"Fred Baker (fred)" <[email protected]> writes:
> I'm not sure it makes sense to discuss fq_codel having a separate
> instance for each queue.
Why not? It does. Completely separate state variables and everything...
> It could, I suppose (by having a separate target delay value for each
> queue), but... the codel algorithm timestamps packets on enqueue and
> compares the difference between that timestamp and the current time
> against a common target delay value on dequeue.
That much is true: all the queues *start out* the same. Doesn't mean
they're not separate...
> If that comparison shows that the induced latency is greater than some
> value, the packet is discarded with some probability.
The state variables (drop count) governing when packets are dropped *are*
separate for each queue, so you can have completely different drop rates
for different queues if they build queues at different rates.
> In the linux fq algorithm, or its counterpart in fq_codel, there is
> one queue for mice and zero or more separate queues for elephant
> flows.
Not so. There can be several 'mice' queues. In fact, each and every
queue starts out its life as a 'mice' queue (getting prioritised) before
being demoted to the second tier ('elephant' queues) after having
dequeued its first quantum (by default an MTU's worth of bytes).
> It is technically possible for a packet to be delayed inordinately
> long in the "mice" queue, if the interface is undergoing a long term
> overload, but that would be pretty unusual (can you say "DDOS"?). More
> probably, discards happen to the "elephant" data flows and their
> corresponding queues, as they are more likely to build a backlog.
The way fq_codel is implemented pretty much guarantees that packets are
not dropped from the mice flows: By definition, they are only mice flows
when dequeueing their first quantum of bytes, at which point the CoDel
state vars are zeroed. Which means that even if the first packet is
queued for longer than the target (which can easily happen at low
bandwidths), this will trigger the wait time for an interval before an
actual drop happens. So unless the mice flow has two consecutive
packets, totalling less than a quantum (MTU) bytes, of which the first
takes more than an interval to put on the wire, the mice flow is not
going to see a drop.
This is, as far as I can tell from your explanation, different than what
fq_pie does.
-Toke
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
