Re: AQM work in the IETF

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Wed, 05 December 2012 14:25 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
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 1B79121F8C0D for <tsv-area@ietfa.amsl.com>; Wed, 5 Dec 2012 06:25:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.486
X-Spam-Level:
X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100]
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 oH0J4P-nxTGz for <tsv-area@ietfa.amsl.com>; Wed, 5 Dec 2012 06:25:31 -0800 (PST)
Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE4121F8BF7 for <tsv-area@ietf.org>; Wed, 5 Dec 2012 06:25:31 -0800 (PST)
Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 4DE2C2B4515; Wed, 5 Dec 2012 14:25:30 +0000 (GMT)
Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 117212B4096; Wed, 5 Dec 2012 14:25:29 +0000 (GMT)
Message-ID: <50BF5958.8000005@erg.abdn.ac.uk>
Date: Wed, 05 Dec 2012 14:25:28 +0000
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683.
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Wesley Eddy <wes@mti-systems.com>
Subject: Re: AQM work in the IETF
References: <50B2DA5E.1040005@mti-systems.com>
In-Reply-To: <50B2DA5E.1040005@mti-systems.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: tsv-area@ietf.org
X-BeenThere: tsv-area@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
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: Wed, 05 Dec 2012 14:25:32 -0000

My thoughts....

(1) TSVWG is about to submit a draft on Byte and Packet Congestion 
Notification - My understanding was that this was already about AQM, so 
yes this does fall within the IETF's area of interest. TSV may not be a 
bad area to do this (although it seems unusual), because the 
implications of AQM are directly linked to transport behaviours (AQM is 
not really to protect the forwarding or control plane or linked to 
routing, more to throttle resources for a flow).

(2) It may be hard to set a charter. There are certainly problems here:
- are there tools to easily see what is happening in deployed networks? 
this could perhaps be suited to ICCRG?
- is there a common reference model we could use to compare? Is there 
wisdom on what may be bad, good, etc...  It would be nice to have 
standard terminology, and guidelines...
- are there specific algorithms, or combinations of techniques (like 
CoDel) that should be described ... could be tricky without a common 
framework?

In sumamry, I think if we ignore this, then we are in danger of ignoring 
the existence of growing use of AQM, we've ignored other technologies in 
the past, and that can be bad when they become popular or turn in 
strange ways. To me it seems like transport - but if it is, then people 
from other areas MUST be engaged.

Gorry


On 26/11/2012 02: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.
>
> 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?
> - 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?
>
> Thanks for your thoughts :).
>