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

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

[Hannes Frederic Sowa]

Hello!

I am thinking about advancing the ipv4/tcp_ecn knob in linux to
distinguish between ipv4 and ipv6 transport and enable ecn signaling
on outgoing ipv6 connections by default (for me, at least). I am
currently doing so with the help of iptables (echo 1 > tcp_ecn and -j
ECN --ecn-tcp-remove).

Currently linux does only respond to ecn signaling but does not actively
try to signal ecn capabilities by default because of the high(?) fail rate
of connections in ipv4 land. I wonder if this situation has improved in
ipv6 world because I assume most providers have upgraded their gear in
recent times to support this shiny new protocol.

Does someone know about recent data if such a change would be reasonable?

Btw, has someone looked at RFC5562 - Adding Explicit Congestion
Notification (ECN) Capability to TCP's SYN/ACK Packets;
experimental? Adam Langley has provided a patch for linux enabling ecn on
syn/ack packets some while ago[1].  This seems to be a nice addition but
I fear for new problems arising because of buggy routers. Perhaps after the
retransmit of the initial syn without the ecn-capable codepoint one could
mark this connection as non-ecn compatible in the destination cache to
reduce further latencies on follow-up syns (kind of path ecn discovery).

Greetings,

  Hannes

[1] https://www.ietf.org/mail-archive/web/tcpm/current/msg03988.html

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

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 1113 bytes --]


>>>>> "Hannes" == Hannes Frederic Sowa <hannes@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 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.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 


[-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --]

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

[Hannes Frederic Sowa]

On Thu, Dec 27, 2012 at 12:04:57AM -0500, Michael Richardson wrote:
> >>>>> "Hannes" == Hannes Frederic Sowa <hannes@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 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.

What data would be needed? Some website where one could copy&paste
traceroutes (with tcp/ecn enabled)? A reprobe mechanism? Some
correlation/dependence mechanisms?

Something like this could be a neat experiment for RIPE Atlas. It would
be nice to have such tests in the various implementations of looking
glass, too.

Greetings,

  Hannes

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

[Hannes Frederic Sowa]

Hello!

On Thu, Dec 27, 2012 at 12:04:57AM -0500, Michael Richardson wrote:
> >>>>> "Hannes" == Hannes Frederic Sowa <hannes@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

Re: [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@stressinduktion.org>
To: "Michael Richardson" <mcr@sandelman.ca>
Cc: <bloat@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@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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat 

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

[Rick Jones]

On 12/26/2012 06:37 PM, Hannes Frederic Sowa wrote:
> Hello!
>
> I am thinking about advancing the ipv4/tcp_ecn knob in linux to
> distinguish between ipv4 and ipv6 transport and enable ecn signaling
> on outgoing ipv6 connections by default (for me, at least). I am
> currently doing so with the help of iptables (echo 1 > tcp_ecn and -j
> ECN --ecn-tcp-remove).

Any particular reason you aren't willing/able to just flip the 
net.ipv4.tcp_ecn sysctl to turn it on for both?  FWIW, that is what I 
have done on netperf.org, with an eye towards seeing what ceases 
working.  Thusfar things seem OK.  At least I've not had anyone contact 
me to say "Hey! Why can't I reach netperf.org!" ...

happy benchmarking,

rick jones

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

[Hannes Frederic Sowa]

On Thu, Dec 27, 2012 at 12:10:35PM -0800, Rick Jones wrote:
> On 12/26/2012 06:37 PM, Hannes Frederic Sowa wrote:
> >I am thinking about advancing the ipv4/tcp_ecn knob in linux to
> >distinguish between ipv4 and ipv6 transport and enable ecn signaling
> >on outgoing ipv6 connections by default (for me, at least). I am
> >currently doing so with the help of iptables (echo 1 > tcp_ecn and -j
> >ECN --ecn-tcp-remove).
> 
> Any particular reason you aren't willing/able to just flip the 
> net.ipv4.tcp_ecn sysctl to turn it on for both?  FWIW, that is what I 
> have done on netperf.org, with an eye towards seeing what ceases 
> working.  Thusfar things seem OK.  At least I've not had anyone contact 
> me to say "Hey! Why can't I reach netperf.org!" ...

But ecn is not employed as long as your clients won't signal ecn
support, too. So there is nothing to break.

I have a squid server where I actually needed to disable outgoing ecn
support because of reachability problems to a german university last
year. This seems to be fixed this year (and they have enabled ipv6,
thus supporting my assumption :) ). I suppose there are still many
ecn-blackholes rendering enabling ecn by default unlikely. I am a bit
more confident this could work some day for ipv6.

Greetings,

  Hannes