Dave Taht <[email protected]> wrote: > > section 6 addition. (could use more verbiage) > > 6.3 "An AQM that is ECN aware MUST have overload protection.
I fear I cannot discern what you mean this to say. :^( > It is trivial for a malbehaved application/worm/bot to mark all > its packets with ECN and thus gain priority over other traffic > not ecn marked. This somewhat-paranoid claim rests on several assumptions that I hope we will recommend against. - the most obvious is an assumption that a tail-drop node will mark _instead_ of dropping ECN-capable packets. This is not actually possible, and I hope we will strongly deprecate it. Tail-drop should drop packets regardless of ECN bits. - there is also an assumption that an ECN-capable transport can mark its packets as ECN-capable and then never reduce its sending rate. I suppose it could; but not-ECN-capable transports can also never reduce the sending rate. :^( And the not-ECN-capable transports could accomplish the same reduction in "lost" packets by FEC. I believe we are going to "suggest" a lower marking threshhold for ECN-capable packets than the dropping threshhold for not-ECN-capable packets at AQM-capable nodes. This should reduce the paranoia level, I hope, since the ECN-capable flows will get congestion signals when not-ECN-capable packets are _not_ being dropped. We should concentrate our efforts on providing useful signals: that some transports might make poor use of these signals is beyond our scope. > 6.4 Enabling ECN at the application layer requires access to the IP > header fields, which are usually abstracted out completely at the > tcp layer, and hard to access from udp with multiple non-portable > methods to do so. Yes, there are TCP stacks which are ECN-unfriendly; but there are enough _today_ which are friendly to ECN. > ECN over UDP in new applications such as webrtc and Quic has > great potential for many other applications, however the same > care of design that went into ECN on TCP needs to go into > future UDP based protocols. I wouldn't disagree; but those issues are essentially-solved problems today. > Some other section that may end up here? > > ECN marking other sorts of flows (example routing packets) that have a > higher priority than other flows on link-local packets may be of benefit > with wider availability of aqm technologies that are ecn aware... I suppose there might be _some_ use for ECN on routing packets; but I doubt this is desirable today. ECN is not-at-all about getting a higher priority -- it's about getting congestion signals without packet loss. -- John Leslie <[email protected]> _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
