Zeta-TCP

<h2 id="congestion-avoidance">Congestion avoidance</h2>
<p>Most TCP stack implementations use <a href="/facts/TCP_congestion_avoidance_algorithm/gC9Fer09">TCP New Reno</a> or its variations (such as TCP SACK <a href="http://www.ietf.org/rfc/rfc3517.txt">RFC3517</a>) 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 technologies, while, relatively, random loss due to the properties of the media (e.g., wireless/<a href="/facts/Fading/RsDwBbdz">Fading channels</a>), wireline noises/cross-talk, connectivity flaws, software bugs, etc., is increasing. Once "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 TCP based applications are often barely able to use a fraction of the subscribed bandwidth, especially when the round-trip delay time (<a href="/facts/Round-trip_delay_time/jYgNMK98">RTT</a>) is large.
</p><p><a href="/facts/TCP_Vegas/FRcKp7Cq">TCP Vegas</a> and its variations, most notably <a href="/facts/FAST_TCP/c5JIdo8N">FAST TCP</a>, 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 congestion in the network. However the latency-based algorithms have their own <a href="/facts/FAST_TCP/c5JIdo8N">limitations</a>.
</p><p>Zeta-TCP addresses the problem by combining the strength of latency-based and loss-based algorithms. It constantly measures the RTT variation and loss rate variation, and calculates the likelihood of congestion. CWND backoff schemes are applied based on the likelihood. With the highest likelihood, it applies the backoff scheme of New Reno, which has already been proven to be effective and stable with many years of massive deployment.
</p>
<h2 id="loss-detection">Loss detection</h2>
<p>The packet losses in the real network environment rarely spread 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 efficient in <a href="http://www.ietf.org/rfc/rfc3517.txt">RFC3517</a>. Some popular Operating Systems have their own implementations that are equally suboptimal.
</p><p>Zeta-TCP provides a simple 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 minimizes the number of retransmitted packets, further improving the bandwidth utilization. Lab tests have confirmed that Zeta-TCP retransmitted much fewer packets than the other TCP implementations under the same loss rate.
</p><p>Zeta-TCP has developed a mechanism to accurately detect the packet loss at the earliest time once it suspects a loss is likely to happen. Early-detection usually can save one RTT or two on retransmission.
</p>
<h2 id="reverse-control">Reverse control</h2>
<p>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 tends to more accurately identify the real packet losses from other abnormal situations in order to avoid triggering unnecessary fast recoveries.
</p><p>The Reverse-controlled inbound acceleration is heuristic in that the inbound speed is controlled by the sender, i.e., the peer. It can only hint to the peer to send faster. Some TCP stacks take the hint and others do not. Often the sender side (e.g. content server) has a rate limiting mechanism that caps acceleration.
</p><p>In addition to acceleration, Reverse Control can also limit the inbound rate. Unlike acceleration, slowing the inbound traffic is 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.<a class="footnote-ref" id="fnref:2" href="#fn:2"><sup>2</sup></a>
</p>
<h2 id="implementation">Implementation</h2>
<p>At the time of writing, Zeta-TCP has been implemented as software modules for Linux (<a href="/facts/Netfilter/M3rtyl3r">Netfilter</a> Kernel Module), Microsoft Windows 10 down to XP and related Windows Server versions (<a href="/facts/Network_Driver_Interface_Specification/YPjBLj2t">NDIS</a> IM Filter/NDIS LWF), and WinCE. AppEx does not modify the protocol stack, but intercepts the TCP flows and apply its algorithms on-the-fly. This nonintrusive way to implement the algorithms is intended for wider acceptance. The drawback is the added overhead of processing but the overhead is negligible in comparison with the performance gains.
</p>

<h2 id="references">References</h2>

<ol>
<li id="fn:1"><p>"Whitepaper: Zeta-TCP - Intelligent, Adaptive, Asymmetric TCP Acceleration" (PDF). <a href="http://www.appexnetworks.com/white-papers/ZetaTCP.pdf" target="_blank">http://www.appexnetworks.com/white-papers/ZetaTCP.pdf</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li>
<li id="fn:2"><p>"Whitepaper: AppEx IPEQ (IP End-to-End QoS)" (PDF). <a href="http://www.appexnetworks.com/white-papers/IPEQ.pdf" target="_blank">http://www.appexnetworks.com/white-papers/IPEQ.pdf</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></p></li>
</ol>

Zeta-TCP open-in-new

Zeta-TCP