Re: [aqm] 答复: [iccrg] [tcpm] ECN support and usage on the Internet

[Jim Gettys <[e-mail]>]

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, 天澜 <[e-mail]> 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 [[e-mail]]
> 发送时间: 2013年3月20日 1:26
> 到: Rick Jones
> Cc: [e-mail]; [e-mail]; [e-mail]; Mikael Abrahamsson
> 主题: Re: [iccrg] [tcpm] ECN support and usage on the Internet
>
> 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 <[e-mail]<mailto:
> [e-mail]>> wrote:
> On 03/19/2013 02:22 AM, Mikael Abrahamsson wrote:
> 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.
>
> Out of curiosity, which stacks have ECN enabled by default?  To my
> 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
>
> _______________________________________________
> tcpm mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/tcpm
>
>
> ________________________________
>
> 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.
>
>
> 本电邮(包括任何附件)可能含有机密资料并受法律保护。如您不是正确的收件人，请您立即删除本邮件。请不要将本电邮进行复制并用作任何其他用途、或透露本邮件之内容。谢谢。
>