Zeta-TCP

This article has multiple issues. Please help or discuss these issues on the talk page. (Learn how and when to remove these template messages) A major contributor to this article appears to have a close connection with its subject. It may require cleanup to comply with Wikipedia's content policies, particularly neutral point of view. Please discuss further on the talk page. (April 2018) (Learn how and when to remove this template message) The topic of this article may not meet Wikipedia's notability guidelines for products and services. Please help to demonstrate the notability of the topic by citing reliable secondary sources that are independent of the topic and provide significant coverage of it beyond a mere trivial mention. If notability cannot be shown, the article is likely to be merged, redirected, or deleted. Find sources:  –  ·  ·  · scholar · JSTOR (April 2018) (Learn how and when to remove this template message) This article relies too much on references to primary sources. Please improve this by adding secondary or tertiary sources. (April 2018) (Learn how and when to remove this template message) This article may rely excessively on sources too closely associated with the subject, potentially preventing the article from being verifiable and neutral. Please help by replacing them with more appropriate citations to reliable, independent, third-party sources. (April 2018) (Learn how and when to remove this template message) This article contains content that is written like an advertisement. Please help by removing promotional content and inappropriate external links, and by adding encyclopedic content written from a neutral point of view. (June 2011) (Learn how and when to remove this template message) (Learn how and when to remove this template message)

Zeta-TCP^[1] refers to a set of proprietary Transmission Control Protocol (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:

• 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 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.

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

Implementation[]

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.

References[]