[lkml]   [1999]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] TCP Vegas implementation available

On Tue, 20 Jul 1999, Rik van Riel wrote:

> Would it help for us poor PPP over analog phone folks who
> can only use up to 1/4th of the available bandwith with the
> current TCP stack?

For scenarios where the performance of long TCP flows is suffering because
traditional TCP congestion control is driving up the queues on the modem
to the point of loss and suffering massive timeouts, Vegas should help by
keeping queues shorter, keeping RTTs lower, and reducing loss. I've added
some example traces of Vegas vs non-Vegas traffic over an emulated 28Kbps
link at:

If the losses are happening at a congested bottleneck in the middle of the
network (say, at the local ISP's access link), then it's more complicated.
If all the flows at the bottleneck were using Vegas then everything would
be just groovy. But if there are any competing Reno flows, they are likely
to erase much of the gains by filling up the queues at that bottleneck and
keeping the loss rate high.

I don't have direct access to any paths with the sort of performance
problems you're experiencing. If you have sender-side tcpdump traces of
these transfers, i'd be happy to take a look at them. Or if anyone has a
machine that's connected often over a slow link and they can turn on their
inetd discard service or run a netperf server, i'd be happy to run some
benchmarks and look into this some more.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:53    [W:0.097 / U:10.732 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site