> On 22 Nov, 2016, at 21:09, Bob Briscoe <[email protected]> wrote:
> 
> {Note 1} I have never got a good answer to my questions on aqm@ietf as to why 
> a sqrt that controls the shrinkage of the spacing between dropped packets has 
> something to do with the steady state law of Reno, particularly because the 
> law leads to linear growth in p over time.

If you have intervals between events which follow a 1/sqrt(N) sequence, where N 
is the number of preceding events, you get an event frequency which increases 
linearly with time.  This applies directly to Codel’s signalling strategy, 
which is to start at one mark per (assumed) RTT, and to increase the marking 
frequency if that was insufficient to control the queue.

When you have multiple Reno flows sharing a single queue, there is a sqrt(N) 
factor in several of the characteristics, where N is the number of flows.  When 
such a shared link becomes saturated, all of the flows must be signalled to 
slow down, but for stochastic reasons it’ll probably take more than N 
signalling events to do so.  Increasing the signalling frequency while the 
queue remains insufficiently controlled has a good chance of quickly finding 
all the flows, while dropping relatively few packets (of non-ECN flows).

I’m reasonably convinced that Codel is a near-optimal solution to congestion 
signalling on TCP-friendly flows.  Regrettably, the latter are not the only 
type of traffic actually found on the Internet.

Really, the central assumption of Codel is that each flow requires only one 
congestion signal event per RTT to cause it to back off.  Codel stops working 
well on traffic which doesn’t obey that assumption (a linear increase in drop 
frequency is inadequate to mitigate a flood - you need to work with drop 
probabilities for that), but it *does* work acceptably well with multiple flows 
sharing a queue, due to this operating-point search.

 - Jonathan Morton

_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm

Reply via email to