On Tue, 2015-06-09 at 13:52 -0700, David Lang wrote: > 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.
According to my calculations, with RTT = 25 msec and MTU = 1500 bytes, you need to be going around 29 Mbps average (oscillating between 2/3 and 4/3 of this) to need to see a drop every 40 seconds. For 1 Mbps average you need ~1.4 secs between drops. For 10K 1 Mbps flows you then need to drop ~7000 packets/sec (~0.8% drop frequency for MTU-sized packets on a 10 GE link). Of course this all assumes uniform stationary elephants which is never the case in real life, but you see how CoDel's drop frequency (for interval = 100 msec) is not even in the right ballpark. > > 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% The more flows you have, the more flows you need to nuke to slow things down even a little bit. The more flows you need to nuke, the faster you need to drop packets. Regards, // Steve _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
