[Bloat] FW: [Iccrg] Fwd: Taxonomy of various sender-side TCPs

[Narasimha Reddy]

Our work on PERT might interest this thread.

http://www.ece.tamu.edu/~reddy/papers/sigcomm07.pdf

PERT is a sender side modification to convert TCP into employing a delay-based response.
It has been designed now to be able to co-exist with TCP:
http://www.ece.tamu.edu/~reddy/papers/iwqos2008.pdf

You can find a comparative performance of some of these protocols in Kiran Kotla's thesis (particularly the buffer buildup part might interest this group, Chapter 7, starting on page46):
http://cegroup.ece.tamu.edu/techpubs/2008/TAMU-ECE-2008-02.pdf

You can find PERT's video delivery performance results at:
http://www.ece.tamu.edu/~reddy/papers/pfldnet10.pdf

Regards,
Reddy

-----Original Message-----
From: iccrg-bounces at cs.ucl.ac.uk [mailto:iccrg-bounces at cs.ucl.ac.uk] On Behalf Of Lars Eggert
Sent: Saturday, March 12, 2011 2:11 AM
To: tcpm at ietf.org Extensions; iccrg at cs.ucl.ac.uk list
Subject: [Iccrg] Fwd: [Bloat] Taxonomy of various sender-side TCPs

FYI, there is an active thread on the bufferbloat list in response to this email that some of you might want to be aware of or join.

Begin forwarded message:

> From: Jonathan Morton <chromatix99 at gmail.com>
> Date: March 11, 2011 9:24:33 GMT+02:00
> To: <bloat at lists.bufferbloat.net>
> Subject: [Bloat] Taxonomy of various sender-side TCPs
> 
> 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.
> 
> I've sorted some common TCPs into groups in roughly ascending order of aggressiveness in the face of congestion, and considered how they might react to the introduction of ECN at the bottleneck.
> 
> 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).
> 
> 2: Illinois, Compound.
> 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.
> 
> 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.
> 
> 4: Veno, 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.
> 
> 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.
> 
> - Jonathan
> 
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat