[e2e] Open the floodgate

Mon Apr 26 02:11:42 PDT 2004

> TCP-Veno is based on the TCP-Vegas congestion avoidance scheme. We
> analyzed this scheme to test whether it could be used as a loss
> discriminator: it is a poor discriminator. There are some rare cases when
> TCP-Vegas is a good discriminator...(Google on "biaz vaidya
> distinguishing").
> Look at Hengartner (Infocom 2000) on the impact on the "new" congestion
> avoidance scheme on TCP-Vegas performance.
>A lot of work is done along the lines of Veno: researchers use some
>heuristics to distinguish congestion losses from other types of losses and
>...................................
>If there is a scheme to distinguish congestion losses from other losses,
>FIRST MEASURE ITS ACCURACY and report it. If you find that you accurately
>diagnose 90 to 95% of congestion losses and
>more than 50% of other losses, then proceed to measure the
>throughput improvement.

Hi,
Sure, if we can determine loss type with high accuracy, it will definitely help TCP react correctly, wonder whether you are concerning the following two papers?

[1] 'TCP Veno: TCP Enhancement for Transmission over Wireless Access Networks," IEEE (JSAC) Journal of Selected Areas in Communications, Feb. 2003 http://www.ntu.edu.sg/home/ascpfu/veno.pdf 

[2] "Distinguishing Congestion Losses from Wireless Transmission Losses: A Negative Result" Seventh International Conference on Computer Communications and Networks (IC3N), New Orleans, October 1998.  http://www.crhc.uiuc.edu/~nhv/old.papers/mobile-computing/ic3n98.ps 

By studying and comparing two papers, just for the reference, four different aspects are listed here: 

(1) Veno is investigated experimentally over real networks (campus LAN, metropolitan WAN, across-country WAN), in contrast, the paper [2] study is only based on simulation results with background traffic model of exponential ON-OFF UDP, (which may not be suitable to real Internet situation); 

(2) In conclusion part [2], authors points out  " based on the results obtained from Vegas, it appears RTT and throughput statistics hold some information that correlates to the causes of packet losses. However, it is not yet clear if there is sufficient correlation to develop ....., future work on this tipic would investigate.... "  (quote from [2]) regarding this issues, there may be two reasons,

a.    In [2], its RTT is based on monitoring one packet per window (this is also weakness of ns-2(version 2.1b1) since its entire window of packets are sent simultaneously, different from real situation, whereby, packets are sent out one by one). In contrast, Veno monitors RTT for each sent packet per window and make an average; 

b.    a specific difference, probably most important point is, as mentioned at the end of Section II.A of Veno paper [1], "It is worth pointing out that the original Vegas algorithm, BaseRTT is continually updated throughout the live time of the TCP connection with the minimum round-trip time collected so far. In our work, however, BaseRTT is reset whenever packet loss is detected, either due to time-out or duplicate ACKs. BaseRTT is then updated as in the original Vegas algorithm until the next fast-recovery or slow-start is triggered. This is done to take into account of the changing traffic from other connections and that the bandwidth acquired by a single connection among the many connections may change from time to time, causing the BaseRTT to change also." BaseRTT plays an important role in loss prediction or estimation, however, this dynamic reset of BaseRTT has not been considered in paper [2].

(3)  Veno uses real network environment to conduct "Verification of Packet Loss Distinguishing Scheme in Veno" (seeing Section III.A of Veno paper), which demonstrates high accuracy of loss distinguishing. A possible reason for the conclusion in [2] may be that [2] makes use of exponential ON-OFF UDP sources to artificially pump up the congestion loss rate in their simulation, further study may be needed???

(4) Veno experimental results show that conservative use of the Vegas prediction mechanism can yield superior throughput performance, moreover, Veno considered a particular way of adjusting the TCP window based on the estimation of loss types - [2] ONLY focused on accuracy of the determination of loss types only without going the details of HOW TO MAKE USE OF THAT INFORMATION; The improvement of Veno is achieved without compromising the performance of concurrently running legacy TCP Reno connections [1] (in campus LAN, metropolitan WAN, across-country WAN) [1], in terms of this distinctive feature, it seems not to have any risk. 

In fact, in a wired/wireless environment, the interesting thing is, for some random loss occurrence, the TCP connection is very close to the congestive state (there are packets queuing in the bottleneck link/router buffer), while in other cases, the connection may be non-congestive state (there are no packets queuing in the bottleneck router buffer) when random loss is occurring. Moreover, some congestion loss is just transient loss while it is due to congestion reason, as described and studied in [3], " ...... this is the case when short-term congestion losses are treated as random wireless losses or more generally, transient losses. This is indeed an appropriate (in effect, finer-grained) loss classification .............." 

[3] Dhiman Barman, Ibrahim Matta, "Effectiveness of Loss Labeling in Improving TCP Performance in Wired/Wireless Networks," IEEE International Conference on Network Protocols, Paris, France, November 12-15, 2002.

"Obviously, as compared to accurately making out which of packet losses are due to congestion and which are due to bit-errors or other non-congestion reasons, it is more meaningful and more practical for a TCP connection to differentiate between congestive drops, which occur in congestive state, and non-congestive drops, which occur in non-congestive state. Veno uses state differentiation to smartly circumvent the packet-loss-type-distinguishing"(quotes from [1])

Overall, it seems that the congestion state that a TCP connection is evolving is a more fundamental concept than packet loss itself - random (due to link errors, or other non-congestion reasons) or congestion (due to overflowing). Roughly, the congestion state division can be classified into non-congestive, mild congestive, and severe congestive states, specifically,

1) non-congestive: when fast retransmit is triggered by triple dupacks, and the estimation of number of accumulated packets in the bottleneck router are most probably less than beta =3) (the left part is realized by Vegas, but refined by Veno)

2) mild congestive: when fast retransmit is triggered by triple dupacks, and the estimation of number of accumulated packets in the bottleneck router are most probably not less than beta =3) (the left part is realized by Vegas, but refined by Veno)

3) severe congestive: when timeout occurs, 

Veno just does a little bit sending side modification on 1), but reaches high performance improvement without causing any adverse effect on other co-existing connections [1] in wire/wireless environments. 

"What TCP Veno proposes is to refine Reno's AIMD evolution over heterogeneous networks by using the complete judgment of network state estimation - congestive state or non-congestive state, rather than merely depending on packet loss occurrence." (quotes from [1])  All in all, congestion state idea is throughout the whole design philosophy of TCP Veno, loss (detected by triple dupacks) is partial information, indicating what the connection state is probably going on, but not all, partial information is derived from congestion state estimation by a refined congestion detection scheme, the other is from timeout occurrence, corresponding to different congestion level derived, according actions should be performed respectively.

A final note is that when RTT is smaller in LAN or metropolitan WAN, there is no contradiction between [1] and [2], this point is discussed in [4], and author argued the in wireless access networks, considering the proxy already installed almost in each of intranet, RTT is usually smaller, thus Veno performance (if deployed in proxy server) is quite good in this typical example of the Internet. 

[4] "TCP Veno Revisited" IEEE Globecom 2003 no" IEEE comm. Letter (in progress)

Anyway, there indeed exists a lot questions and doubts on Veno, further study is really needed although initial work, as follows, has been explored.

[5] "Performance Study of TCP Veno over wireless LAN and RED router " IEEE Globecom 2003 

[6] "An Enhancement of Multicast Congestion Control over Hybrid Wired/Wireless Networks" WCNC2004

[7] "Dynamics Comparison of TCP Veno and Reno" in progress.

[8] "Improvements Achieved by SACK Employing TCP VENO Equilibrium-Oriented Mechanism over Lossy Networks IEEE EUROCOM 2001

[9] "An analysis of refined TCP algorithm for wired/wireless networks"

-Franklin
====================================
Dr. Fu Cheng Peng, Franklin
Asst Professor 
School of Computer Engineering
Nanyang Technological University, Singapore 639798
Tel: (65) 6790-4287 Fax: (65) 6792-6559 
====================================