From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-33-ewr.dyndns.com (mxout-029-ewr.mailhop.org [216.146.33.29]) by lists.bufferbloat.net (Postfix) with ESMTP id 33DAB2E0322 for ; Thu, 24 Mar 2011 15:22:58 -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 8543A6F7054 for ; Thu, 24 Mar 2011 22:22:56 +0000 (UTC) X-Spam-Score: 0.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 134.157.0.129 Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mail-33-ewr.dyndns.com (Postfix) with ESMTP id 568276F6B18 for ; Thu, 24 Mar 2011 22:22:52 +0000 (UTC) Received: from hydrogene.pps.jussieu.fr (hydrogene.pps.jussieu.fr [134.157.168.1]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id p2OMMN3b064982 ; Thu, 24 Mar 2011 23:22:36 +0100 (CET) X-Ids: 168 Received: from lanthane.pps.jussieu.fr (lanthane.pps.jussieu.fr [134.157.168.57]) by hydrogene.pps.jussieu.fr (Postfix) with ESMTPS id 8753BC010C; Thu, 24 Mar 2011 23:22:22 +0100 (CET) Received: from jch by lanthane.pps.jussieu.fr with local (Exim 4.72) (envelope-from ) id 1Q2sv8-0001sd-CF; Thu, 24 Mar 2011 23:22:22 +0100 From: Juliusz Chroboczek To: richard References: <7imxklz5vu.fsf@lanthane.pps.jussieu.fr> <1300999472.12456.22.camel@amd.pacdat.net> Date: Thu, 24 Mar 2011 23:22:22 +0100 In-Reply-To: <1300999472.12456.22.camel@amd.pacdat.net> (richard@pacdat.net's message of "Thu, 24 Mar 2011 13:44:32 -0700") Message-ID: <7iipv8i2g1.fsf_-_@lanthane.pps.jussieu.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Miltered: at jchkmail.jussieu.fr with ID 4D8BC41F.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4D8BC41F.000/134.157.168.1/hydrogene.pps.jussieu.fr/hydrogene.pps.jussieu.fr/ Cc: bloat@lists.bufferbloat.net Subject: [Bloat] Packet drops, ECN and ECN+ [was: Thoughts on Stochastic Fair Blue] 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: Thu, 24 Mar 2011 22:22:58 -0000 >>> [1] Aleksandar Kuzmanovic. The power of explicit congestion >>> notification. In Proceedings of the 2005 conference on Applications, >>> technologies, architectures, and protocols for computer >>> communications. 2005. >> http://www.cs.northwestern.edu/~akuzma/doc/ecn.pdf >> >> appears to be the paper Juliusz cited. Indeed. See Figure 3, where you clearly see TCP's admission issues in the presence of ECN. Compare to Figure 2, where dropping at high congestion levels works around the issue (mostly). The authors of the paper suggest ECN marking SYN packets ("ECN+") to overcome this issue; my reading of their data is that dropping at high congestion levels is a good workaround. (And in case you wonder why the Wikipedia page on ECN agrees with me -- I wrote it.) >> I haven't had time to read the paper thoroughly, but I don't argue >> with this - if the marking probability goes above 1/2 then you >> probably have an unresponsive flow anyway. Hmm... for TCP, a mark/drop rate of 1/2 means that the fair share is slightly less than one packet per RTT, right? While not very good, that's quite likely to happen in The Real World, especially for low RTT and browsers opening multiple connections per page. (And yes, as far as I can see, transitioning to a low-latency Internet will require increasing mark/drop rates dramatically. I'll let you draw your own conclusions about whether we can fight bufferbloat without ECN.) > If nothing else, I take away from this paper that ECN should be applied > (at least) on servers (and they advocate clients and routers) to TCP > control packets (e.g. SYN and ACK packets) as well as data packets > despite the potential (accepted admin legend???) that this might be a > "bad thing" for reasons of aiding a potential SYN-flood attack vector. Unfortunately, other issues have been found with "ECN+" since the paper was published, which is why it is no longer being proposed for deployment on the Public Internet. It's been a couple years since I've looked at that stuff, though, so it might take me some work to find the reference. --Juliusz