On 16. feb. 2014, at 20:35, Dave Taht wrote: > On Sat, Feb 15, 2014 at 7:10 AM, Michael Welzl <mich...@ifi.uio.no> wrote: > >> 14:40 >> draft-fairhurst-ecn-motivation >> Gorry Fairhurst >> 15 min >> >> >> This is apparently not a published draft yet. >> >> >> It's draft-welzl-ecn-benefits, >> http://tools.ietf.org/html/draft-welzl-ecn-benefits-00 > > It describes the benefits of ECN persuasively and well.
Thanks!! > I would rather like a section discussing the negatives. We point to one problem in the introduction: "Following a recommendation in [RFC3168], which says: "for a router, the CE codepoint of an ECN- Capable packet SHOULD only be set if the router would otherwise have dropped the packet as an indication of congestion to the end nodes", it has often been assumed that routers mark packets at the same level of congestion at which they would otherwise drop them (e.g. in [RFC2884]), but there are indications that this configuration is not ideal [KH13]." With this configuration, which is a common default, e.g. also in Linux AFAIK, one sometimes gets more queue growth than without ECN because the very packets that an AQM mechanism marks with ECN don't free queue space (which they would do if they were dropped instead). However, even this disadvantage has to be put against the advantages that we tried to list, some of which can't be measured by looking at the delay of packets on the wire (e.g., head-of-line blocking delay occurs in the receiver buffer). Do you know about any other disadvantages? Cheers, Michael _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
