On Tue, 2015-06-09 at 20:46 +0300, Jonathan Morton wrote:
> In such cases you could reasonably configure fq_codel with a very
> large number of queues - I believe it supports 65536 out of the box -
> and/or to provide host fairness instead of flow fairness. A planned
> enhancement to cake (which really is designed for the last mile -
> fq_codel isn't so specialised) is to provide both at once.
>
> In the default mode, fq_codel still degrades gracefully when faced
> with an extreme flow count, due to the natural incidence of hash
> collisions. Each Codel instance then applies to traffic from a subset
> of flows. Even under these conditions, a single unresponsive flow is
> reasonably well isolated, only interfering with traffic unfortunate
> enough to end up in the same queue by chance.
That's great, but I'm talking about how to do AQM on Nx100 Gbps packet
processing ASICs, not Linux boxes. And I agree that FQ is desirable,
but not always cost effective or feasible to retrofit.
So back to my previous point: is CoDel as described in
draft-ietf-aqm-codel-01 suitable *by itself* as an AQM for high-speed
links multiplexing lots (> 1K) of flows.
Ex/ RTT = 25 msec
#flows = 1K
To drop 1 packet/flow/RTT as you say, I need to drop 40K packets/sec.
CoDel ramps up to this drop rate after approximately eternity (~16e6
drops).
Has anyone tested CoDel (*not fq_codel*) in an environment with interval
~100 msec and #flows >= 1K? It would be easy enough to tweak the
control law ramp: just scale the calculation of drop interval by a
factor inversely proportional to link speed or average number of flows.
Regards,
// Steve
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
