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

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

There may be a new contender on the block, "TCP-fit", which is
"a novel congestion control algorithm targeting both emerging
wireless networks such as LTE, WiMax, Wi-Fi and HSPA and high speed long
delay (high BDP) networks. "

The knobs they are twisting seem to be appropriate for these sorts of
networks, and the results very interesting.

See paper at:

http://media.cs.tsinghua.edu.cn/~multimedia/tcp-fit/papers/mobicom10_demo.pdf

And more details at:

http://media.cs.tsinghua.edu.cn/~multimedia/tcp-fit/

(I've cc'd the authors in the hope they can tell us more about it.)

Stephen Hemminger <shemminger@vyatta.com> writes:

> On Fri, 11 Mar 2011 09:24:33 +0200
> Jonathan Morton <chromatix99@gmail.com> wrote:
>
>> There's a lot of literature about how various TCP congestion-control algorithms compare to each other, but there's not much in the way of 10,000 foot overviews.  So this is an attempt to bring the most relevant data into one place.
>
> The literature often doesn't tell what is wrong with each one.
>
>> 1: Vegas.
>> Strategy:  Fill the pipe, not the buffers.
>> Reaction to congestion:  Backs off until RTT approaches baseline, ie. buffers empty.
>> Probable reaction to 1% ECN marking:  Very little (but it doesn't need to).
> Weaknesess: Sensitive to variations in RTT and reverse path congestion; underperforms
> when competing against loss based congestion control. Does not detect increase in
> bandwidth ie recovers slowly from congestion clearing.
>
>
>> 2: Illinois, Compound
> (Add in Yeah, Veno, and TCP-NV )
>> Strategy:  Fill the pipe quickly, then probe the buffer slowly to avoid being outcompeted.
>> Reaction to congestion:  Backs off firmly on packet loss, then quickly re-probes for the pipe.
>> Probable reaction to 1% ECN marking:  Window should stabilise near pipe length.
> Weaknesses: Not widely tested. Microsoft disabled Compound.
>
>
>> 3: Reno (and subtle variations thereof).
>> Strategy:  Avoid congestion collapse in a simple, standardisable way.
>> Reaction to congestion:  Halves the window on packet loss.
>> Probable reaction to 1% ECN marking:  Window should stabilise near 100 packets.
> Weaknesses: Unstable at higher speed and long delay links.
>
>
>> 4: Westwood+.
>> Strategy:  Distinguish congestion loss from random channel loss.
>> Reaction to congestion:  Identical to Reno.
>> Probable reaction to 1% ECN marking:  Identical to Reno.
>
>
>> 5: CUBIC.
>> Strategy:  Fill pipe and all buffers to capacity.  This is the most aggressive widely-deployed TCP.
>> Reaction to congestion:  On packet loss, quickly re-probes for buffer capacity.
>> Probable reaction to 1% ECN marking:  UNKNOWN.
>
> Also any algorithm that uses RTT estimation ends up having to use higher (sub tick)
> resolution time stamps. On many platforms this is cheap (TSC 0, HPET 1usec) but on
> older hardware or other architectures it can be expensive (several usec's per packet).
>
>> 
>> Currently, CUBIC is the default TCP send-side algorithm in Linux.  It seems likely that it will react correctly to ECN marking, but that a higher rate of marking may be needed to bring it down to a given buffering level.  From what I've read, SFB should be able to probe for the correct marking rate on a per-flow basis, which is nice.
>> 
>> On the subject of ECN, my impression is that YouTube currently doesn't enable it, but a one-man company I recently downloaded some stuff from does.  I wonder if there's any reliable data on how many of the most popular sites enable ECN if you ask for it.  Personally, I think IPv6 and ECN should probably go together - v6 gear is new or upgraded anyway so there shouldn't be any legacy problems.
>
> Even TCP window scaling is problematic. Many consumer bits of gear are seriously
> broken. I have had to turn off WS on my laptop to deal with hotel and conference
> wireless front ends.

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