Re: Vegas_cong_avoid patch redux (was Re: TCP Vegas Patch) LONG

paulr (reichp@ameritech.net)
Tue, 03 Aug 1999 20:30:24 -0500

Andi Kleen wrote:
>
> reichp@ameritech.net (paulr) writes:
>
> > For the "home" setup, I had a 28.8K modem with hardware
> > MNP-5 compression, and hardware error correction. I
> > disabled ppp_deflate, and used V-J header compression.
> > The MRU/MTU values for the link were the default values
> > for my ISP (MRU=1524, MTU=384, IIRC). The DCE baud rate
> > for the 28.8K dialup modem (ttyS1) was set at 115KB for
> > all tests.
>
> This sounds like you installed the Vegas patch on the
> _receiver_. Correct? I'll assume so.
^^^^^^^^^^^^
Correct.

>
> > 1. With the present TCP algorithm, long FTP downloads

-------------------<stuff snipped>----------------------

> > and MRU) combinations. I was never able to stream at
> > rates exceeding 2.7KBps.
>
> Reality check:
> Vegas only changes the TCP sending algorithms, nothing at the
> receiver side (ACK policy is not changed). So for bulk downloads at
> the receiver side it should make no difference. Did the sender in this
> case run the Vegas algorithm too? Did it behave differently with
> other senders not running Vegas?

The web page I referred to in my posting suggested that the reimple-
mented TCP_V_C algorithm performed better in the presence of *delayed
ACKS* (ACK/NACK policy??). I take that to mean that the algorithm
uses a different method of transmit/retransmit control when ACK/NACK
link signals are time-delayed due to net.congestion.

Cardwell mentioned in his paper that a part of the improvement resulted
from the use of usleep() for a more finely-grained timing algorithm.
Cardwell stated to the effect that a previous kernel implementation
of Reno-Vegas did not achieve its potential because of the rather
coarse granularirty of the 10ms (1 jiffy???) "clock tick" that was used....

I invite the interested reader to look at the paper which is published
at:

http://www.cs.washington.edu/homes/cardwell/linux-vegas/

The (indirect) quote above appeared on the first page, IIRC.

>
> > 2. Under the same conditions as (1), with the TCP-Vegas
> > algorithm enabled:
> >

----------------<stuff snipped>-------------------

> > no stalls. The download rate starts at about 3.5-4 KBps
>
> If this is only on the client this sounds bogus.

???

>
> > Or, perhaps, I should ask whether there is a relevant RFC-*
> > that would be "broken" by this algorithm. I'll be pleased to
> > contribute any additional testing anyone may be interested in.
>
> Strictly it would break RFC1122 which requires VJ, but this could
^^^^^^^^
Isn't Van-Jacobsen a header compression algorithm?
(I haven't read RFC-1122...)

> probably be overcome. The problem is that Vegas has not been
> extensively investigated yet on larger scale, what would happen
> if millions of Linux 2.4 Vegas boxes in 2001 cause congestion
> collapse on the internet ... ? [ok, this is a worst case scenario
> and not that likely, but one has to be careful: linux is not a
> research OS].

Point well taken!

>
> I'm currently working on some ways to increase performance of
> low speed/high buffering links, stay tuned.
>
> -Andi
> --
> This is like TV. I don't like TV.

I'd like to try out your new code. Anything to improve this
dial-up link would be a gift from heaven ;-)

Warm regards,

Paul

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Paul Reich   reichp[at]ameritech.net 


Q: How many Harvard MBA's does it
   take to screw in a lightbulb?


A: Just one. He grasps it firmly and
   the universe revolves around him.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/