TCP UDP Questions
It is a general best practice to not mix TCP-based traffic with UDP-based traffic (especially Streaming-Video) within a single service-provider class because of the behaviors of these protocols during periods of congestion. Specifically, TCP transmitters throttle back flows when drops are detected. Although some UDP applications have application-level windowing, flow control, and retransmission capabilities, most UDP transmitters are completely oblivious to drops and, thus, never lower transmission rates because of dropping.
When TCP flows are combined with UDP flows within a single service-provider class and the class experiences congestion, TCP flows continually lower their transmission rates, potentially giving up their bandwidth to UDP flows that are oblivious to drops. This effect is called TCP starvation/UDP dominance.
TCP starvation/UDP dominance likely occurs if TCP-based applications is assigned to the same service-provider class as UDP-based applications and the class experiences sustained congestion.
Granted, it is not always possible to separate TCP-based flows from UDP-based flows, but it is beneficial to be aware of this behavior when making such application-mixing decisions within a single service-provider class.
TCP Selective Acknowledgement (SACK) prevents unnecessary retransmissions by specifying successfully received subsequent data. Let’s see an example of the advantages of TCP SACK.
|TCP (Normal) Acknowledgement||
TCP Selective Acknowledgement
For TCP (normal) acknowledgement, when a client requests data, server sends the first three segments (named of packets at Layer 4): Segment#1,#2,#3. But suppose Segment#2 was lost somewhere on the network while Segment#3 stills reached the client. Client checks Segment#3 and realizes Segment#2 was missing so it can only acknowledge that it received Segment#1 successfully. Client received Segment#1 and #3 so it creates two ACKs#1 to alert the server that it has not received any data beyond Segment#1. After receiving these ACKs, the server must resend Segment#2,#3 and wait for the ACKs of these segments.
For TCP Selective Acknowledgement, the process is the same until the Client realizes Segment#2 was missing. It also sends ACK#1 but adding SACK to indicate it has received Segment#3 successfully (so no need to retransmit this segment. Therefore the server only needs to resend Segment#2 only. But notice that after receiving Segment#2, the Client sends ACK#3 (not ACK#2) to say that it had all first three segments. Now the server will continue sending Segment #4,#5, …
The SACK option is not mandatory and it is used only if both parties support it.
The TCP Explicit Congestion Notification (ECN) feature allows an intermediate router to notify end hosts of impending network congestion. It also provides enhanced support for TCP sessions associated with applications, such as Telnet, web browsing, and transfer of audio and video data that are sensitive to delay or packet loss. The benefit of this feature is the reduction of delay and packet loss in data transmissions. Use the “ip tcp ecn” command in global configuration mode to enable TCP ECN.
The TCP time-stamp option provides improved TCP round-trip time measurements. Because the time stamps are always sent and echoed in both directions and the time-stamp value in the header is always changing, TCP header compression will not compress the outgoing packet. Use the “ip tcp timestamp” command to enable the TCP time-stamp option.
The TCP Keepalive Timer feature provides a mechanism to identify dead connections. When a TCP connection on a routing device is idle for too long, the device sends a TCP keepalive packet to the peer with only the Acknowledgment (ACK) flag turned on. If a response packet (a TCP ACK packet) is not received after the device sends a specific number of probes, the connection is considered dead and the device initiating the probes frees resources used by the TCP connection.
Global synchronization occurs when multiple TCP hosts reduce their transmission rates in response to congestion. But when congestion is reduced, TCP hosts try to increase their transmission rates again simultaneously (known as slow-start algorithm), which causes another congestion. Global synchronization produces this graph:
Global synchronization reduces optimal throughput of network applications and tail drop contributes to this phenomenon. When an interface on a router cannot transmit a packet immediately, the packet is queued. Packets are then taken out of the queue and eventually transmitted on the interface. But if the arrival rate of packets to the output interface exceeds the ability of the router to buffer and forward traffic, the queues increase to their maximum length and the interface becomes congested. Tail drop is the default queuing response to congestion. Tail drop simply means that “drop all the traffic that exceeds the queue limit. Tail drop treats all traffic equally and does not differentiate among classes of service.
When TCP is mixing with UDP under congestion, TCP flows will try to lower their transmission rate while UDP flows continue transmitting as usual. As a result of this, UDP flows will dominate the bandwidth of the link and this effect is called TCP-starvation/UDP-dominance. This can increase latency and lower the overall throughput.
If the speed of an interface is equal or less than 768 kbps (half of a T1 link), it is considered a low-speed interface. The half T1 only offers enough bandwidth to allow voice packets to enter and leave without delay issues. Therefore if the speed of the link is smaller than 768 kbps, it should not be configured with a queue.