The below makes several mis-characterisations of codel in the first place, and then attempts to reason from there.
On Tue, Jun 9, 2015 at 9:11 AM, Steven Blake <slbl...@petri-meat.com> wrote: > I have a question about how CoDel (as defined in > draft-ietf-aqm-codel-01) behaves on high-speed (e.g., >= 1 Gbps) links. > If this has been discussed before, please just point me in the right > direction. > > In the text below, I'm using "drop" to mean either packet discard/ECN > mark. I'm using (instantaneous) "drop frequency" to mean the inverse of > the interval between consecutive "drops" during a congestion epoch, > measured in drops/sec. > > The control law for CoDel computes the next time to drop a packet, and > is given as: > > t + interval/sqrt(count) > > where t is the current time, interval is a value roughly proportional to > maximum RTT (recommended 100 msec), and count is cumulative number of > drops during a congestion epoch. No. Count is just a variable to control the curve of the drop rate. It is not constantly incremented, either, it goes up and down based on how successful it is at controlling the flow(s), only incrementing while latency exceeds the target, decrementing slightly after it stays below the target. The time spent below the target is not accounted for, so you might have a high "bang-bang" drop rate retained, when something goes above from below. This subtlety is something people consistently miss and something I tried to elucidate in the first stanford talk. >It is not hard to see that drop > frequency increases with sqrt(count). At the first drop, the frequency > is 10 drop/sec; after 100 drops it is 100 drops/sec; after 1000 drops it > is 316 drops/sec. > > On a 4 Mbps link serving say 1000 packets/sec (on average), CoDel > immediately starts dropping 1% of packets and ramps up to ~10% after 100 > drops (1.86 secs). No it will wait 100ms after stuff first exceeds the target, then progressively shoot harder based on the progress of the interval/sqrt(count). secondly people have this tendency to measure full size packets, or a 1k average packet. The reality is a dynamic range of 64 bytes to 64k (gso/tso/gro offloads). So bytes is a far better proxy than packets in order to think about this properly. offloads of various sorts bulking up packet sizes has been a headache. I favor reducing mss on highly congested underbuffered links (and bob favors sub-packet windows) to keep the "signal strength" up. The original definition of packet (circa 1962) was 1000 bits, with up to 8 fragments. I do wish the materials that were the foundation of packet behavior were online somewhere... > This seems like a reasonable range. On a 10 GE link > serving 2.5 MPPs on average, CoDel would only drop 0.013% of packets > after 1000 drops (which would occur after 6.18 secs). I am allergic to averages as a statistic in the network measurement case. > This doesn't seem > to be very effective. It's possible to reduce interval to ramp up drop > frequency more quickly, but that is counter-intuitive because interval > should be roughly proportional to maximum RTT, which is link-speed > independent. Except that tcp's drop their rates by (typically) half on a drop, and a matter of debate as to when on CE. > > 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. > > Regards, > > // Steve > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm -- Dave Täht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
