TCP improves performance with congestion avoidance and flow control.

Congestion Avoidance

Congestion avoidance is a way of increasing performance by reducing or minimizing the number of packets that are lost on the network (and so have to be resent) due to congestion. Routers buffer frames that they aren’t ready to process yet. If the buffer gets filled up, further incoming packets are dropped and have to be resent. So, avoiding that overflow improves performance.

Numerous congestion control algorithms exist, but they all have two things in common: they use feedback from the network (in the form of lost or delayed packets or in some cases a signal) to identify congestion, and they slow down the rate of transfer when congestion is identified.

TCP uses the ECE (Explicit Congestion Notification Echo) and CWR (Congestion Window Reduced) flags for congestion avoidance. These two flags are used to warn senders of congestion in the network, so they can reduce the rate at which they send subsequent segments.

Flow Control

Flow control is a process that regulates the amount of data that the receiving node receives, to prevent the receiver from being overwhelmed with data. When a receiver receives data that it isn’t ready to process yet, it queues the data in a buffer. If more data comes in than the buffer can hold, then it gets dropped and has to be resent.

Flow control attempts to avoid this type of overflow by specifying the amount of data that the sender can send before receiving an acknowledgement from the receiver. This amount of data is called the “window size.” The Window Size field in a TCP segment header holds this value; TCP uses this value to implement flow control.

UDP

The User Datagram Protocol, or UDP, is a connectionless protocol: each packet is sent to the receiver’s IP address and port without first establishing a connection. UDP does not guarantee that its messages are sent, and has no support for congestion avoidance or flow control. As such, it is not considered a “reliable” protocol; it leaves reliability up to the application layer to implement. (On average, about 95 percent of UDP PDUs successfully reach their destination, which is reliable enough for some applications.)

Since UDP doesn’t have the overhead required to ensure reliability, it’s also a lower-latency (faster) protocol than TCP. UDP is used in situations where speed is more important than guaranteed delivery, in particular voice and video transmissions.

UDP provides faster transportation of data than TCP does, but it’s also less reliable. It does not implement any sort of congestion avoidance or flow control mechanisms. It is often used for video and voice applications, where low latency is more important to the user experience than absolute reliability: someone watching a live video stream is more willing to tolerate some garbled transmission than having the transmission stop altogether for a few seconds. Another example of a service that uses UDP is DNS (Domain Name Server), the set of servers which resolve domain names (www.mywebsite.com is an example of a domain name) into IP addresses.

The only reliability requirement that UDP implements is a checksum to identify corrupt datagrams, and it can be set to drop them if corrupt. Applications using UDP as their Transport Layer protocol may implement their own additional reliability requirements as needed. For example, an application needing in-order datagrams, but not retransmission of lost packets, could implement something similar to TCP’s sequencing number, while not implementing any sort of acknowledgement process.

UDP Datagrams

UDP PDUs are called datagrams. A UDP datagram looks like this:

1. 1.  Source port.
   2. Destination port.
   3. Length.
   4. Checksum.
   5. Payload (an Application Layer PDU).

The UDP Checksum field is optional when using IPv4 at the Internet Layer, and mandatory when using IPv6. This is because an IPv4 packet header has a Checksum field of its own, while an IPv6’s does not.

UDP does — optionally — drop corrupt datagrams. Other than that, it doesn’t do anything to ensure reliability. This is not necessarily a problem; dropped packets cause the garbled voice or video streams with which most of us are familiar, but that is preferable to having the stream stop until dropped packets can be resent.

The next article concludes the discussion of the Transport Layer with an explanation of sockets.