Gorry Fairhurst <[email protected]> wrote: > > https://datatracker.ietf.org/doc/draft-ietf-aqm-ecn-benefits/
I have been reviewing an intermediate version. I doubt I'll find time this week for a review of the latest. Sorry about that... Generally, I think the document could be very significantly improved by being more careful about the word "congestion". In the IETF, we (long ago) observed buffer-overflow and started calling it "congestion". There are, of course, other meanings that "congestion" has historically indicated. As we have introduced Active Queue Management, we have started to introduce "congestion" signals other than buffer overflow: thus we now have at least two meanings attached to the word "congestion". This document, as of 18 March, continues to spread the confusion between the two (and perhaps other meanings as well). In particular, I stumbled badly over the phrase "before there is significant congestion". What do we actually mean to say here? What I think we mean to say is that an AQM "congestion" signal can be received and acted upon before the buffer at that node actually overflows. (Of course, this may or may not be true. Sometimes a node's buffer will go from empty to full in less than one RTT.) Myself, I find it helpful to think in terms of "congestion" meaning that packets are arriving faster than they can be forwarded -- but I don't ask anyone else to agree with me. I could suggest terms for the different meanings we want to talk about; but that doesn't seem helpful right now. But I do think we should separate the "buffer overflow" idea from the "latency is rising" idea; and I think the document should actually mention the problem of feedback-that-can-be-acted-upon lagging the actual status of the forwarding node in question. I could supply some text about that... The overall point I think we want to make is that ECN gives an unambiguous signal of whatever-it-signals that can be acted upon in one RTT -- which is in many cases before there is danger of buffer overflow; and that acting faster upon this signal can significantly reduce the latency while packets sit in the buffer at that node. -- John Leslie <[email protected]> _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
