On Mar 14, 2013, at 12:43 AM, Michael Welzl <[email protected]> wrote:
> Great, I turn on ECN, and that gives me more delay, just what I want! > And, even better: the more people use ECN, the more delay everybody gets. > > Seriously, I see the incentive idea behind this two-level marking idea, but > one has to carefully consider the increased delay vs. gained throughput > trade-off in such a scheme. I don't understand your comment. Fill me in please? If I have a tail-drop queue, TCP using CUBIC or New Reno seeks to keep the queue full. If the queue has N positions (there are many ways to measure a queue, bear with this one for the purpose of the example), worst case delay approximates waiting for N messages, and general case delay is predicted by queuing theory to shoot for N when the link has 95% utilization or whatever. With any AQM algorithm, the same queue will accept N messages in the event that it gets a burst, but will start marking/dropping at some point M significantly less than N, so that the queue depth tends to approximate M, not N. That's the whole point of any AQM algorithm. How M is chosen or predicted is of course different for various algorithms. The pushback I generally hear about ECN is that people will mark traffic as ECN-capable in order to work around AQM algorithms signaling early; to make them signal later. I am told that people do abuse the EF code point in order to make their traffic go into a priority queue, so I can imagine people doing this as well. What I am suggesting is that the AQM algorithm use the appropriate signal to make queue depth approximate M, whether than is ECN or loss depending on the traffic marking, and in the event of abuse do no worse than present it's-done-everywhere tail drop, in which the queue depth tends towards N. M < N. Remind me how saying that one will use ECN for ECN-capable traffic makes the average queue depth deeper? That makes no sense to me.
