Re: TCP congestion graphs (2.6.19-rc4)

[David Miller <davem@davemloft.net>]

From: Stephen Hemminger <shemminger@osdl.org>
Date: Tue, 31 Oct 2006 16:10:07 -0800

> On Tue, 31 Oct 2006 15:25:16 -0800
> "Xiaoliang (David) Wei" <davidwei79@gmail.com> wrote:
> 
> > It seems that the default Vegas alpha parameter in the rc4 is 1...
> > 
> > I observed similar situation with the NS2Linux simulator (with 2.6.16
> > code) and found that if alpha=1, delayed ack will make it broken
> > (keeping cwnd very low without real congestion)
> > 
> > See details at http://www.cs.caltech.edu/%7Eweixl/technical/ns2linux/known_linux/index.html#vegas
> > 
> > (Basically alpha==1 means Vegas seeks to see a delay of about 1 packet
> > worth. With delayed ack, 1 packet worth of delay is common even with
> > no congestion.)
> > 
> > To make Vegas work, I'd suggest to raise alpha to at least 2 or 3.
> > (and beta has to be at least as large as alpha.)
> > 
> > -David
> > 
> 
> I ran with the current default:
> 	alpha = 1 (scaled 2)
> 	beta  = 3 (scaled 6)
> 	gamma = 1 (scaled 2)

Testing with alpha=2 and beta=4 would be interesting.

Brakmo and Peterson don't see this delayed ACK behavior in their tests
in the original Vegas paper.  I read through it a few times and I see
no explicit mention of whether they had delayed ACKs enabled or not in
any of there tests.

I seem to recall that it was very popular around that time to analyze
TCP changes with delayed ACKs disabled since it made the results
easier to analyze (which in my opinion invalidates any such results,
since in the real world you never run with delayed ACKs off).  So
perhaps the Vegas folks were doing something similar and just didn't
think it was worth mentioning :-)

BTW, Stephen, can you give a short HOWTO on how you generate those
graphs, given a tcpdump trace?  Thanks a lot.