On Tue, 9 Jun 2015, Steven Blake wrote:
Except that tcp's drop their rates by (typically) half on a drop, and
a matter of debate as to when on CE.
Ex/ 10 GE link, ~10K flows (average). During a congestion epoch, CoDel
with interval = 100 msec starts dropping 257 packets/sec after 5 secs.
How many flows is that effectively managing?
how fast are the flows ramping back up to the prior speed?
if you have 10K flows and ~250 drops/sec, over 40 seconds each could end up with
one drop. If that keeps the link uncongested, it's doing it's job.
Unfortunantly, when there is a drop, the affected flow slows down a LOT, so if
you are near the edge of being uncongested, you may not need to slow that many
flows down to be uncongested. Then as the flows ramp back up, the link becomes
congested again and some flow needs to be slowed down. Hopefully CoDel is going
to slow down a different flow the next time.
With the extisting feedback that can be provided, it's not possible to slow all
flows down 5%, all you could do is to slow 10% of the flows by 50% to reduce
overall load by 5%
David Lang
Unless I am mistaken, it appears that the control law should be
normalized in some way to average packet rate. On a high-speed link, it
might be common to drop multiple packets per-msec, so it also isn't
clear to me whether the drop frequency needs to be recalculated on every
drop, or whether it could be recalculated over a shorter interval (e.g.,
5 msec).
Pie took the approach of sampling, setting a rate for shooting, over a
16ms interval. That's pretty huge, but also low cost in some hardware.
Codel's timestamp per-packet control law is continuous (but you do
need to have a cheap packet timestamping ability).
Certainly in all cases more work is needed to address the problems
100gps rates have in general, and it is not just all queue theory! A
small packet is .62 *ns* in that regime. A benefit of fq in this case
is that you can parallelize fib table lookups across multiple
processors/caches, and of fq_codel is that all codels operate
independently.
High-speed metro/core links need AQM, too. I believe that
draft-ietf-aqm-codel-01 doesn't work for these links in the general case
(e.g., large #flows, recommended value for interval, no FQ). IMHO the
draft should say something about this, or should adjust the algorithm
accordingly.
Regards,
// Steve
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
