ietf
[Top] [All Lists]

Gen-art LC review of draft-ietf-aqm-recommendation-08

2014-12-22 10:00:04
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.


<Prev in Thread] Current Thread [Next in Thread>