Latency Optimization - Network Performance
What is Latency?
Latency is any type of delay that occurs in network. While ideal performance would occur without latency, in the real world latency is a fact of life. Light travelling in a fiber optic network will have latency even in an ideal setup. Therefore a baseline of latency will exist for any network. However, when compared to the actual latency experienced in networks the baseline is small. Most of the latency can be attributed to equipment on the network such as routers, firewalls, etc.
Typically, latency is measured by the time taken for a round trip by a data packet. While using this as a measure of latency may seem counter intuitive, it is indeed a better measure of network performance. This is due to the fact that systems communicating with each other are in constant touch and each receiving system will respond. Thus, network latency can be determined by the time taken for the roundtrip.
Many factors determine network latency. These include but are not limited to transmission latency, propagation, hardware and router latency. Upgrading hardware may improve latency, but this will involve a substantial investment.
Latency Optimization Algorithms
While increasing bandwidth to improve performance is as easy as negotiating extra bandwidth from an ISP, latency optimization is trickier and more involved. Over the years several algorithms have been developed to address the issue of latency optimization. The following gives a list of some, but not all of the algorithms and a brief explanation on how they tackle latency optimization.
TCP Tahoe and Reno – these two latency optimization algorithms are named after Lake Tahoe and Reno, Nevada. They are TCP Congestion Avoidance Algorithms and are frequently referred latency optimization algorithms.
All packet switched networks face the danger of congestion collapse. Congestion collapse is that situation when no (or very little) communication occurs because of traffic congestion. The condition occurs at network chock points where the total incoming data traffic exceeds the capacity or bandwidth for outward transmission. The WAN/LAN interface is a point where this condition most frequently manifests itself.
TCP uses a multi-pronged strategy to avoid traffic congestion which results in latency. A congestion window is maintained by TCP for each connection and this window limits the number of unacknowledged packets that could be in transit. A technique called Slow Start is used by TCP to increase the congestion window after a connection is initialized, or there is a timeout. In this technique, the window is initially double the Maximum Segment Size (commonly referred to as MSS). Each acknowledged packet results in the congestion window increasing the MSS by 1. Thus while the initial rate may be slow, the rate of increase is very fast and effectively doubles for every acknowledge packet round trip.
Congestion avoidance stage begins when the congestion window exceeds a threshold (called ssthresh). The initial ssthresh is large and because of this the initial slow start usually ends after a loss. The ssthresh however, is refreshed after each slow start and will sometimes affect subsequent slow starts which are triggered by timeouts.
When data packets are lost, Tahoe and Reno differ in the way in which this is handled. Packet loss usually results in duplicate ACK being received. Tahoe considers triple duplicate ACKs as timeouts and will immediately perform fast retransmits while reducing the congestion window to 1 MSS and resetting to slow start mode.
In contrast to the way Tahoe handles packet loss, on receipt of 3 duplicate ACKs, the congestion window is reduces by 50%, fast retransmit is carried out and will enter a stage called Fast Recovery. The slow start mode is also used.
TCP Vegas - This is a congestion avoidance algorithm for latency optimization that uses packet delay rather than packet loss as basis for optimizing latency. TCP Vegas bases its decision on the Round Trip Time (RTT) values and is very dependent on the accurate determination of these to calculate a base RTT. If real time calculated RTT values are less than the base number, the throughput required will be less than the capacity of the connection and traffic flow will be normal. If the number is too high, then it detects congestion and slows down the rate at which it sends packets.
TCP Hybla – this algorithm was developed to specifically handle the fluctuations in performance caused by long RTTs in satellite connections. Some of the steps involved in this algorithm are
- Long RTT connections are granted the same transmission rate of a comparable fast connection reference
- Mandatory SACK (this refers to sending ACK for each transmission) policy
- Time stamps
- Dynamic Bandwidth Estimation (Hoe’s estimation)
- Use of pacing – a packet spacing technique
Hybla shows great promise in handling satellite links that are notorious for latency. By allowing the algorithm to accept some of the connection have this problem, Hybla smoothes fluctuations and assists in latency optimization