I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
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:http://dx.doi.org/10.1145/1327452.1327492