In message <Pine.GSO.4.61.0506040236370.20116@rfhpc8317>Hubert Feyrer writes
>On Fri, 3 Jun 2005, Rui Paulo wrote:
>>> - TCP-NewReno
>>
>> net.inet.tcp.newreno
>> net.inet6.tcp6.newreno
>
>Hrm. This reminds me of our state of sysctl (non)documentation. :-(
>
>
>>> - TCP-Vegas
>> See http://catarina.usc.edu/yaxu/Vegas/Html/vegas.html.
>
>Looking at the patch and NetBSD, it seems that this was never included. 

Isn't that URL a pointer to Peter Danzig's work?

>Can someone confirm this?

Correct. It was not included. I suppose it could be resurrected if
there is interest. But it should definitely not be enabled by default.
Personally I don't see any reason (marketing brag^h^h^h^hchecklists
aside), to include TCP-Vegas.

As best I recall, TCP-Vegas never proceeded much beyond experimental
status, largely because its performance depends on two critical
parameters (called alpha and beta in the TCP-Vegas literature).
Nobody really knows (or knew, its been a decade) how to tune those two
crucial parameters for different link speeds -- let alone how to get
TCP-Vegas to automatically tune the parameters itself.

That's what I recall Prof.  Danzig saying in the corridors at SIGCOMM
ten years ago; anyone interested could check Citeseer to see if
there's newer news than Peter Danzig et al's replication of the
original Arizona results (SIGCOMM 95), or Mark Almann et al's paper
from circa 1996, analyzing and comparing TCP-Vegas and Reno.

(If memory seves, _the_ significant difference was that Reno oscillates
around a send rate where all the buffers up to the bottleneck router
fill, then you experience lots of drop; whereas Vegas steady-state doesn't
fill nearly so many router buffers.  But all that work predates RED
and FRED and ECN. I dunno if anyone has investigated Vegas-like send
policies with an FRED or ECN network. Maybe ns2 has all the pieces?)

OTOH, I'm sure Linux has code, but I bet its not enabled by default.
I wonder how many people actually use it.