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

[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
> 
>