Subject: [aqm] ECN Manifesto iD - now uploaded

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 23 Mar 2015 17:41:57 -0500

People may have noticed (?) that we have now pushed the updates to the ECN Benefits draft to the ID archives. I published -01 with corrections for the initial NiTs reported.  I also published -02, which is a reorganisation based that updates the title. This reorganisation also resulted in moving " Bleaching and middlebox requirements to deploy ECN” to section 2.2.

https://datatracker.ietf.org/doc/draft-ietf-aqm-ecn-benefits/ <https://datatracker.ietf.org/doc/draft-ietf-aqm-ecn-benefits/>

Michael and I think this is now in good shape, and we plan to ask for a WGLC in the AQM meeting this week, Comments are welcome.

Gorry & Michael

---

From: John Leslie <[email-masked]>
Date: Tue, 24 Mar 2015 09:26:48 -0400

Gorry Fairhurst <[email-masked]> 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-masked]>

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 25 Mar 2015 13:29:13 -0500

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-masked]> wrote:
>