[e2e] TCP behaviour in the presence of reverse traffic (Vegas, New Reno, Westwood+, Fast?)

[Lisong Xu]

Relative delay can be measured without synchronization of two end hosts. See
TCP-LP by Rice University, TCP-Santa Cruz by University of California -
Santa Cruz, and Syn-TCP by UNC - Chapel Hill.

Lisong

----- Original Message ----- 
From: "Saverio Mascolo" <sm at signal.uu.se>
To: "Jing Shen" <jshen_cad at yahoo.com.cn>; <lz6 at njit.edu>
Cc: <end2end-interest at postel.org>
Sent: Friday, November 14, 2003 8:31 AM
Subject: Re: [e2e] TCP behaviour in the presence of reverse traffic (Vegas,
New Reno, Westwood+, Fast?)


> i think so
> saverio
> ----- Original Message -----
> From: "Jing Shen" <jshen_cad at yahoo.com.cn>
> To: <lz6 at njit.edu>; "Saverio Mascolo" <mascolo at poliba.it>
> Cc: <end2end-interest at postel.org>
> Sent: Friday, November 14, 2003 12:31 PM
> Subject: Re: [e2e] TCP behaviour in the presence of reverse traffic
(Vegas,
> New Reno, Westwood+, Fast?)
>
>
> > Does that means the two ends need to sync. time or the
> > like?
> >
> >
> >
> > jing shen
> >
> >
> >  --- lz6 at njit.edu |¨¬??y???¨ºo> Hi, Saverio,
> > >
> > > The paper "An Enhanced Congestion Avoidance
> > > Mechanism for TCP Vegas"(IEEE
> > > COMMUNICATIONS LETTERS, VOL. 7, NO. 7, JULY 2003)
> > > provided a fix to the problem
> > > mentioned in your post. The basic idea of that paper
> > > is to use forward path
> > > delay to calculate queueing delay instead of using
> > > rtt to do so. But this
> > > requires TCP receiver to add "extra" timestamp in
> > > the ACK packet, which
> > > is "legal" as I remember.
> > >
> > > Li
> > >
> > >
> > > Quoting Saverio Mascolo <mascolo at poliba.it>:
> > >
> > > > The link below shows some results we have obtained
> > > by simulating (in
> > > > ns-2)
> > > > one TCP connection in the forward direction and
> > > one ON-OFF New Reno
> > > > TCP
> > > > connection going in the backward direction. The
> > > backward connection
> > > > excites
> > > > congestion along the ACK path of the forward
> > > connection.
> > > >
> > > > This scenario clearly shows that an rtt-based
> > > congestion detection
> > > > mechanism, such as the one of Vegas,  detects
> > > false congestion because
> > > > of
> > > > queuing in the  reverse path. This could be a
> > > problem also for Fast
> > > > TCP,
> > > > which employs rtt-based congestion detection too.
> > > >
> > > >
> > > >
> > >
> > http://www-ictserv.poliba.it/mascolo/TCP%20Westwood/Reverse/reverse.htm
> > > > -----------
> > > > Saverio Mascolo
> > > >
> > > >
> > >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
>
>
>