Gorry Fairhurst <[email protected]> wrote: > To: Mikael Abrahamsson <[email protected]>, "[email protected]" <[email protected]> > >> My summary: I would like to see some text on the downsides of having >> ECN transport, ECN enabled routers and having middle box bleaching >> ECN bits, thus removing the congestion signal. This downside, and the >> operational problem that some old equipment just simply drop packets >> with ECN bits set should be summarized the same way as the benfits. >> These are the only drawbacks of enabling ECN that I can see, and >> potentially text describing how to detect these problems could be >> added/extended (it's somewhat hinted at currently). > > GF/MW: We could certainly add text, how about adding something like: > > After: > A network device should therefore not remark an ECT(0) or ECT(1) mark to > zero > Add: > This can result in packets that were originally marked as > ECN-capable being dropped by ECN-capable network devices further > along the path. This eliminates the advantage of enabling ECN.
This text is a bit confusing -- I had to read it three times to get (I think) your point. Perhaps: " " This would negate the advantages of ECN for congestion which may " occur later in the path, in that an ECN-capable network device would " not be able to forward the packet with congestion signaled by "CE". Putting the effect first seems easier to read... Also, the forwarding node later in the path might have signaled congestion via "CE" at an earlier threshhold than it would drop packets. > And after: > Such a packet has already received ECN > treatment in the network, and remarking it would then hide the > congestion signal from the endpoints. > Add: > The endpoint will then be unaware of the signalled congestion, and > will only trigger a congestion response later if the congested > queue drops a packet. Note that ECN-enabled > networks devices need to drop excessive traffic [Section > 4.2.1 of RFC2309.bis] even when this is marked as ECN-capable. > This eliminates the advantage of enabling ECN, and could slow > down the response to congestion compared to using AQM, but is not > expected to be worse than drop-tail performance. I'm still failing (after five readings) to extract a clear meaning. :^( There are several points: - clearing a "CE" marking destroys the congestion signal. Barring some extraordinary programming, this would make an ECN-enabled flow unresponsive. - with an unresponsive flow, the congested node _might_ reach a level of congestion requiring tail-drop. But it also might not. :^( - _if_ a receiver added a way to observe this abuse (possibly by having the sender set an occasional "CE" mark before sending the packet), the responsiveness would still be degraded. Besides, there's really no chance that _all_ flows would ever be programmed to do this. Myself, I see no reason to add text to cover all of these: I think text covering the first point is sufficient. -- John Leslie <[email protected]> _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
