From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Tue, 31 Oct 2006 16:10:07 -0800
> On Tue, 31 Oct 2006 15:25:16 -0800 > "Xiaoliang (David) Wei" <[EMAIL PROTECTED]> 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. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
