[Bloat] enabling outgoing tcp-ecn by default for ipv6 links

[Richard Scheffenegger]

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" <hannes at stressinduktion.org>
To: "Michael Richardson" <mcr at sandelman.ca>
Cc: <bloat at lists.bufferbloat.net>
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 <hannes at stressinduktion.org> 
>> >>>>> 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:
> <http://article.gmane.org/gmane.linux.network/253691>
>
>> 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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat