[e2e] Question about FAST TCP

Steven Low slow at caltech.edu
Sat Oct 11 12:33:06 PDT 2003 

Hi Injong

Indeed, the interaction of delay-based and loss-based
schemes at high speed may be one of the most challenging
issues to be resolved for FAST TCP.  My feeling is that
all the other commonly cited issues are manageable *in
practice*, though this remains to be confirmed or disproved
with a lot more testing in real applications and networks.

As I mentioned to several people previously, we believe
FAST is certainly suitable for many niche applications
where such complications do not pose a serious problem.
In such environments, FAST TCP seems to perform well,
and more importantly, predictably and robustly.
What remains to be seen is whether it is generally applicable
in an environment where all complications can arise.  We
are of course cautiously optimistic.

A few comments on the inter-protocol fairness.

1. Take Reno and FAST TCP for an example.  In theory
(with some assumptions), one can tune FAST TCP parameter
to achieve any desirable fairness (precisely defined) between
Reno and FAST, given global information.  The challenge is
whether one can adapt the parameter to achieve this in a
distributed manner using only local information.   This suggests
that there is no fundamental barrier for the coexistence of Reno
and FAST, though the quest for a good engineering solution is
wide open.

2. As you said, there are many desirable properties of
delay-based schemes.   As a community, we, both research
and industry, have put in a tremendous amount of effort trying
to rectify some undersirable properties of loss-based schemes.  
I believe that as capacity increases, this fight will only become
harder.   Exploiting delay as a measure of congestion, together
with loss signal, is both necessary and desirable moving forward.

>  In fact, during loaded cases
> where many flows are competing, I am not sure whether there is any better
> scheme than AIMD in achieving fairness (including rtt fairness).

3. So far in our experiments, in scenarios where inter-protocol
issues do not arise, FAST TCP performs exactly as expected
in under-loaded and loaded cases, in terms of throughoutput,
fairness, delay, loss etc.    Again, how to enhance FAST TCP
to perform as well in complicated scenioars involving other
protocols is a current R&D effort.

Regards
Steven



Injong Rhee wrote:

>Hi Steve,
>
>In my humble opinion, it remains to be seen how delay-based congestion
>control schemes would live together with loss-based ones. I believe that
>there are many desirable properties of delay-based schemes. However, in the
>world that is dominated by loss-based Reno style congestion control, I see
>some up-heel battle for delay-based schemes.
>
>I have this wild idea (no flames) for some hybrid ones that react to *delay
>reductions* rather than *delay increases* while keeping the loss reactions
>the same as is now. This does not reduce queuing delays (maybe worsen it)
>unlike existing delay-based schemes would do. However, it does increase
>scalability during less loaded situations. In fact, during loaded cases
>where many flows are competing, I am not sure whether there is any better
>scheme than AIMD in achieving fairness (including rtt fairness).
>
>Regards,
>Injong
>
>
>
>-----Original Message-----
>From: end2end-interest-admin at postel.org
>[mailto:end2end-interest-admin at postel.org]On Behalf Of Steven Low
>Sent: Saturday, October 11, 2003 2:58 AM
>To: Saverio Mascolo
>Cc: lz6 at njit.edu; end2end-interest at postel.org
>Subject: Re: [e2e] Question about FAST TCP
>
>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
>
>
>
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.524 / Virus Database: 321 - Release Date: 10/6/2003
>
>---
>Outgoing mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.524 / Virus Database: 321 - Release Date: 10/6/2003
>
>
>
>  
>

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

More information about the end2end-interest mailing list