Re: [Bloat] TCP vegas vs TCP cubic

[Dave Taht <dave.taht@gmail.com>]

re: vegas
On Wed, Feb 2, 2011 at 9:05 AM, Justin McCann <jneilm@gmail.com> wrote:

> 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.

After talking to the original author (who suggested that I also look
at TCP veno) ...

I suspect that Vegas is actually doing a *great* job measuring queuing
latency, which is artificially high due to the network path under test
doing 13 TX_Retries.

I did some testing on a de-bloated device and vegas actually did
slightly better than cubic (noted over on bloat-devel) but will need
to either get my radio speed ratcheted down or update more radios to a
de-bloated condition to test further.


-- 
Dave Täht