While it is true that there is no large-scale implementation experience
with Vegas, and there is no substitute for such experience, it has been
studied fairly extensively analytically and through simulation. A few of
the papers linked to on:
http://www.cs.washington.edu/homes/cardwell/linux-vegas/
show analytic proofs of its basic stability and fairness, for example.
I think one advantage of having a Linux Vegas implementation out there is
that we can start to accumulate some more of that critical real-world
experience.
> 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].
I'm willing to bet that Vegas would never lead to congestion collapse. The
reason is that Vegas is by its very nature more conservative than VJ-style
congestion control. If you give a VJ-style stack and a Vegas stack the
same inputs (RTT, packet loss, etc), the Vegas stack will always react
more conservatively, ie, send at a slower rate, than the VJ stack.
In fact, when VJ TCP and Vegas TCP send through the same congested
bottleneck, the VJ TCP will almost always be far more aggressive than the
Vegas sender. The reason is that VJ TCP tends to keep many packets queued,
whereas Vegas tends to keep only a handful queued. And since a flow's
throughput is basically proportional to the fraction of the queue slots it
occupies, the VJ flow will send far faster than the Vegas flow. I've
observed this experimentally, as have others before me (see Ahn, Danzig,
Liu, and Yan. SIGCOMM '95, and Mo, La, Anantharam, Walrand. INFOCOM '99).
So congestion collapse due to Vegas over-sending is not the real risk. The
real risk is that nice Vegas senders will be crowded out by aggressive VJ
senders when they share a congested bottleneck. [If/when/where RED is
deployed, it will even the odds a bit, since it will keep VJ flows from
queuing so many packets.]
I think the bottom line for now is that when you are using TCP over a path
where you aren't competing with VJ-style TCP flows at a congested
bottleneck link, Vegas is a fine way to go.
Neal
-
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/