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

[Simon Barber <[e-mail]>]

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:
> 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]
> <mailto:[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] <mailto:[e-mail]>]
>     发送时间: 2013年3月20日 1:26
>     到: Rick Jones
>     Cc: [e-mail] <mailto:[e-mail]>; [e-mail]
>     <mailto:[e-mail]>; [e-mail] <mailto:[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]><mailto:[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><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]><mailto:[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.
>
>     本电邮(包括任何附件)可能含有机密资料并受法律保护。如您不是正确的收件
>     人，请您立即删除本邮件。请不要将本电邮进行复制并用作任何其他用途、或
>     透露本邮件之内容。谢谢。
>
>
>
>
> _______________________________________________
> aqm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/aqm
>