From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-34-ewr.dyndns.com (mxout-091-ewr.mailhop.org [216.146.33.91]) by lists.bufferbloat.net (Postfix) with ESMTP id EEC602E011F for ; Fri, 11 Mar 2011 10:31:46 -0800 (PST) Received: from scan-32-ewr.mailhop.org (scan-32-ewr.local [10.0.141.238]) by mail-34-ewr.dyndns.com (Postfix) with ESMTP id 498F070B068 for ; Fri, 11 Mar 2011 18:31:45 +0000 (UTC) X-Spam-Score: 0.1 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 75.145.127.229 Received: from gw.co.teklibre.org (75-145-127-229-Colorado.hfc.comcastbusiness.net [75.145.127.229]) by mail-34-ewr.dyndns.com (Postfix) with ESMTP id 3FAC270A210 for ; Fri, 11 Mar 2011 18:31:41 +0000 (UTC) Received: from cruithne.co.teklibre.org (unknown [IPv6:2002:4b91:7fe5:1::20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cruithne.co.teklibre.org", Issuer "CA Cert Signing Authority" (verified OK)) by gw.co.teklibre.org (Postfix) with ESMTPS id CCE6D5E9C7 for ; Fri, 11 Mar 2011 11:31:40 -0700 (MST) Received: by cruithne.co.teklibre.org (Postfix, from userid 1000) id 3CA12120844; Fri, 11 Mar 2011 11:31:39 -0700 (MST) From: d@taht.net (Dave =?utf-8?Q?T=C3=A4ht?=) To: Jonathan Morton Organization: Teklibre - http://www.teklibre.com References: <6210AF7E-3EB3-4199-A87B-A54B0F73A106@gmail.com> <20110311092157.23dea5e8@nehalam> <878vwlr0rl.fsf@cruithne.co.teklibre.org> Date: Fri, 11 Mar 2011 11:31:39 -0700 In-Reply-To: (Jonathan Morton's message of "Fri, 11 Mar 2011 20:21:23 +0200") Message-ID: <87oc5hpkz8.fsf@cruithne.co.teklibre.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Stephen Hemminger , bloat@lists.bufferbloat.net Subject: Re: [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 18:31:47 -0000 Jonathan Morton writes: > On 11 Mar, 2011, at 8:05 pm, Dave T=C3=A4ht wrote: > >>> 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. >>=20 >> I agree, but lack data. What TCP algorithms are available in the IPv6 >> stack on Linux? I know SFB works with both ipv4 and ipv6... > > AFAIK, the TCP congestion algorithms are all implemented independently > of IP version, so even the exotic ones are available in v6 already. I > don't think they need to look at the addresses or port numbers. So the echo vegas > /proc/sys/net/ipv4/tcp_congestion_control knob applies to both v4 and v6? I have been thinking that we needed per-device TCP/IP algorithms. An internal interface differs in requirements from an external gateway, which in turn differs from several different kinds of wireless interfaces. > > The qdiscs are also relatively protocol-independent in themselves, I > think. Classifiers are mostly what need to examine the addresses and > so on.=20=20 Since the state of ipv6 and encapsulated traffic shaping is so poor (non-existent), I've been working on pulling together a good classifier in my Cruft repository, when I have time. I hope we can gather more shaper people together to work on improving matters for bufferbloat/ECN/advanced shapers in the coming weeks, now that we have the debloat-testing tree to work against and work ongoing in openwrt. > In particular, I'm pretty sure SFQ works, and that *does* > depend on flow identification, so there is no reason why a competent > implementation of nRED or SFB wouldn't. Testing... We really could use a good example tc implementation of SFB and HTB at minimum to be playing with. >> ECN has been enabled on kernel org for 8+ years. > > Which is great, except that ECN is still not universally enabled > client-side, so many problems with random ISPs are still masked until > someone starts doing something unusual. Lots O Testing needed... If you haven't already seen the recent MIT study on ECN, it's here: http://mirrors.bufferbloat.net/Talks/AIMS2011/bauer-ecn-aims-2011.pdf > > More relevantly, what is the situation with Windows (XP/Vista/7), > MacOS X, and the prominent mobile OSes (Android, iOS)? Do they > attempt ECN negotiation already? What happens if they encounter a > black hole while doing so? I've experienced some issues with the Iphone and ECN, but I have so many other balls/kernels/tools/drivers in the air regarding wireless that I have not been able to track it down. > > - Jonathan > --=20 Dave Taht http://nex-6.taht.net