DNP3: TCP versus UDP

Many sites choose to use UDP rather than TCP for DNP3 connections, especially on cellular networks where it is important to reduce data usage and associated costs. These savings come at the cost of less efficient handling of packet-loss, slower notice of connection failure and increased application complexity. Trihedral does not recommend either protocol over the other, but offers the following information to help you choose which to use.

 

TCP has a direct overhead over UDP of 12 octets per packet sent. There are also TCP connection setup packets (SYN, SYN + ACK, ACK, 68, 68 & 64 octets respectively), each time a connection is made and TCP ACK messages to be sent, although these are often conveyed along with data, hence no overhead.

For a common DNP3 master message (for example, a class 0123 request with 27 octets), a TCP packet will contain 81 octets and a UDP packet will contain 69 octets giving a TCP overhead of 12/69 = 17.4%. For a common DNP3 maximum size response, a TCP packet will contain 346 octets and a UDP packet 334, a TCP overhead of 12/346 = 3.45%. As a DNP3 response often consists of multiple response packets, the average overhead will tend to be a little lower than 17% in the master to outstation direction, and a little more than 3.5% in the outstation to master direction.

The overhead figures show that UDP (as long as retransmissions are ignored) will use less octets on the link, but a dropped UDP packet is likely to cause a bigger retransmission (all application fragments will be resent) and hence more octets than with TCP (a small ACK will be sent requesting only the missing segment).

 

A system configured to use TCP in "disconnected mode", where the master closes the connection shortly after the outstation check poll and the outstation connects to the master when it has events to send, is the most efficient use of TCP, and requires an IP network listener tag for each local port in use. Only one IP Network listener is definitely required as all drivers could use the same port, with the DNP3 drivers configured for the IP Network listener group and the outstations configured to either connect to the last master IP, or have the master IP's statically configured along with the remote port to be used. The outstation also has to have the local port configured for incoming connections.

For UDP, the outstations still require configuration, either to connect to the last master IP, or have the master IP's statically configured, along with the local and remote port to be used.

 

In summary there is a little extra configuration at the master side for TCP, and nothing at the outstation, although TCP does require each outstation using a particular port to have a distinct DNP3 address (0 - 65519 are available).

With TCP, the protocol guarantees in-order packet delivery to the application, requesting retransmissions if necessary for missing packets. Failures of the connection are reported to the application which can take prompt recovery action (e.g. opening a new connection).

With UDP, there are no guarantees, as the application has to perform the TCP in-order reassembly functionality along with retransmission requests, and there are no indications to the application of issues in the transit to the remote apart from a lack of response. For VTScada drivers, the recovery will occur after the driver timeout limit for responses occurs.

TCP has built-in congestion control, handled by all components on the route, UDP has none, and when under capacity pressure, routers are more likely to drop or delay UDP packets as it's assumed applications running atop of UDP don't mind.

 

In summary, for DNP3 the tradeoff is a small increase in octets transmitted for TCP, but with better behavior with packet loss and more immediate notice of connection failure and a reduced application complexity. With the current DNP3 driver, UDP packet loss (or out-of-order packets) causes the whole DNP3 message to be retransmitted.