From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id CA5D521F3B7 for ; Fri, 27 Feb 2015 07:55:35 -0800 (PST) Received: from srichardlxp2 ([46.245.200.65]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M5cpk-1XYIhP3IAy-00xbi7; Fri, 27 Feb 2015 16:55:31 +0100 Message-ID: <2C4C4344762441E5BD544597D47CA1C0@srichardlxp2> From: "Richard Scheffenegger" To: "Hannes Frederic Sowa" , "Michael Richardson" References: <20121227023728.GB19548@order.stressinduktion.org><18172.1356584697@sandelman.ca> <20121231173729.GB11700@order.stressinduktion.org> Date: Fri, 27 Feb 2015 16:52:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit 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.6157 X-Provags-ID: V03:K0:YjtkKrUL1HhhMXCmixcZE5/qpHMZmlRs6Jc0Ly/+X14MmUMJFhK k4u3jn499GOKsliFFhdfk9yrqnIsNbi/4wHHh2AesHDRX8Tr8+7qZ3SI8JvdjDYea9FKDP8 yfo2Yr4xYkdheZech+YuE/sO9QkNeg8aFpbFjEltdi9xRmmNdzmmbnoOZjQe71uri1dGymq vdaba8uDJKqeejVU22B2A== X-UI-Out-Filterresults: notjunk:1; Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] enabling outgoing tcp-ecn by default for ipv6 links 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, 27 Feb 2015 15:56:04 -0000 Hi, Disclaimer: As one of the co-authors, I can point you to Trammell, B., Kühlewind, M., Boppart, D., Learmonth, I., Fairhurst, G., & Scheffenegger, R. Enabling Internet-Wide Deployment of Explicit Congestion Notification. http://www.tik.ee.ethz.ch/file/55c228c89bd841b6f85542c58781b2dc/ecn-pam15.pdf For Linux, making that change shoudl be relatively save for the client - if it features a robust fall-back mechanism (if the initial two SYN,ECE,CWR are not responded two, Linux will try a regular SYN; patch is available, haven't checked if it went mainline [1]). So, the impact of a blackholed ECN path/destination should be nothing more than longer session handshake. However, going from a few 10s of ms, to a few seconds worst case, for each TCP session would be noticable to users... Unfortunately, enabling ECN on the TCP layer itself won't automagically *really* enable ECN... While the TCP signalling seems to be quite reasonable (as long as you are not trying to talk to the majority of the top Alexa100 sites... you know who you are), the IP ECN signaling seems to be broken in a larger scale - but less so for IPv6. See Section 4.2. The number of (non customer edge) devices that actually mark seems to be near zero (indicating that even when (W)RED or any other AQM has been enabled, ECN marking has not... While the number of meddleboxes that actively prevent IP ECN signalling seems staggering with all kinds (including the ones you cann't readily think of) of odd behavior. However, since this is a chicken-and-egg problem, if the ECN signal loop on Layer 4 is enabled (TCP, SCTP, DCCP all support ECN signal feedback in L4), I'm all for enabling this on the end hosts, and push the meddlebox vendors to fix their gear - many of which haven't noted that IPv4 TOS went out of fashion near 20 years ago (now DiffServ / ECN). Hope this helps! Best regards, Richard [1] Kuehlewind, M. and B. Trammell, "A Mechanism for ECN Path Probing and Fallback", draft-kuehlewind-tcpm-ecn- fallback-01 (work in progress), September 2013. ----- Original Message ----- From: "Hannes Frederic Sowa" To: "Michael Richardson" Cc: Sent: Monday, December 31, 2012 6:37 PM Subject: Re: [Bloat] enabling outgoing tcp-ecn by default for ipv6 links > Hello! > > On Thu, Dec 27, 2012 at 12:04:57AM -0500, Michael Richardson wrote: >> >>>>> "Hannes" == Hannes Frederic Sowa >> >>>>> writes: >> Hannes> I am thinking about advancing the ipv4/tcp_ecn knob in linux >> to >> Hannes> distinguish between ipv4 and ipv6 transport and enable ecn >> signaling >> Hannes> on outgoing ipv6 connections by default (for me, at least). I >> am >> Hannes> currently doing so with the help of iptables (echo 1 > >> tcp_ecn and -j >> Hannes> ECN --ecn-tcp-remove). >> >> I think it's definitely worth splitting the sysctl, so that we can at >> least learn if it can fly in v6 land. I'd turn it on. > > I had some spare time and posted a patch: > > >> I suggest that doing this without a way to report on a path/IP/vendor >> that is screwing things up is a mistake. >> >> http://urchin.earth.li/ecn/ >> >> went inactive again in 2011. > > Will look into this now. > > Greetings, > > Hannes > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat