[e2e] Question about FAST TCP

[Steven Low]

Hi Saverio

In principle, FAST TCP will indeed react to congestion in
the reverse path as well, by reducing its window.   Whether
one should react to congestion only in the forward path or
in both the forward and reverse paths may be debatable.
Without the help of the receiver and/or network, it seems
that delay-based algorithms will always react to both.
If receiver can help, then, indeed, one can implement
schemes such as TCP Santa Cruz; if both receiver
and network can help, one can implement Shiv's
Monoco.

Whether reverse path congestion is a serious issue
in practice remains to be seen.

Steven


Saverio Mascolo wrote:

>Hi Steven and all,
>
>in the msg below, FAST TCP is described as "a high speed version of Vegas".
>
>We have found that the main problem with Vegas is that, being based on RTT
>measures as indication of congestion, it is not able to get bandwidth in the
>presence of reverse traffic because the reverse traffic increases the RTT.
>For instance 1 Vegas flow would not be able to grab bandwidth when going
>"against" 10 Vegas reverse connections. So it would be important to test
>Fast TCP with reverse traffic.
>
>A solution could be to measure the forward propagation time instead of
>measuring the rtt, basically doing what has been done in TCP Santa Cruz.
>
>The problem with these kind of solutions is that, when coexisting with
>probing algorithms such as Reno, Reno would get more bandwidth since it
>would tend to get more queuing.
>
>Saverio
>
>----- Original Message -----
>From: "Steven Low" <slow at caltech.edu>
>To: <lz6 at njit.edu>
>Cc: <end2end-interest at postel.org>
>Sent: Wednesday, August 06, 2003 8:04 AM
>Subject: Re: [e2e] Question about FAST TCP
>
>
>  
>
>>The first two papers are more on background
>>theory, focusing just on the window control
>>algorithm.  The algorithms proposed in 1
>>and 2 all contain a q_dot term (derivative
>>of end to end price).  They have been
>>implemented in ns, but not yet in Linux,
>>so there is no performance measurement in
>>real network.
>>
>>The third paper (IETF Draft) is a small
>>subset of a paper we are revising (whose
>>extended abstract has been submitted),
>>and will hopefully be available online
>>soon.  The algorithm there can be thought
>>of as a high speed version of Vegas, and
>>does not use q_dot term.
>>
>>Steven
>>
>>
>>
>>
>>lz6 at njit.edu wrote:
>>
>>    
>>
>>>As far as I know, there are three major FAST TCP based on control
>>>      
>>>
>theory:
>  
>
>>>1. Stabilized Vegas, D. H. Choe and S. H. Low
>>>2. A new TCP/AQM for stable operation in fast networks, F. Paganini, Z.
>>>      
>>>
>Wang,
>  
>
>>>S. H. Low and J. C. Doyle
>>>3. IETF Draft: FAST TCP for high-speed long-distance networks, Cheng
>>>      
>>>
>Jin,
>  
>
>>>David X. Wei and Steven H. Low
>>>
>>>Is there any performance comparison among these three appraoches in real
>>>network?
>>>
>>>
>>>
>>>      
>>>
>>--
>>_____________________________________________
>>Steven Low                assoc prof, cs & ee
>>netlab.caltech.edu        tel: (626) 395-6767
>>slow at caltech.edu          fax: (626) 568-3603
>>
>>
>>    
>>
>
>
>  
>

-- 
_____________________________________________
Steven Low                assoc prof, cs & ee
netlab.caltech.edu        tel: (626) 395-6767
slow at caltech.edu          fax: (626) 568-3603