Telechat Review of draft-ietf-aqm-recommendation-09

Request Review of draft-ietf-aqm-recommendation
Requested rev. no specific revision (document currently at 11)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2015-02-17
Requested 2015-02-12
Authors Fred Baker, Gorry Fairhurst
Draft last updated 2015-03-16
Completed reviews Genart Last Call review of -08 by Elwyn Davies (diff)
Genart Telechat review of -09 by Elwyn Davies (diff)
Secdir Last Call review of -08 by Shawn Emery (diff)
Opsdir Last Call review of -08 by Mehmet Ersue (diff)
Assignment Reviewer Elwyn Davies
State Completed
Review review-ietf-aqm-recommendation-09-genart-telechat-davies-2015-03-16
Reviewed rev. 09 (document currently at 11)
Review result Almost Ready
Review completed: 2015-03-16


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: