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-08.txt
Reviewer: Elwyn Davies
Review Date: 2014/12/19
IETF LC End Date: 2014/12/24
IESG Telechat date: (if known) -

Summary:  Almost ready for BCP.

Possibly missing issues:

Buffer bloat:  The suggestions/discussions are pretty much all about keeping buffer size
sufficiently large to avoid burst dropping.  It seems to me that it might be good to
mention the possibility that one can over provision queues, and this needs to be avoided
as well as under provisioning.

Interaction between boxes using different or the same algorithms: Buffer bloat seems to
be generally about situations where chains of boxes all have too much buffer.  One thing
that is not currently mentioned is the possibility that if different AQM schemes are
implemented in various boxes through which a flow passes, then there could be inappropriate
interaction between the different algorithms.  The old RFC suggested RED and nothing else so
that one just had one to make sure multiple RED boxes in series didn't do anything bad.  With
potentially different algorithms in series, one had better be sure that the mechanisms don't
interact in a bad way when chained together - another research topic, I think.

Minor issues:
s3, para after end of bullet 3:



    The projected increase in the fraction of total Internet traffic for
    more aggressive flows in classes 2 and 3 could pose a threat to the
    performance of the future Internet.  There is therefore an urgent
    need for measurements of current conditions and for further research
    into the ways of managing such flows.  This raises many difficult
    issues in finding methods with an acceptable overhead cost that can
    identify and isolate unresponsive flows or flows that are less
    responsive than TCP.






Question: Is there actually any published research into how one would 


identify


class 2 or class 3 traffic in a router/middle box? If so it would be 


worth noting -


the text call for "further research" seems to indicate there is 


something out there.






s4.2, next to last para: Is it worth saying also that the randomness 


should avoid targeting a single flow within a reasonable period to give 


a degree of fairness.




s4.2.1, next to last para:



    An AQM algorithm that supports ECN needs to define the threshold and
    algorithm for ECN-marking.  This threshold MAY differ from that used
    for dropping packets that are not marked as ECN-capable, and SHOULD
    be configurable.



Is this suggestion really compatible with recommendation 3 and s4.3 (no 


tuning)?






s7:  There is an arguable privacy concern that if schemes are able to 


identify class 2 or class 3 flows, then a core device can extract 


privacy related info from the identified flows.




Nits/editorial comments:
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, last para: Probably need to expand POP, IMAP and RDP; maybe provide 


refs??






s2.1, 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:



In 2013,



"At the time of writing" ?

s4.7, para 3:



the use of Map/Reduce applications in data centers



I think this needs a reference or a brief explanation.