On Tue, 2015-06-09 at 19:31 +0300, Jonathan Morton wrote: > > On 9 Jun, 2015, at 19:11, Steven Blake <[email protected]> wrote: > > > > 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). This doesn't seem > > to be very effective. > > Question: have you worked out what drop rate is required to achieve > control of a TCP at that speed? There are well-known formulae for > standard TCPs, particularly Reno. You might be surprised by the > result. > > Fundamentally, Codel operates on the principle that one mark/drop per > RTT per flow is sufficient to control a TCP, or a flow which behaves > like a TCP; *not* a particular percentage of packets. This is because > TCPs are generally required to perform multiplicative decrease upon a > *single* congestion event. The increasing count over time is meant to > adapt to higher flow counts and lower RTTs. Other types of flows tend > to be sparse and unresponsive in general, and must be controlled using > some harder mechanism if necessary.
I'm not worried about controlling one TCP. I'm worried about controlling a multiplex of > 10K TCPs (on average). > One such mechanism is to combine Codel with an FQ system, which is > exactly what fq_codel in Linux does. Fq_codel has been tested > successfully at 10Gbps. Codel then operates separately for each flow, > and unresponsive flows are isolated. FQ is very nice, but not always an option at the necessary scale for 10/100 Gbps links. Regards, // Steve _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
