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

[d@taht.net (Dave Täht)]

Jonathan Morton <chromatix99@gmail.com> writes:

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

Several freeswitch (VOIP) folk said they were using Vegas for the TCP
side of their servers due to it's lower impact for command and control
applications while lots of RTP streams were running. One claimed that
Vegas is what google uses, but that's unconfirmed. Discussion here
(including recording)

http://www.bufferbloat.net/projects/bloat/wiki/Bufferbloat_and_Freeswitch_Conference_Call_March_9

Also, for those new to the list, there was a huge LEDBAT thread here
earlier and interest in embedding that into the kernel.

https://lists.bufferbloat.net/pipermail/bloat/2011-February/000025.html

And split-tcp solutions were discussed here:

https://lists.bufferbloat.net/pipermail/bloat/2011-February/000068.html

>
>  - Jonathan
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

-- 
Dave Taht
http://nex-6.taht.net