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" <han...@stressinduktion.org>
To: "Michael Richardson" <m...@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 <han...@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
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
