Zeta-TCP
Encyclopedia
Zeta-TCP refers to a set of proprietary TCP
algorithms targeted to improve the end-to-end performance of TCP, regardless of whether the peer is Zeta-TCP or any other TCP protocol stack, in other words, to be compatible with the existing TCP algorithms. It was designed and implemented by AppEx Networks Corporation
.
Zeta-TCP offers the following improvements primarily:
), wireline noises/cross-talk, connectivity flaws, software bugs, etc., is increasing. Once a "congestion" is detected (or false-alarmed), New Reno shrinks the Congestion Window (CWND) sharply, causing a plunge of the sending rate. This is one of the major reasons that the TCP based applications are often barely able to utilize a fraction of the subscribed bandwidth today, especially when the RTT
is large.
TCP Vegas
and its variations, most notably FAST TCP
, base their congestion prodications on the RTT measurement only. Such latency-based algorithms overcome the problems of the loss-based ones, and are usually a more realistic reflection of the congestions in the network. But the latency-based algorithms have their own limitations, too.
Zeta-TCP attempts to tackle the problem by combining the strength of both latency-based and loss-based algorithms. It constantly measures the RTT variation and loss rate variation, and calculates the likelihood of the congestions. Different CWND backoff schemes are applied based on the likelihood level. With the highest level, it applies the backoff scheme of New Reno, which has already been proven to be effective and stable with many years of massive deployment.
Zeta-TCP has introduced a simple but effective algorithm to calculate the loss probability on every unACK'd/unSACK'd packet. A packet is retransmitted only when its loss probability has surpassed a certain threshold. The same rule applies to the retransmission decision of every packet. Therefore Zeta-TCP is able to minimize the number of retransmitted packets, further improving the bandwidth utilization. Lab tests also confirmed that Zeta-TCP retransmitted much fewer packets than the other TCP implementations under the same loss rate.
Zeta-TCP has also developed a mechanism to accurately detect the packet loss at the earliest possible time once it suspects the a loss is likely to happen. Early-detection usually can save an RTT or two on retransmission.
The Reverse-Controlled inbound acceleration is heuristic in that the inbound speed is really controlled by the sender, i.e., the peer. It can only hint the peer to send faster. Some TCP stacks take the hint and others don't. Also, quite often the sender side (content server for instance) has rate limiting mechanism so that the acceleration effect is capped.
In addition to acceleration, Reverse Control can also limit the inbound rate. Unlike acceleration, putting a brake on the inbound traffic is very effective and accurate with the TCP flow control mechanism. The inbound rate limiting of Zeta-TCP lays the foundation of the inbound flow control of AppEx IPEQ.
IM Filter/NDIS LWF), and WinCE. AppEx chose not to modify the protocol stack, but intercept the TCP flows and apply its algorithms on-the-fly. This is the nonintrusive way to implement the algorithms intended for wider acceptance. The drawback is the added overhead of processing. But in reality the overhead is negligible in comparison with the performance gains.
Transmission Control Protocol
The Transmission Control Protocol is one of the core protocols of the Internet Protocol Suite. TCP is one of the two original components of the suite, complementing the Internet Protocol , and therefore the entire suite is commonly referred to as TCP/IP...
algorithms targeted to improve the end-to-end performance of TCP, regardless of whether the peer is Zeta-TCP or any other TCP protocol stack, in other words, to be compatible with the existing TCP algorithms. It was designed and implemented by AppEx Networks Corporation
AppEx Networks
AppEx Networks is a privately-held WAN optimization and ADN company headquartered in Cupertino, California, with an R&D center in Beijing, China. AppEx manufactures networks appliances based on its patented technologies, and delivers WAN optimization, ADN and traffic management solutions...
.
Zeta-TCP offers the following improvements primarily:
- Congestion avoidanceTCP congestion avoidance algorithmTransmission Control Protocol uses a network congestion avoidance algorithm that includes various aspects of an additive increase/multiplicative decrease scheme, with other schemes such as slow-start in order to achieve congestion avoidance....
based on both latency and loss measures. - Improved loss-detection algorithm.
- Reverse control.
Congestion Avoidance
Most of the TCP stack implementations today use TCP New Reno or its variations (such as TCP SACK RFC3517) as the congestion avoidance algorithm. The New Reno based algorithms are loss-based. Loss-based algorithms treat the packet losses as the sole indication of the congestions in the network. As the Internet has since evolved, this assumption is often an overkill today. The congestion loss is constantly descending with the advancement of the technologies, while, relatively, random loss due to the properties of the media (e.g., wireless/Fading channelsFading
In wireless communications, fading is deviation of the attenuation that a carrier-modulated telecommunication signal experiences over certain propagation media. The fading may vary with time, geographical position and/or radio frequency, and is often modelled as a random process. A fading channel...
), wireline noises/cross-talk, connectivity flaws, software bugs, etc., is increasing. Once a "congestion" is detected (or false-alarmed), New Reno shrinks the Congestion Window (CWND) sharply, causing a plunge of the sending rate. This is one of the major reasons that the TCP based applications are often barely able to utilize a fraction of the subscribed bandwidth today, especially when the RTT
Round-trip delay time
In telecommunications, the round-trip delay time or round-trip time is the length of time it takes for a signal to be sent plus the length of time it takes for an acknowledgment of that signal to be received...
is large.
TCP Vegas
TCP Vegas
TCP Vegas is a TCP congestion avoidance algorithm that emphasizes packet delay, rather than packet loss, as a signal to help determine the rate at which to send packets. It was developed at the University of Arizona by Lawrence Brakmo and Larry L...
and its variations, most notably FAST TCP
FAST TCP
FAST TCP is a TCP congestion avoidance algorithm especially targeted at long-distance, high latency links, developed at the , California Institute of Technology and now being commercialized by...
, base their congestion prodications on the RTT measurement only. Such latency-based algorithms overcome the problems of the loss-based ones, and are usually a more realistic reflection of the congestions in the network. But the latency-based algorithms have their own limitations, too.
Zeta-TCP attempts to tackle the problem by combining the strength of both latency-based and loss-based algorithms. It constantly measures the RTT variation and loss rate variation, and calculates the likelihood of the congestions. Different CWND backoff schemes are applied based on the likelihood level. With the highest level, it applies the backoff scheme of New Reno, which has already been proven to be effective and stable with many years of massive deployment.
Loss Detection
The packet losses in the real network environment rarely spread out evenly. Rather they tend to happen close to each other. The TCP related RFCs (New Reno and SACK, etc.) explicitly defined how the first loss can be detected with high confidence. However, the detection of the losses after TCP enters the Fast Recovery mode with SACK permitted is not very efficient in RFC3517. And some popular Operating Systems have their own implementations that are equally suboptimal.Zeta-TCP has introduced a simple but effective algorithm to calculate the loss probability on every unACK'd/unSACK'd packet. A packet is retransmitted only when its loss probability has surpassed a certain threshold. The same rule applies to the retransmission decision of every packet. Therefore Zeta-TCP is able to minimize the number of retransmitted packets, further improving the bandwidth utilization. Lab tests also confirmed that Zeta-TCP retransmitted much fewer packets than the other TCP implementations under the same loss rate.
Zeta-TCP has also developed a mechanism to accurately detect the packet loss at the earliest possible time once it suspects the a loss is likely to happen. Early-detection usually can save an RTT or two on retransmission.
Reverse Control
While the other algorithms focus on accelerating the outgoing traffic, Reverse Control attempts to address the incoming issues. Reverse Control monitors the quality of the connections with inbound data, and executes the algorithm to hint the peer to transmit as fast as it can when the connection quality is good. The algorithm also makes good effort to more accurately identify the real packet losses from other abnormal situations in order to avoid triggering unnecessary fast recoveries.The Reverse-Controlled inbound acceleration is heuristic in that the inbound speed is really controlled by the sender, i.e., the peer. It can only hint the peer to send faster. Some TCP stacks take the hint and others don't. Also, quite often the sender side (content server for instance) has rate limiting mechanism so that the acceleration effect is capped.
In addition to acceleration, Reverse Control can also limit the inbound rate. Unlike acceleration, putting a brake on the inbound traffic is very effective and accurate with the TCP flow control mechanism. The inbound rate limiting of Zeta-TCP lays the foundation of the inbound flow control of AppEx IPEQ.
Implementation
At the time of writing, Zeta-TCP has been implemented as software modules for Linux (Netfilter Kernel Module), Microsoft Windows 7 down to XP (NDISNetwork Driver Interface Specification
The Network Driver Interface Specification is an application programming interface for network interface cards . It was jointly developed by Microsoft and 3Com Corporation, and is mostly used in Microsoft Windows, but the open-source NDISwrapper and Project Evil driver wrapper projects allow...
IM Filter/NDIS LWF), and WinCE. AppEx chose not to modify the protocol stack, but intercept the TCP flows and apply its algorithms on-the-fly. This is the nonintrusive way to implement the algorithms intended for wider acceptance. The drawback is the added overhead of processing. But in reality the overhead is negligible in comparison with the performance gains.