From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-24-ewr.dyndns.com (mxout-047-ewr.mailhop.org [216.146.33.47]) by lists.bufferbloat.net (Postfix) with ESMTP id 3A5122E0601 for ; Thu, 10 Mar 2011 23:24:42 -0800 (PST) Received: from scan-21-ewr.mailhop.org (scan-21-ewr.local [10.0.141.243]) by mail-24-ewr.dyndns.com (Postfix) with ESMTP id 8BDBF5CD804 for ; Fri, 11 Mar 2011 07:24:41 +0000 (UTC) X-Spam-Score: -1.0 (-) X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 209.85.215.171 Received: from mail-ey0-f171.google.com (mail-ey0-f171.google.com [209.85.215.171]) by mail-24-ewr.dyndns.com (Postfix) with ESMTP id 5B7EC5CC82F for ; Fri, 11 Mar 2011 07:24:36 +0000 (UTC) Received: by eydd26 with SMTP id d26so981696eyd.16 for ; Thu, 10 Mar 2011 23:24:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=Hm91JeixdloFaNJT03J6cHiEcK8CASUpZDHCHE1x/Bw=; b=EgJOETRKHKbU8581V8sqk8DmTwhcpoEfY9SZia/4j1rIhXIKpG2fDXnXv4Nrdfyi00 qOLvB9lHTEcA2N9Nc0jXXWTOqEMyaIWMliegahEnb5J1UlWacjOTd/pIFi9ZpqNZ7kAs +C7d+CUQvyz00zPAJAlTpuPq24IdJsiXRQzsA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=BDcHP8wdktNfymV1xKdgzz6LnHnl+bgwmOEhAi7Va+1KXQ2r3JSkAPsWt2oNkJRQAr AjL2Mh3mUpZ4U+7PNxebcPRsnCV4gDlj+zSvZU/1wbY4M2TrwhJoo/9qqoXf+M52675J jpzyx9HSanHNBJZXSuzs7iIdmK6G5q6AP4dCM= Received: by 10.14.13.143 with SMTP id b15mr6070688eeb.46.1299828275563; Thu, 10 Mar 2011 23:24:35 -0800 (PST) Received: from [192.168.239.42] (xdsl-83-150-84-172.nebulazone.fi [83.150.84.172]) by mx.google.com with ESMTPS id b52sm3185147eei.19.2011.03.10.23.24.34 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 Mar 2011 23:24:35 -0800 (PST) From: Jonathan Morton Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Mar 2011 09:24:33 +0200 Message-Id: <6210AF7E-3EB3-4199-A87B-A54B0F73A106@gmail.com> To: bloat@lists.bufferbloat.net Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [Bloat] 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: Fri, 11 Mar 2011 07:24:42 -0000 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. =46rom 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