-------- Original Message
--------
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.