From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-33-ewr.dyndns.com (mxout-076-ewr.mailhop.org [216.146.33.76]) by lists.bufferbloat.net (Postfix) with ESMTP id 9180B2E0054 for ; Fri, 25 Mar 2011 12:28:02 -0700 (PDT) Received: from scan-31-ewr.mailhop.org (scan-31-ewr.local [10.0.141.237]) by mail-33-ewr.dyndns.com (Postfix) with ESMTP id 6CE146F6F63 for ; Fri, 25 Mar 2011 19:28:02 +0000 (UTC) X-Spam-Score: 0.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 213.165.64.22 Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by mail-33-ewr.dyndns.com (Postfix) with SMTP id 610426F6CCA for ; Fri, 25 Mar 2011 19:27:58 +0000 (UTC) Received: (qmail invoked by alias); 25 Mar 2011 19:27:57 -0000 Received: from unknown (EHLO srichardlxp2) [213.143.107.142] by mail.gmx.net (mp036) with SMTP; 25 Mar 2011 20:27:57 +0100 X-Authenticated: #20720068 X-Provags-ID: V01U2FsdGVkX1/LsQpFgFXLEQkC7kIsOnpqcygc6IfmuZXAj24QeO dRkpnExMCv8t4/ Message-ID: From: "Richard Scheffenegger" To: "Juliusz Chroboczek" , "richard" References: <7imxklz5vu.fsf@lanthane.pps.jussieu.fr><1300999472.12456.22.camel@amd.pacdat.net> <7iipv8i2g1.fsf_-_@lanthane.pps.jussieu.fr> Date: Fri, 25 Mar 2011 20:22:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Y-GMX-Trusted: 0 Cc: bloat@lists.bufferbloat.net Subject: Re: [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: Fri, 25 Mar 2011 19:28:03 -0000 IIRC, the IBM AIX5L TCP stack actually sets ECT0 for all TCP segments (pure ACK, SYN, SYNACK) when ECN is enabled, not only data segments... ----- Original Message ----- From: "Juliusz Chroboczek" To: "richard" Cc: Sent: Thursday, March 24, 2011 11:22 PM Subject: [Bloat] Packet drops,ECN and ECN+ [was: Thoughts on Stochastic Fair Blue] >>>> [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 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat