Messages in this thread | | | Date | Wed, 4 Aug 1999 22:55:08 -0700 (PDT) | From | Neal Cardwell <> | Subject | Re: Vegas_cong_avoid patch redux (was Re: TCP Vegas Patch) LONG |
| |
> The problem is that Vegas has not been > extensively investigated yet on larger scale,
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/
| |