Re: [aqm] ECN Manifesto iD - now uploaded

John Leslie <john@jlc.net> Tue, 24 March 2015 13:27 UTC

Return-Path: <john@jlc.net>
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 896341A1B1C for <aqm@ietfa.amsl.com>; Tue, 24 Mar 2015 06:27:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 YmSl_WxWZMHF for <aqm@ietfa.amsl.com>; Tue, 24 Mar 2015 06:27:01 -0700 (PDT)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB961A1AF0 for <aqm@ietf.org>; Tue, 24 Mar 2015 06:27:01 -0700 (PDT)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 45C6BC94C4; Tue, 24 Mar 2015 09:26:48 -0400 (EDT)
Date: Tue, 24 Mar 2015 09:26:48 -0400
From: John Leslie <john@jlc.net>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <20150324132648.GZ39886@verdi>
References: <8721294B-7FD3-4A8F-BF66-3C4D86DBCFE4@erg.abdn.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8721294B-7FD3-4A8F-BF66-3C4D86DBCFE4@erg.abdn.ac.uk>
User-Agent: Mutt/1.4.1i
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/EAX9AOMKrR4bJhVyG2CGG87SYvk>
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: Tue, 24 Mar 2015 13:27:03 -0000

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>