Zeta-TCP

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 channels), 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 predications 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.

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.

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.[2]

At the time of writing, Zeta-TCP has been implemented as software modules for Linux (Netfilter Kernel Module), Microsoft Windows 10 down to XP and related Windows Server versions (NDIS 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.