Gen-art LC follow-up review of draft-ietf-aqm-recommendation-09

Elwyn Davies <> Mon, 09 February 2015 18:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0E4A81A6F02; Mon, 9 Feb 2015 10:13:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -99.2
X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FYIY2HVEMEgd; Mon, 9 Feb 2015 10:13:26 -0800 (PST)
Received: from ( [IPv6:2001:8b0:0:30::51bb:1e33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 273F91A6F10; Mon, 9 Feb 2015 10:13:18 -0800 (PST)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from <>) id 1YKspa-0005Dt-QI; Mon, 09 Feb 2015 18:13:14 +0000
Message-ID: <>
Date: Mon, 09 Feb 2015 18:13:15 +0000
From: Elwyn Davies <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: General Area Review Team <>
Subject: Gen-art LC follow-up review of draft-ietf-aqm-recommendation-09
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
Cc:, IETF Discussion <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Feb 2015 18:13:29 -0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-aqm-recommendation-09.txt
Reviewer: Elwyn Davies
Review Date: 2015/02/09
IETF LC End Date: 2014/12/24
IESG Telechat date: (if known) -

Summary:  Almost ready for BCP.  I have done some homework on the 
subject of AQM since my previous review and reread the latest version 
(-09).  I think a couple of my comments in the previous review were 
inappropriate - apologies to the authors - and we did not come to a 
meeting of minds at that point.  On rereading, I think it is generally 
an excellent and readable document.  However there are a couple of 
points, including one left over from the previous review, that could be 
usefully and (IMO) importantly taken into account.

Minor Issues:

Ensuring that mechanisms do not interact badly:
Given that a number of different mechanisms are being developed and 
potentially may all be deployed in various quantities in routers, etc., 
along the path that a packet takes, ensuring that this does not lead to 
instability or other interactions should also be a target of research. 
A number of applications now have flow control mechanisms that may be 
deployed as an adjunct to TCP so that a single path may have multiple 
nested end-to-end feedback loops (notably, just about to be 
standardized, HHTP2!) and it would be very wise to ensure that adding 
AQM into the loop does not lead to problems.
A short extra paragraph in s4.6 would cover the case I think.

Interactive applications such as gaming; and
The gaming aspect is mentioned very briefly (in s4.6).  Gaming is a 
major application and, for many consumers, ensuring that interaction 
with server-based games is low latency and pretty reliable is key to 
their enjoyment and the continuation of a large segment of the computer 
entertainment market.

Combinations of traffic:
A little more stress on the need to consider combinations of traffic in 
further research would be desirable.  I found CableLabs report of their 
simulation comparisons of the various AQM mechanisms being developed to 
be instructive in various ways: general AQM background, requirements of 
gaming and similar applications and thinking about combinations of traffic.

Nits/editorial comments:
(not fixed from -08)
General: s/e.g./e.g.,/, s/i.e./i.e.,/

s1.2, para 2(?) - top of p4: s/and often necessary/and is often necessary/
s1.2, para 3: s/a > class of technologies that/a class of technologies that/

s2, first bullet 3: s/Large burst of packets/Large bursts of packets/

s2, second set of bullets, #2: Probably need to expand POP and RDP (DNS 
and IMAP are in the RFC editor's "well known" class).  Alternatively 
could change POP/IMAP to "email access protocols".

s3, bullet #2, last para: s/open a large numbers of short TCP flows/may 
open a large number of short duration TCP flows/

s4, last para: s/experience occasional issues that need moderation./can 
experience occasional issues that warrant mitigation./

s4.2, para 6, last sentence: s/similarly react/react similarly/

s4.2.1, para 1: s/using AQM to decider when/using AQM to decide when/

s4.7, para 3:
> the use of Map/Reduce applications in data centers
I think this needs a reference or a brief explanation.  Maybe:
Jeffrey Dean and Sanjay Ghemawat. 2008. MapReduce. Commun. ACM 51, 1 
(January 2008), 107–113. DOI: