Hi Michael, Gorry, in section 3.2, you state that "it exposes the presence of congestion". But ECN (on the IP layer) goes beyond that, and can expose not only the presence, but also the extent of congestion.
(It's just that very few transports have ways to carry that extent back to the sender - speaking as co-author of draft-kuehlewind-tcpm-accecn-reqs and draft-kuehlewind-tcpm-accurate-ecn). > Do you know about any other disadvantages? I think the biggest issue is the interaction between ECN and non-ECN flows (and packets; for TCP, only data segments are specified to optionally be ECN-enabled, not pure ACKs, and other control segments (some are allowed as experimental, i.e. SYN/ACK). If ECN would have been seen as universally good (back in the day), it is odd that one L4 flow (TCP session) is constituted from both ECN- and non-ECN segments during it's lifetime. The natural conclusion would be to assume that ECN on pure ACK, FIN, RST is detrimental in some way (personally I tend to disagree; there may not be any significant benefit, but it wouldn't break anything either - just the opposite, pure ACKs would serve as probes into the congestion state of the return path, once the data direction within the TCP flow reverses). But these points are transport specific; However, guidance to transport protocol designers on the use of ECN with control segments etc seems like it could be in scope for this document? In any case, to hash out the obvious, the interaction between ECN and non-ECN is complex and seen as potentially problematic. That may account for a real or perceived (depending on the AQM's use of ECN) problem with ECN... Richard Scheffenegger (individual contributor) > -----Original Message----- > From: Michael Welzl [mailto:[email protected]] > Sent: Montag, 17. Februar 2014 10:21 > To: Dave Taht > Cc: Scheffenegger, Richard; [email protected] > Subject: Re: [aqm] Draft Agenda for IETF89 > > > On 16. feb. 2014, at 20:35, Dave Taht wrote: > > > On Sat, Feb 15, 2014 at 7:10 AM, Michael Welzl <[email protected]> > 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 [email protected] https://www.ietf.org/mailman/listinfo/aqm
