From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-33-ewr.dyndns.com (mxout-096-ewr.mailhop.org [216.146.33.96]) by lists.bufferbloat.net (Postfix) with ESMTP id 722942E0271 for ; Mon, 14 Mar 2011 06:56:06 -0700 (PDT) Received: from scan-32-ewr.mailhop.org (scan-32-ewr.local [10.0.141.238]) by mail-33-ewr.dyndns.com (Postfix) with ESMTP id BCEBC6FAB1D for ; Mon, 14 Mar 2011 13:56:05 +0000 (UTC) X-Spam-Score: 0.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 165.91.240.45 Received: from mail.ece.tamu.edu (mail.ece.tamu.edu [165.91.240.45]) by mail-33-ewr.dyndns.com (Postfix) with ESMTP id 7BBFC6F9E3B for ; Mon, 14 Mar 2011 13:56:01 +0000 (UTC) Received: from MAIL1.ece.tamu.local ([fe80::984c:4987:b6ac:2f06]) by mail2.ece.tamu.local ([fe80::3178:6467:d72f:204f%21]) with mapi id 14.01.0270.001; Mon, 14 Mar 2011 08:55:59 -0500 From: Narasimha Reddy To: "bloat@lists.bufferbloat.net" Thread-Topic: [Iccrg] Fwd: [Bloat] Taxonomy of various sender-side TCPs Thread-Index: AQHL4I4r0jxsO348AUSbNZHPdANMe5Qs3DRQ Date: Mon, 14 Mar 2011 13:55:58 +0000 Message-ID: <0B1D122344E6D0439C555B56CEA095381B7752B4@mail1.ece.tamu.local> References: <6210AF7E-3EB3-4199-A87B-A54B0F73A106@gmail.com> <2231D7DC-D58A-41F8-8A06-05FF4EEA0EA5@nokia.com> In-Reply-To: <2231D7DC-D58A-41F8-8A06-05FF4EEA0EA5@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 14 Mar 2011 07:57:31 -0700 Subject: [Bloat] FW: [Iccrg] Fwd: Taxonomy of various sender-side TCPs X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 13:56:06 -0000 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-ba= sed 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 gr= oup, 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@cs.ucl.ac.uk [mailto:iccrg-bounces@cs.ucl.ac.uk] On Beh= alf Of Lars Eggert Sent: Saturday, March 12, 2011 2:11 AM To: tcpm@ietf.org Extensions; iccrg@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 > Date: March 11, 2011 9:24:33 GMT+02:00 > To: > Subject: [Bloat] Taxonomy of various sender-side TCPs >=20 > There's a lot of literature about how various TCP congestion-control algo= rithms compare to each other, but there's not much in the way of 10,000 foo= t overviews. So this is an attempt to bring the most relevant data into on= e place. >=20 > I've sorted some common TCPs into groups in roughly ascending order of ag= gressiveness in the face of congestion, and considered how they might react= to the introduction of ECN at the bottleneck. >=20 > 1: Vegas. > Strategy: Fill the pipe, not the buffers. > Reaction to congestion: Backs off until RTT approaches baseline, ie. buf= fers empty. > Probable reaction to 1% ECN marking: Very little (but it doesn't need to= ). >=20 > 2: Illinois, Compound. > Strategy: Fill the pipe quickly, then probe the buffer slowly to avoid b= eing 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 l= ength. >=20 > 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 pa= ckets. >=20 > 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. >=20 > 5: CUBIC. > Strategy: Fill pipe and all buffers to capacity. This is the most aggre= ssive widely-deployed TCP. > Reaction to congestion: On packet loss, quickly re-probes for buffer cap= acity. > Probable reaction to 1% ECN marking: UNKNOWN. >=20 > Currently, CUBIC is the default TCP send-side algorithm in Linux. It see= ms likely that it will react correctly to ECN marking, but that a higher ra= te of marking may be needed to bring it down to a given buffering level. F= rom what I've read, SFB should be able to probe for the correct marking rat= e on a per-flow basis, which is nice. >=20 > On the subject of ECN, my impression is that YouTube currently doesn't en= able 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 site= s enable ECN if you ask for it. Personally, I think IPv6 and ECN should pr= obably go together - v6 gear is new or upgraded anyway so there shouldn't b= e any legacy problems. >=20 > - Jonathan >=20 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat