Subject: [aqm] ECN support and usage on the Internet

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 19 Mar 2013 09:04:32 +0100

Hi everybody,

we just published a paper on the state of ECN support and usage on the 
Internet. We performed a similar study than Bauer et al., probing webservers 
to get the current status. We found that about 30% of webservers (by Sep'12) 
support ECN. Unfortunately, still we saw a failure rate of 9% when checking
end-2-end path ECN usability (setting CE). Additionally, we analyzed NetFlow 
data to get a lower bound for the ECN usage which was below 1%. Then we also 
had a look at IPv6 (47,5% ECN support). At the same time we also monitored an 
increase in general IPv6 support on webserver over the IPv6 launch day last 
year (-> check the paper).

Kühlewind, M.; Neuner, S.; Trammell, B.: On the state of ECN and TCP Options 
on the Internet. Proceedings of the 14th Passive and Active Measurement 
conference (PAM 2013), Hong Kong, March 2013.

http://www.ikr.uni-stuttgart.de/Content/Publications/Archive/Kue_PAM13_40160.pdf

Do we need to start a campaign to further encourage greater ECN support (also 
of network providers)? Asking the content providers on the list(s): What are 
the reasons to not enable ECN support?

Mirja

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 19 Mar 2013 10:22:52 +0100 (CET)

On Tue, 19 Mar 2013, Mirja Kühlewind wrote:

> Do we need to start a campaign to further encourage greater ECN support 
> (also of network providers)? Asking the content providers on the 
> list(s): What are the reasons to not enable ECN support?

Let me speculate:

It's not on by default in Windows. There is little reason to turn it on, 
because "nobody" acts on ECN, and nobody acts on ECN because there is no 
demand for AQM, and even if there was AQM, it would most likely not be ECN 
enabled.

I tried enabling ECN back in 2001 but saw major breakage. I re-enabled ECN 
again around 2008 or so <http://seclists.org/nanog/2008/Nov/250> and 
investigated, and at least the vendors I talked to didn't show much 
interest. I've been running with ECN on ever since and have not 
experienced any breakage I could trace back to ECN usage. This is hopeful.

I believe the Bufferbloat discussions and increased interest in AQM on the 
customer access link will increase interest in ECN as well, so the 
important thing is that AQM document includes requirements for AQM, so 
when I request support for "best practice AQM", I get ECN support as well. 
I am looking for RFC6204 (Basic Requirements) style document.

Then we need to advertise ECN benefit to end users, for instance by 
advocating its use through tools like 
<http://www.speedguide.net/tcpoptimizer.php>. The change log says "Changed 
ECN Capability optimal recommendation in General tab based on user 
feedback and issues with some US ISPs" and I fear that the recommendation 
there is to turn ECN off :P. I don't want to install the utility to test.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Jim Gettys <[email-masked]>
Date: Tue, 19 Mar 2013 13:26:23 -0400

You need to distinguish 1) "Will talk ECN when talked to", from 2) "Will
initiate an ECN conversation".

Linux, for example, will do 1) by default (and has for some time now), but
requires configuration to turn on ECN when initiating a connection.
                                  - Jim

On Tue, Mar 19, 2013 at 10:45 AM, Rick Jones <[email-masked]> wrote:

> On 03/19/2013 02:22 AM, Mikael Abrahamsson wrote:
>
>>  Do we need to start a campaign to further encourage greater ECN
>>> support (also of network providers)? Asking the content providers on
>>> the list(s): What are the reasons to not enable ECN support?
>>>
>>
>> Let me speculate:
>>
>> demand for AQM, and even if there was AQM, it would most likely not be
>> ECN enabled.
>>
>
> Out of curiosity, which stacks have ECN enabled by default?  To my
> recollection, on netperf.org I had to explicitly enable TCP's use of ECN
> in the kernel which ships with Ubuntu 12.04.
>
> rick jones
>
> ______________________________**_________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/tcpm<https://www.ietf.org/mailman/listinfo/tcpm>
>

---

From: Yuchung Cheng <[email-masked]>
Date: Tue, 19 Mar 2013 13:17:57 -0700

> http://www.ikr.uni-stuttgart.de/Content/Publications/Archive/Kue_PAM13_40160.pdf
Do people on the list know any (good) evaluation of performance impact
of ECN on real and/or emulated networks. E.g., how much faster will
the Web be if ECN is used (correctly).

>
> Mirja
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 19 Mar 2013 20:35:26 +0000

> the reasons to not enable ECN support?

probably.

---

From: Jim Gettys <[email-masked]>
Date: Tue, 19 Mar 2013 18:36:19 -0400

Clearly, having a working AQM is a necessary prerequisite for ECN to be
useful; one only overcome in the last year with CoDel/Pie.  Variable
bandwidth is still a challenge, but with CoDel at least, we think it can be
done.  And we've certainly implemented ECN support in the codel/fq_codel
qdisc's (though would be grateful if ECN experts make sure it's been done
correctly).

The incentive structure needs to work here. There may be things we can and
should do to provide incentive for ECN deployment.

For Bell Heads working on wireless cellular transport, the incentive is
really pretty clear: they ***hate*** dropping packets with a passion, not
understanding that either packet drop or ECN are necessary, and it will
probably be easier to convince them to adopt ECN than to drop packets.
 Given how hard they sweat to get packets over the air, I sort of
understand where they come from.

I believe some of the cellular carriers are requiring ECN support in
handsets going forward, and as they classify VOIP into a separate bearer
class anyway, I can see little incentive not to use ECN on their "best
effort" bearer class.

I believe all current operating systems react correctly to ECN marked
packets; the only question is whether they will talk ECN if talked to
(pretty common; Linux has done so now for quite a few years), *and* whether
they enable ECN when establishing new connections or not (no one does right
now by default).

At the moment, Windows is vanishingly small fraction of handsets, being
dominated by Android (Linux) and Apple as it is.

I worry about bufferbloat in the HARQ layer of cellular networks not
reflecting ECN marking into packets, but until that analysis has been done
in real systems, it's just one more thing to worry about. Our Linux
experience is that bufferbloat hides everywhere in current systems: the
analogy in WiFi is the error correction layer in 802.11n, which causes
large amounts of bloat, and fixing WiFi is very much a work in progress
(except that not enough resources are currently available to go do the
work, and it's more complicated that wired systems).  Dave Taht cheered the
first time he got the 802.11 layer to drop a packet, it was so much a
problem.

Right now, there are still some disincentives for ECN: e.g. some very small
fraction of sites that become "black holes", or crashing antique
middelboxes. We have no data on how much this is at this date, and the
database that used to exist documenting middlebox problems has bit-rotted.
 These  middleboxes are likely in the consumer edge, and unlikely to be in
the path of most mobile devices and web sites on 3g/LTE.  Mobile devices on
home WiFi networks are more likely to have problems.

We have ECN enabled in CeroWrt and have not noticed any problems; but 4-5
years ago OpenWrt (with a very much larger user base) still detected
problems to the extent they had to disable initiating ECN connections.

I know Bauer et. al. examined this a few years ago. But we have no data
over the last several years I've seen (though this new paper referenced
may: I've not had a chance to read it yet).

There is one other issue with ECN: when operating at low bandwidth at the
very edge of the net, it can still be advantageous to drop a packet rather
than ECN mark it, to get back the transmission time of the packet.  Dave
Taht's experiments (IIRC) were below 4Mbps for this advantage (when doing
VOIP over that bottleneck competing against other traffic in a best effort
class).

My intuition is to get VOIP reliable over WiFI on a busy network (or when
far away from the AP) we'll want to classify the VOIP packets anyway and
use the right hardware class in WiFi; this is primarily to get priority
access to a transmit opportunity on WiFi rather than the previous reasons
we've had.  Certainly on other media we've seen little reason to have to do
any explicit classification for VOIP anymore once running fq_codel.  Things
generally "just work" without all that hair for VOIP traffic.
                                                  - Jim

On Tue, Mar 19, 2013 at 5:49 PM, 天澜 <[email-masked]> wrote:

> To let ECN be popular used ，the most important is let the connection which
> used “ECN” is fairness to the other connection;
> So we should design new algorithm for ECN connection to "prize" those
> people who use ECN;
>
>
>                                          hritian
>
> ________________________________________
> 发件人: Jim Gettys [[email-masked]]
> 发送时间: 2013年3月20日 1:26
> 到: Rick Jones
> Cc: [email-masked]; [email-masked]; [email-masked]; Mikael Abrahamsson
> 主题: Re: [iccrg] [tcpm] ECN support and usage on the Internet
>
> On Tue, Mar 19, 2013 at 10:45 AM, Rick Jones <[email-masked]<mailto:
> [email-masked]>> wrote:
> recollection, on netperf.org<http://netperf.org> I had to explicitly
> enable TCP's use of ECN in the kernel which ships with Ubuntu 12.04.
>
> rick jones
>
> [email-masked]<mailto:[email-masked]>
> ________________________________
>
> This email (including any attachments) is confidential and may be legally
> privileged. If you received this email in error, please delete it
> immediately and do not copy it or use it for any purpose or disclose its
> contents to any other person. Thank you.
>
>
> 本电邮(包括任何附件)可能含有机密资料并受法律保护。如您不是正确的收件人，请您立即删除本邮件。请不要将本电邮进行复制并用作任何其他用途、或透露本邮件之内容。谢谢。
>

---

From: Simon Barber <[email-masked]>
Date: Tue, 19 Mar 2013 16:43:11 -0700

I'm not sure why people are so obsessed with ECN - the little data I've 
seen about it showed that it's effect on system throughput was in the 
noise. Sure, wireless guys don't like to waste precious wireless 
bandwidth, but they're not dropping packets that have used up the 
precious wireless bandwidth. They get dropped before the wireless link.

Simon

On 03/19/2013 03:36 PM, Jim Gettys wrote:
> bandwidth is still a challenge, but with CoDel at least, we think it can
> be done.  And we've certainly implemented ECN support in the
> codel/fq_codel qdisc's (though would be grateful if ECN experts make
> sure it's been done correctly).
>
> The incentive structure needs to work here. There may be things we can
> and should do to provide incentive for ECN deployment.
>
> really pretty clear: they ***hate*** dropping packets with a passion,
> not understanding that either packet drop or ECN are necessary, and it
> will probably be easier to convince them to adopt ECN than to drop
> packets.  Given how hard they sweat to get packets over the air, I sort
> of understand where they come from.
>
> (pretty common; Linux has done so now for quite a few years), *and*
> whether they enable ECN when establishing new connections or not (no one
> does right now by default).
>
> reflecting ECN marking into packets, but until that analysis has been
> done in real systems, it's just one more thing to worry about. Our Linux
> work, and it's more complicated that wired systems).  Dave Taht cheered
> the first time he got the 802.11 layer to drop a packet, it was so much
> a problem.
>
> Right now, there are still some disincentives for ECN: e.g. some very
> small fraction of sites that become "black holes", or crashing antique
> database that used to exist documenting middlebox problems has
> bit-rotted.  These  middleboxes are likely in the consumer edge, and
> unlikely to be in the path of most mobile devices and web sites on
> 3g/LTE.  Mobile devices on home WiFi networks are more likely to have
> problems.
>
> We have ECN enabled in CeroWrt and have not noticed any problems; but
> 4-5 years ago OpenWrt (with a very much larger user base) still detected
> There is one other issue with ECN: when operating at low bandwidth at
> the very edge of the net, it can still be advantageous to drop a packet
> rather than ECN mark it, to get back the transmission time of the
> packet.  Dave Taht's experiments (IIRC) were below 4Mbps for this
> advantage (when doing VOIP over that bottleneck competing against other
> traffic in a best effort class).
>
> My intuition is to get VOIP reliable over WiFI on a busy network (or
> when far away from the AP) we'll want to classify the VOIP packets
> anyway and use the right hardware class in WiFi; this is primarily to
> get priority access to a transmit opportunity on WiFi rather than the
> previous reasons we've had.  Certainly on other media we've seen little
> reason to have to do any explicit classification for VOIP anymore once
> running fq_codel.  Things generally "just work" without all that hair
> for VOIP traffic.
>                                                    - Jim
>
>
>
>
>
> On Tue, Mar 19, 2013 at 5:49 PM, 天澜 <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     To let ECN be popular used ，the most important is let the
>     connection which used “ECN” is fairness to the other connection;
>     So we should design new algorithm for ECN connection to "prize"
>     those people who use ECN;
>
>
>                                                     hritian
>
>     发件人: Jim Gettys [[email-masked] <mailto:[email-masked]>]
>     发送时间: 2013年3月20日 1:26
>     到: Rick Jones
>     Cc: [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>;
>     Mikael Abrahamsson
>     You need to distinguish 1) "Will talk ECN when talked to", from 2)
>     "Will initiate an ECN conversation".
>
>     Linux, for example, will do 1) by default (and has for some time
>     now), but requires configuration to turn on ECN when initiating a
>     connection.
>                                        - Jim
>
>
>
>     On Tue, Mar 19, 2013 at 10:45 AM, Rick Jones <[email-masked]
>     <mailto:[email-masked]><mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>     recollection, on netperf.org
>     <http://netperf.org><http://netperf.org> I had to explicitly enable
>     TCP's use of ECN in the kernel which ships with Ubuntu 12.04.
>
>     rick jones
>
>     [email-masked] <mailto:[email-masked]><mailto:[email-masked]
>     <mailto:[email-masked]>>
>     This email (including any attachments) is confidential and may be
>     legally privileged. If you received this email in error, please
>     delete it immediately and do not copy it or use it for any purpose
>     or disclose its contents to any other person. Thank you.
>
>     本电邮(包括任何附件)可能含有机密资料并受法律保护。如您不是正确的收件
>     人，请您立即删除本邮件。请不要将本电邮进行复制并用作任何其他用途、或
>     透露本邮件之内容。谢谢。
>
>
>
>
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm
>

---

From: Rick Jones <[email-masked]>
Date: Tue, 19 Mar 2013 07:45:59 -0700

rick jones

---

From: Glen Turner <[email-masked]>
Date: Wed, 20 Mar 2013 09:38:37 +1030

On 20/03/2013, at 9:06 AM, Jim Gettys wrote:
> 
> We have ECN enabled in CeroWrt and have not noticed any problems; but 4-5 years ago OpenWrt (with a very much larger user base) still detected problems to the extent they had to disable initiating ECN connections.  

The issues with accessing web sites from ECN-using hosts were primarily due to one software bug in one popular network vendor's popular firewall. The software versions with that bug have been end-of-lifed by the vendor. So you should have a much better experience with ECN reachability these days.

-glen

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 20 Mar 2013 05:01:22 +0100 (CET)

> I worry about bufferbloat in the HARQ layer of cellular networks not

This might be from just one vendor, but the Radio Link Control (RLC) layer 
on our equipment will buffer up to 400 packets before it does tail-drop. 
There might be additional buffering in GGSN/SGSN doing rate-shaping before 
it's even sent to the RNC (which terminates the RLC layer between the RNC 
and the end user terminal equipment). All this buffering is strict FIFO.

I personally belive that AQM at each of these buffering points would be 
beneficial to the end user equipment.

