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

[=?gb2312?q?Jing=20Shen?=]

Does that means the two ends need to sync. time or the
like?



jing shen


 --- lz6 at njit.edu µÄÕýÎÄ£º> 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