Re: [aqm] ECN Manifesto iD - now uploaded

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Wed, 25 March 2015 18:29 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92C61B29E0 for <aqm@ietfa.amsl.com>; Wed, 25 Mar 2015 11:29:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VMZUKrwWMYU for <aqm@ietfa.amsl.com>; Wed, 25 Mar 2015 11:29:16 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 766E11B29DC for <aqm@ietf.org>; Wed, 25 Mar 2015 11:29:16 -0700 (PDT)
Received: from [IPv6:2001:67c:370:152:cd5:680a:2f34:4af] (unknown [IPv6:2001:67c:370:152:cd5:680a:2f34:4af]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 25CDE1B0050F; Wed, 25 Mar 2015 18:29:35 +0000 (GMT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
In-Reply-To: <20150324132648.GZ39886@verdi>
Date: Wed, 25 Mar 2015 13:29:13 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <F0D053B8-FBEB-4261-9CA7-7E3D1F985653@erg.abdn.ac.uk>
References: <8721294B-7FD3-4A8F-BF66-3C4D86DBCFE4@erg.abdn.ac.uk> <20150324132648.GZ39886@verdi>
To: John Leslie <john@jlc.net>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/qo1YAaPPmUKk7pAFvSQIeFOoaRE>
Cc: aqm@ietf.org
Subject: Re: [aqm] ECN Manifesto iD - now uploaded
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Mar 2015 18:29:19 -0000

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 <john@jlc.net> wrote:
> 
> Gorry Fairhurst <gorry@erg.abdn.ac.uk> 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 <john@jlc.net>