> running fq_codel.  Things generally "just work" without all that hair 

I agree, fq_codel probably needs some DSCP handling so that VOIP packets 
(EF marked) would end up in a different hardware queue. For mobile, the 
bearer model would mean there would be an L4 inspection engine putting the 
traffic into the correct bearer anyway (that's the 3GPP way), so here 
codel probably wouldn't need to do anything (because there would be 
several codel instances running, one per bearer).

---

From: Matthew Ford <[email-masked]>
Date: Wed, 20 Mar 2013 11:14:42 +0000

(trimmed the cc list)

On 19 Mar 2013, at 22:36, Jim Gettys <[email-masked]> wrote:

> There is one other issue with ECN: when operating at low bandwidth at the very edge of the net, it can still be advantageous to drop a packet rather than ECN mark it, to get back the transmission time of the packet.  Dave Taht's experiments (IIRC) were below 4Mbps for this advantage (when doing VOIP over that bottleneck competing against other traffic in a best effort class).

Hmmm. According to Akamai, global average connection speeds remain stubbornly below 4Mbps [1], so if Dave's analysis is correct, an unsophisticated ECN-deployment campaign may be counterproductive.

Mat

[1] http://www.internetsociety.org/blog/2013/02/internet-connection-speeds-and-right-some

---

From: Emmanuel Lochin <[email-masked]>
Date: Wed, 20 Mar 2013 12:22:35 +0100

> the Web be if ECN is used (correctly).

There is : http://dl.acm.org/citation.cfm?id=1080091.1080100

EL

-- 
Emmanuel Lochin
Professeur ISAE - OSSI
Institut Supérieur de l'Aéronautique et de l'Espace (ISAE)
Issu du rapprochement SUPAERO et ENSICA
10 avenue Edouard Belin - BP 54032 - 31055 Toulouse cedex 4
Tel : 05 61 33 91 85 - Fax : 05 61 33 91 88
Web : http://personnel.isae.fr/emmanuel-lochin/
---
"This email and any attachments are confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed"

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 20 Mar 2013 16:03:59 +0000

Thanks!

Which fortunately is already an experimental http://tools.ietf.org/html/rfc5562 

But too little experience to follow up on that just yet; Last time I looked, I believe it was the AIX 5.3 TCP stack would default to 5562, when ECN is enabled - but ECN is off by default in that OS...

But the findings in that paper don't compare Tail-Drop non-ECN with AQM/ECN*, which is probably what you are after Yuchung?

Put differently: With a large enough fraction of AQM deployment, a reasonable number of RTOs should be avoidable (less probability that the last segment in a session is dropped); with the addition of ECN, even that loss should go away...

Do you know what the CCDF for object load times would look like, if there were virtually no RTOs anymore?

Apparently, the incentive to avoid (costly) RTOs is too small to drive ECN deployment, even though that should be something easy to achieve with ECN on TCP.

Richard Scheffenegger

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Emmanuel Lochin
> Sent: Mittwoch, 20. März 2013 12:23
> To: Yuchung Cheng
> Cc: [email-masked] Extensions; [email-masked]; [email-masked]
> Subject: Re: [tcpm] ECN support and usage on the Internet
> 
> Institut Supérieur de l'Aéronautique et de l'Espace (ISAE) Issu du
> rapprochement SUPAERO et ENSICA
> 10 avenue Edouard Belin - BP 54032 - 31055 Toulouse cedex 4 Tel : 05 61 33
> 91 85 - Fax : 05 61 33 91 88 Web : http://personnel.isae.fr/emmanuel-
> lochin/
> ---
> "This email and any attachments are confidential. They may contain legally
> privileged information or copyright material. You should not read, copy,
> use or disclose them without authorisation. If you are not an intended
> recipient, please contact us at once by return email and then delete both
> messages. We do not accept liability in connection with computer virus,
> data corruption, delay, interruption, unauthorised access or unauthorised
> amendment. This notice should not be removed"
>

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Wed, 20 Mar 2013 16:14:03 +0000

