Re: [Bloat] Taxonomy of various sender-side TCPs

[Jonathan Morton <chromatix99@gmail.com>]

On 11 Mar, 2011, at 7:21 pm, Stephen Hemminger wrote:

>> 2: Illinois, Compound
> (Add in Yeah, Veno, and TCP-NV )
>> Strategy:  Fill the pipe quickly, then probe the buffer slowly to avoid being outcompeted.

I separated Veno to put it with Westwood, because there is almost no difference between Veno and Westwood, and they do not advance more rapidly than Reno in the uncongested regime.  I consider those two more aggressive than Reno only because they back off less if they believe the link is not congested, and that belief has a chance of being incorrect.

Meanwhile I considered Illinois and Compound to be less aggressive than Reno because they explicitly advance less rapidly in the congested regime, and back off at least as effectively as Reno does (well, the Linux implementation of Compound - it seems M$ screwed up their version).

I haven't read up on Yeah and NV (or TCP-fit) yet, so I can't classify them.  I'm also aware that a number of other aggressive TCPs designed for LFN throughput exist, but I can't be bothered enumerating them because they are useless - obsoleted by CUBIC in their intended application, and too aggressive for the wider Internet.

I do agree that TCPs which attempt to probe for minRTT have a weakness in this area, and Vegas is particularly weak because it relies very heavily on minRTT and is also very timid.  If the whole Internet used Vegas this wouldn't be a problem, but it gets outcompeted badly by literally everything else, especially the extra-aggressive TCPs like CUBIC.  So simply changing the send-side TCP congestion algorithm is insufficient to solve the whole problem, though some classes of users are seeing benefits from using Vegas despite it's flaws.

 - Jonathan