Looks pretty good to me. I took a pretty good read on the airplane west
yesterday, and comments are below.
- Jim
1.
"The rest of this document" is immediately followed by "The rest of this
section". That repetition is unfortunate, and the second is capitalized.
1.2
You should note again that fq_codel is not limited to hashing on f-tuples;
just that the current implementation defaults to hashing those.
Noting that fq_codel gets really good performance is nice and usually better
than most deployed ad-hoc classification schemes, but you should
also note that if you want hard "guarantees" of performance, packet
classification still has a role to play. For example, multiplexing a
control plane for a network over that network would be something that
requires
explicit classification to provide such guarantees.
4.1.2 Target
Should the target be tuned to at least the transmission time of an aggregate
on aggregating media (e.g. Cable, 802.11n, etc)? I think so....
but we can/should check with Kathy and Van....
4.1.3
This default of 10240 packets bothers me. That's of order 15,306,000
bytes.
It should be computed on link speed, or maybe observed transmission rate.
And should it be in bytes?
How does one compute the "suitable size"? So it's wrong by at least an
order
of magnitude for *most* current devices.
We really don't want to discourage naive people on IoT devices to think
that it will eat them out of house and home and therefore not to use
fq_codel.
At a minimum, we should note that this is an artifact of the current
implementation, and note the shortcoming of the current implementation.
Sigh.
Where did our "no knobs" mantra get lost? I guess Eric is too used to
machines with 10G and faster ethernet interfaces.
5.3
The "Jenkins" hash should be referenced. Which one is used?
Possibly worth noting that some other hash could also be used (I presume
it can be?), and why was the Jenkins hash chosen?
5.2
"This is because otherwise the queue can" -> "Otherwise the queue could"
The last paragraph does probability computations; IIRC, this was work
done by Paul McKenney for SFQ. It should be referenced.
6.2
There are indenting problems in this section.
6.3
"it cannot be easily retrofitted to devices".
Cannot is a bit strong; some silicon may also have modifyable firmware.
I'd say instead:
"it may be impossible to retrofit devices that do most of their
processing in silicon and lack space for timestamping"
You say:
Also, timestamping functions in the core OS need to be very
efficient.
Somehow we should make clear that perfection is not required.
Timestamping to of order a millisecond is fine; certainly getting time
at that resolution is sufficient, so long as the overhead to get the time
at that resolution is very low.
6.5
You say:
Finally, FQ-CoDel drops packets from the largest flows sooner and
more accurately than CoDel alone, and it is more responsive to
changes in bandwidth, and in number of flows, than CoDel alone.
Why is this true? It's an assertion without explanation. I'd be happier
if there is a one/two sentence explanation.
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
