FW: [e2e] Question about FAST TCP

[Hadrien Bullot]

Saveri and al.
I 've made few tests from SLAC to NsLabs with Fast TCP on this side and 
with TCP Reno 16 streams in the other side. We have a  decrease of the 
performance of Fast TCP only with the 8 MB window size but not 4 MB. 
Also with the reverse traffic, note that we have more variation on the RTT.
The plots are avalaible here : 
http://www.slac.stanford.edu/~hadrien/reversefast/index.html

Hadrien


Cottrell, Les wrote:

>
>
> -----Original Message-----
> From: Saverio Mascolo [mailto:mascolo at poliba.it]
> Sent: Friday, October 10, 2003 3:53 AM
> To: Steven Low; lz6 at njit.edu
> Cc: end2end-interest at postel.org
> Subject: Re: [e2e] Question about FAST TCP
>
>
> 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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/end2end-interest/attachments/20031010/cf80dd9b/attachment.html