>
>Jeff Roberson <nomad@nop.aliensystems.com> writes:
>
>> Just out of curiosity is the current NetBSD TCP/IP stack based on tcp
>> vegas, or reno?  I saw a sample implimentation of TCP Vegas on the web
>> which was implimented in netbsd 1.0.
>
>I don't recall the details, but according to Van Jacobsen, TCP Vegas
>flow control is not stable on overloaded networks (i.e. the greater
>internet), and is thus not desirable.

Yep, Van claims that (I've heard him!)  but its not entirely accurate.
Problem is that in the absence of ECN or early drop, TCP-Reno (or for
that matter NewReno) both converge on filling all buffers along the
path up to the bottleneck link.  The available studie (the original
Arizona paper in SIGCOMM 94 and the the, uh, SIGCOMM 96 BSD-based
reimplentation) show that Vegas acutally congests less than Reno does,
is sliglhty fairer than Reno, etc., etc.

Vegas loses because it relies on someone configuring two parameters,
\alpha and \beta, to values suitable for each path. No-one's figured
out how to do that automatically. And RED, and someday ECN, improve
TCP-Reno's behaviour to where the Vegas improvements are kind of moot.