Re: AQM work in the IETF

David Ros <David.Ros@telecom-bretagne.eu> Tue, 27 November 2012 15:20 UTC

Return-Path: <David.Ros@telecom-bretagne.eu>
X-Original-To: tsv-area@ietfa.amsl.com
Delivered-To: tsv-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7562921F8419 for <tsv-area@ietfa.amsl.com>; Tue, 27 Nov 2012 07:20:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.422
X-Spam-Level:
X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_23=0.6, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tem5GO4aiPhZ for <tsv-area@ietfa.amsl.com>; Tue, 27 Nov 2012 07:20:46 -0800 (PST)
Received: from zproxy220.enst-bretagne.fr (zproxy220.enst-bretagne.fr [192.108.117.9]) by ietfa.amsl.com (Postfix) with ESMTP id B1B9D21F8235 for <tsv-area@ietf.org>; Tue, 27 Nov 2012 07:20:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by zproxy220.enst-bretagne.fr (Postfix) with ESMTP id 1B598301A5; Tue, 27 Nov 2012 16:20:42 +0100 (CET)
X-Virus-Scanned: amavisd-new at zproxy220.enst-bretagne.fr
Received: from zproxy220.enst-bretagne.fr ([127.0.0.1]) by localhost (zproxy220.enst-bretagne.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRMsT9pYo5yB; Tue, 27 Nov 2012 16:20:41 +0100 (CET)
Received: from arabica.home (ARennes-653-1-12-57.w92-139.abo.wanadoo.fr [92.139.171.57]) by zproxy220.enst-bretagne.fr (Postfix) with ESMTPSA id 5914A301A4; Tue, 27 Nov 2012 16:20:41 +0100 (CET)
Subject: Re: AQM work in the IETF
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="iso-8859-1"
From: David Ros <David.Ros@telecom-bretagne.eu>
In-Reply-To: <50B2DA5E.1040005@mti-systems.com>
Date: Tue, 27 Nov 2012 16:20:40 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <84F1B97D-E073-4B44-B0C1-0ED0F2ADCDB8@telecom-bretagne.eu>
References: <50B2DA5E.1040005@mti-systems.com>
To: Wesley Eddy <wes@mti-systems.com>
X-Mailer: Apple Mail (2.1283)
Cc: iccrg list <iccrg@cs.ucl.ac.uk>, tsv-area@ietf.org
X-BeenThere: tsv-area@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Transport and Services Area Mailing List <tsv-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsv-area>
List-Post: <mailto:tsv-area@ietf.org>
List-Help: <mailto:tsv-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Nov 2012 15:20:47 -0000

On 26 nov. 2012, at 03:56, Wesley Eddy wrote:

> As TSV ADs, Martin and I have been wondering lately about
> AQM work.
> 
> At this point, thanks largely to Jim Gettys, we all know
> about large buffers, and we know what bulk-transfer with
> loss-based congestion control can do to interactive traffic
> when large queues exist.
> 
> We know one thing that can be done to help is the use of
> AQMs, but the IETF is currently not doing a whole lot to
> help in this regard.
> 
> There is the CoDel I-D that was discussed in the TSVAREA
> meeting in Vancouver:
> http://tools.ietf.org/html/draft-nichols-tsvwg-codel-00
> But this is an individual submission that Martin and I
> would be happy to sponsor, and not a working group
> activity.
> 
> At the last IETF meeting, we had a request to talk about
> PIE, which we didn't have time for in TSVAREA, but ICCRG
> did:
> http://www.ietf.org/proceedings/85/slides/slides-85-iccrg-2.ppt
> 
> This was really interesting, and we wonder if the
> community is interested in continuing to hear about
> AQMs in this space, and what the IETF should be doing.
> 
> If people have thoughts about this, we'd like to hear
> about them on this list, and/or during the TSVAREA
> meeting in Orlando at the next IETF meeting.  We want
> to know what the level of interest in AQMs is, and
> might make this a focus of the TSVAREA meeting, if a
> lot of people seem to think it's a good idea.

Hi,

Some thoughts from Michael & I, with ICCRG chair hats on. I'm cc'ing the ICCRG list, just in case.


> 
> Particularly, I have wondered:
> - Should we have a working group looking at AQMs?
> - If so, does it make sense to shoot for Standards Track
>  specifications?
> - Would we be able to come up with actual requirements
>  on an AQM so that it's implementable for cheap in
>  hardware and software, and behaves well under load?
> - Would it be valuable to have a test suite for AQMs
>  similar to what ICCRG was doing for high-rate TCP?

An AQM test suite is in the purview of ICCRG, IOHO. And it'd certainly be valuable to have such a test suite.


> - Would it be valuable to have a BCP (or multiple) on
>  configuring "legacy AQM" like RED, or the use of AQM
>  metrics like "sojourn time" rather than variations of
>  the queue length?
> - If any of this is of value, how much belongs in the
>  ICCRG versus TSV working groups?

Metrics-related stuff (as in, e.g., what metric should an arbitrary AQM algorithm base its decisions upon) looks to us as ICCRG material. Other stuff seems more fit to TSV. ICCRG has served as an "intermediate" forum for experimental things that are not ready for a WG yet, so we can take that role again w.r.t. AQMs and TSVWG, just like the RG did for high-speed-TCPs and TCPM -- and, as Michael said, things getting stuck in the ICCRG-to-TCPM path wasn't the fault of the RG, actually. Or, the RG can be the home of Experimental RFCs for AQMs, that would move later to TSVWG when (if) moving to Standards-track.

Our take is, AQMs in general fit in ICCRG, and for some AQM-related things Informational or Experimental RFCs are possible outputs from the RG; in particular, we would very much like to see the new PIE proposal published through ICCRG.

Thanks,

David.

> 
> Thanks for your thoughts :).
> 
> -- 
> Wes Eddy
> MTI Systems

=================================================================
David ROS
http://www.rennes.enst-bretagne.fr/~dros/

Deadlines really start to press a week or two after they pass. -- John Perry