Re: [aqm] ECN Manifesto iD - now uploaded

[John Leslie <[e-mail]>]

Gorry Fairhurst <[e-mail]> 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 <[e-mail]>