Hi Simon,

For one, throughput is the one metric, that should NOT be influenced by ECN, actually. So if that is "in the noise", that is a very good sign; 

The more interesting metrics, that are addressed with ECN are latency ("page load times") and network efficiency (fewer packets are needlessly processed in initial hops, just to be dropped by the penultimate hop; that bandwidth can be allocated to other flows etc).

Other schemes that reduce latency usually do so by trading a good share of bandwidth... (credit allocation scheme used in FC, anyone?)

ECN hat a huge issue of deployability issues, that had nothing to do with the mechanism itself, but with misbehaving equipment on the signaling - and the institutional memory still remembers those albeit any new signaling scheme could run into similar issues (independent of the mechanisms).

Ie. some people still haven't got the Memo that IPv4 TOS was deprecated quite some time ago (now DiffServ/ECN),

Regards,

Richard Scheffenegger

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Simon Barber
> Sent: Mittwoch, 20. März 2013 00:43
> To: Jim Gettys
> Cc: Rick Jones; [email-masked]; [email-masked]; 天澜; [email-masked]; Mikael
> Abrahamsson
> Subject: Re: [aqm] 答复: [iccrg] [tcpm] ECN support and usage on the
> Internet
> 
> bandwidth, but they're not dropping packets that have used up the precious
> wireless bandwidth. They get dropped before the wireless link.
> 
> Simon
>

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 21 Mar 2013 15:29:16 +0000

Hi,

I'm afraid I was not able to parse your statement.

My comment was not about reducing the RTO time (!). On the contrary, I was pointing out, that with ECN (and without genuine loss due to corruption), RTOs - regardless of the actual timer value as long as that is reasonably larger than RTT - should become exceedingly rare, once ECN is fully deployed.

Once RTO is no longer necessary to recover ~70% of all lost TCP segments (google webserver data), you can actually *increase* the minimum RTO timeout value since it really is a last resort. (Using a "last resort" recovery mechanism for 70% of recoveries is really NOT "last resort").

Best regards,

Richard Scheffenegger

> From: 天澜 [mailto:[email-masked]]
> Sent: Donnerstag, 21. März 2013 07:47
> To: Scheffenegger, Richard; Emmanuel Lochin; Yuchung Cheng
> Subject: 答复: [iccrg] [tcpm] ECN support and usage on the Internet
> 
> about RTO ,accroding to out experience ,use small probe packet at least
> reduce 90% RTO time（Since 2010,now every day peek floe more than 1Tbps ）
> ; Consider the mobile network Excessive reduce RTO time is unreasonable;
> 
> 发件人: Scheffenegger, Richard [[email-masked]]
> 发送时间: 2013年3月21日 0:03
> 到: Emmanuel Lochin; Yuchung Cheng
> But too little experience to follow up on that just yet; Last time I
> looked, I believe it was the AIX 5.3 TCP stack would default to 5562, when
> ECN is enabled - but ECN is off by default in that OS...
> 
> 
> But the findings in that paper don't compare Tail-Drop non-ECN with
> AQM/ECN*, which is probably what you are after Yuchung?
> 
> 
> Put differently: With a large enough fraction of AQM deployment, a
> reasonable number of RTOs should be avoidable (less probability that the
> last segment in a session is dropped); with the addition of ECN, even that
> loss should go away...
> 
> 
> Apparently, the incentive to avoid (costly) RTOs is too small to drive ECN
> deployment, even though that should be something easy to achieve with ECN
> on TCP.
> 
> 
> Richard Scheffenegger
> 
> 
> 
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Emmanuel Lochin
> > > Do people on the list know any (good) evaluation of performance
> > > impact of ECN on real and/or emulated networks. E.g., how much
> > > faster will the Web be if ECN is used (correctly).
> >
> > "This email and any attachments are confidential. They may contain
> > legally privileged information or copyright material. You should not
> > read, copy, use or disclose them without authorisation. If you are not
> > an intended recipient, please contact us at once by return email and
> > then delete both messages. We do not accept liability in connection
> > with computer virus, data corruption, delay, interruption,
> > unauthorised access or unauthorised amendment. This notice should not be
> removed"
> >

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 22 Mar 2013 14:49:06 +0000

>> the reasons to not enable ECN support?
I think so too - for years this was just another "technology", it's 
rapidly becoming important to control internet queuing delay and we need 
to consider seriously whether we recommend this and what.

Gorry

---

From: Dave Taht <[email-masked]>
Date: Fri, 22 Mar 2013 08:04:54 -0700

This is just sort of a grab bag of reactions to this thread.

ECN on conventional voip is nuts. Another packet will be along soon enough.

It might make sense on videoconferencing and on adaptive voice/video codecs.

ECN on egress from a low bandwidth router is dumb. Dropping packets is
much more efficient.

ECN in ingress from a cmts/dslam to a couple short hops inside the home
gateway seems to work pretty well at 20+ mbit. The packet's traversed
the internet, might as well mark it rather than drop.

The Xfq_codel shapers that I've been using to get results like toke's
at iccrg and those on the
http://www.bufferbloat.net/projects/codel/wiki/RRUL_Rogues_Gallery
do ecn in ingress to the home and drop on egress.

ECN however can be seriously gamed and there needs to be an operating
point in an AQM where packets are dropped not marked. I never found
one that worked, but that was in early fq_codel days before
I had tests like RRUL that made sense. (see codel list thread on ECN:

https://lists.bufferbloat.net/pipermail/codel/2012-August/000412.html

I have also successfully been using ecn enablement on wifi routing
traffic, using the congestion indicator as a possible means to explore
new metrics.

That said, marking almost never happens at the stack layer fq_codel
is at now in Linux wifi, but I suspect, if we get separate queues for
wifi packets, notably multicast, it may become useful as an indicator
of (for
example) multicast overload on wifi.

That said, I'd really like there
to be a dropped packet and delay indications from codel information
(via netlink) that a userspace daemon could "see" so as to get more of
that indication, more rapidly, up there, where we could intelligently
(for example) re-route flows.

mosh ( http://mosh.mit.edu) traffic got ecn capability about 6? months
ago, and it was neat.

It worked. :)

What did happen instead, was the weird marking I'd asked the mosh folk
to use (AF42) caused problems on two networks, keith has more
details.

Lastly, as for the lemming problem on incast, I tend to agree with
fred that using TCP as written is not the right thing. :) I liked what
I little I understood of RFC6013 attempts on this front (and on things
like reducing amplification attacks on dns), it's too bad that work
seems to have stalled out, and that option space is so scarce.

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 26 Mar 2013 15:49:59 +0100

Hi,

I don't understand the obsession to not use ECN. The advantage is, you don't 
have to drop packets. Sure, (core) networks are optimized to have a very low 
drop rate anyway, but isn't it better not not drop any packets at all?

Mirja

On Wednesday 20 March 2013 00:43:11 Simon Barber wrote:
> >     It's not on by default in Windows. There is little reason to turn it
> > on, because "nobody" acts on ECN, and nobody acts on ECN because there is
> > no demand for AQM, and even if there was AQM, it would most likely not be
> > ECN enabled.
> >

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: [email-masked]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------

---

From: Simon Barber <[email-masked]>
Date: Tue, 26 Mar 2013 13:51:26 -0700

I can see advantages for time sensitive applications, like VoIP, or for 
protocols with longer, slow timeouts (TCP SYN, SYN-ACK). I don't see 
any real advantage for TCP data, the extra traffic caused by the losses 
is insignificant, compared to the complexity of getting ECN to work in 
today's networks.

Simon