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

From: Wesley Eddy <[email-masked]>
Date: Wed, 9 Mar 2016 14:18:06 -0500

FYI -

-------- Forwarded Message --------
Subject: 	Re: [Gen-art] Gen-art LC review of draft-ietf-aqm-fq-codel-05
Date: 	Thu, 10 Mar 2016 08:07:06 +1300
From: 	Brian E Carpenter <[email-masked]>
Organization: 	University of Auckland
To: 	Elwyn Davies <[email-masked]>, 
[email-masked]
CC: 	General area reviewing team <[email-masked]>

On 10/03/2016 06:12, Elwyn Davies wrote:
> I am the assigned Gen-ART reviewer for this draft.

And I am another Gen-ART reviewer who saw this go by:

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

For IPv6 there is another issue here: the well-known difficulty in finding
the protocol and port numbers at line speed when extension headers are present.
Which is of course why IPv6 senders are supposed to set the flow label, which
should in turn provide a handy 3-tuple (addresses/flow label) that would be
ideal for CoDel. The operational facts today are that most hosts don't set
the flow label and many paths through the Internet drop packets with extension
headers, but the fact that the 5-tuple is problematic in this way might be
worth mentioning.

     Brian

---

From: Jonathan Morton <[email-masked]>
Date: Thu, 10 Mar 2016 01:06:06 +0200

> On 9 Mar, 2016, at 21:18, Wesley Eddy <[email-masked]> wrote:
> 

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