John, I agree that we can improve the language we use to describe ECN. In particular saying what we mean by congestion, as you note below.
What I spoke about in the AQM meeting at the IETF in Dallas was the idea of trying to harmonise language - where possible - between the various AQM drafts, using the language we agreed in RFC 2309.bis as the starting point. Some people thought this was a good idea, and I was encouraged to try to align this in the draft you commented upon. I also promised to look at the recommendations in the evaluation guidelines from this perspective, Expect a new rev soon! Gorry > On 24 Mar 2015, at 08:26, John Leslie <[email protected]> wrote: > > 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
