Re: [aqm] Fwd: Re: [Gen-art] Gen-art LC review of draft-ietf-aqm-fq-codel-05

[Jonathan Morton]

> On 9 Mar, 2016, at 21:18, Wesley Eddy  wrote:
> 
> > Minor issues: Treatment of packets that don't fit into the hashing 
> > classification scheme:  The default FQ-CoDel hashing
> > mechanism uses the protocol/addresses/ports 5-tuple, but there will be 
> > packets that don't fit this scheme (especially ICMP).

I believe the current implementations treat “ICMP” as part of the protocol 
(viz. TCP/UDP), and set the port numbers to zero, then hash as normal.  This 
stochastically provides a separate queue without explicit special handling.  I 
agree that this is worth mentioning in the spec.

ARP is another protocol worth noting here.  The only addresses reliably 
available are at the MAC level.

In fact, these are general problems for any flow-isolating qdisc, which is why 
Linux now provides a sophisticated (if slightly obtuse) flow-dissection 
mechanism which accounts for these factors and yields a straightforward hash 
value.  Perhaps a document dedicated to discussing this problem would be 
valuable, if it doesn’t already exist (and if it does, it should be referenced).

 - Jonathan Morton

___
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

[aqm] Fwd: Gen-art LC review of draft-ietf-aqm-fq-codel-05

[Wesley Eddy]

FYI - some of Elwyn's comments may be of interest to the working group:


 Forwarded Message 
Subject:Gen-art LC review of draft-ietf-aqm-fq-codel-05
Date:   Wed, 9 Mar 2016 17:12:41 +
From:   Elwyn Davies 
To: General area reviewing team 
CC: draft-ietf-aqm-fq-codel@ietf.org



I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-aqm-fq-codel-05.txt
Reviewer: Elwyn Davies
Review Date: 2016/03/06
IETF LC End Date: 2016/03/17
IESG Telechat date: (if known)  2016/03/17

Summary:
Almost ready.  There are a couple of minor issues that are barely above 
the level of nits plus a fair bit of editorial work.


I notice that the draft is on the IESG agenda on the day that last call 
ends.  If the authors wish to sort out the nits before the end of last 
call, I will be happy to work with them on this.


Major issues:
None.

Minor issues:
Treatment of packets that don't fit into the hashing classification 
scheme:  The default FQ-CoDel hashing mechanism uses the 
protocol/addresses/ports 5-tuple, but there will be packets that don't 
fit this scheme (especially ICMP).  There is no mention of what the 
classification would do with these packets.  I guess that one extra 
queue would probably suffice to hold any such outliers, but it would be 
wise to say something about how the packets from this/these queue(s) 
would be treated by the scheduler.  It might also be useful to say 
something about treatment of outliers in other classification schemes, 
if only to say that the scheme used needs to think about any such outliers.


s6.2, last para:  The proposal to add flow related marking to 
encapsulated packets needs to come with a very well exposed security and 
privacy health warning.. [It occurs to me that it might be possible to 
confine these markings to out of band notifications within the 
originating host which would allow fq_codel or similar to Flow Queue the 
packets getting them into a sensible order on the outgoing link.  Once 
the packets had been ordered in this way, a subsequent box (maybe an 
ADSL modem or suchlike) linking a home environment to the outside world 
could work purely on source address, thereby interspersing the packets 
from different hosts onto the external link but not needing to reorder 
the packets from each individual host.  Not sure if this is a sensible 
idea but it looks like a way to avoid the privacy issues.]


s11:  Internet Drafts are not scientific papers as such and do not 
usually have a Conclusions section.  I think it would be useful to move 
the paragraph in s11 as is to s1.  Since this draft is targeted for 
Experimental RFC status, it would be useful to suggest (maybe in s7) 
that experiments along the lines noted in s7 might be carried out and 
there results reported (where?  AQM WG?).  Given the developments with 
Cake, I am not sure whether the authors expect this version of FQ-CoDel 
to make it onto standards track or BCP, but to set out some sort of 
expected trajectory is desirable.


Nits/editorial comments:
General: s/i.e./i.e.,/, s/e.g./e.g.,/

Draft Title: The acronym CoDel with an uppercase D is used everywhere 
else in the document - Suggest the title should be FlowQueue-CoDel


Abstract:   Need to expand AQM. [DNS and and CPU are 'well-known' - 
http://www.rfc-editor.org/materials/abbrev.expansion.txt]


General: It would be helpful to capitalize Quantum throughout (or at 
least from s3 onwards)  to emphasise that it is a configured value.  
Likewise Interval and Target parameters.  Maybe also Flow and Queue as 
they a defined terms.


s1, para 1: It would be helpful to give the full title 
(FlowQueue-CoDel), expand AQM (again), provide a refernece explaining 
the term bufferbloat and give references for AQM, basic CoDel, DRR and 
the ns2/ns3 network simulators.


I would think one or both of the following would be useful (long term 
stable) refs for bufferbloat (the first is useful because the article is 
publically available rather than needing a sub to IEEE or ACM):


Jim Gettys. 2011. Bufferbloat: Dark buffers in the Internet. IEEE 
Internet Comput. 15, 3 (2011), 95–96. 
DOI:http://dx.doi.org/10.1109/MIC.2011.56 (freely available at 
http://www.bufferbloat.net/attachments/27/IC-15-03-Backspace.pdf)


and/or
Jim Gettys and Kathleen Nichols. 2012. Bufferbloat:Dark buffers in the 
Internet. Commun. ACM 55, 1 (2012), 1–15. 
DOI:http://dx.doi.org/10.1145/2063176.2063196


Suggest:
OLD:
   The FQ-CoDel algorithm is a combined packet scheduler and AQM
   developed as part of the bufferbloat-fighting community effort.  It
   is based on a modified Deficit Round Robin (DRR) queue