[Bloat] TCP vegas vs TCP cubic

[Justin McCann]

On Wed, Feb 2, 2011 at 10:20 AM, Dave Täht <d at taht.net> wrote:
> Can I surmise that TCP cubic is like a dragster, able to go really fast
> in one direction down a straightaway, and TCP vegas more like an 80s
> model MR2, maneuverable, but underpowered?

There are some parameters to tune, essentially setting the number of
packets you want queued in the network at any one time (see
http://neal.nu/uw/linux-vegas/). I haven't messed with it much myself,
but you might try to increase those just a bit -- if Vegas
underestimates the queue size and the queue empties, you'll never get
the throughput. Ideally there would always be exactly one packet in
the bottleneck queue.

But I think your results are pretty much expected with Vegas, since it
uses the increase in queuing latency as an early congestion indicator.
If everyone used it, we may be better off, but other congestion
algorithms aren't fair to Vegas since they wait until there are packet
drops to notice congestion.


> On a failed hunch, I also re-ran the tests with a much larger
> congestion window:
>
> echo /proc/sys/net/core/rmem_max
> echo /proc/sys/net/core/wmem_max
>
> iperf -w8m -s
>
> To no net difference in effect.

I think you mean larger send/receive buffers instead of congestion
window? I'll bet the Vegas parameters are keeping the congestion
window smaller than your send/receive buffer sizes, so they aren't
limiting you in the first place, so no improvement.

The web100 patches (web100.org) are great for getting into the details
of how TCP is working. If you don't want to apply them yourself, you
can try the Live CD of perfSONAR-PS (http://psps.perfsonar.net/). It
might be useful to have an NDT
(http://www.internet2.edu/performance/ndt/) server running on your
home network, or use one at M-Lab. It doesn't need much resource-wise
but the web100 patches.

   Justin