Hi, Sorry in case I misunderstood. More below:
On Mar 14, 2013, at 6:54 AM, Fred Baker (fred) <[email protected]> wrote: > > 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. Up to here, I agree. > 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. Just for clarification, you mean: mark it but not react to it? (Which is possible, because the nonce isn't used…) > 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. Okay, now I understand where this is coming from. > 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. I didn't say "using ECN for ECN-capable traffic" does that. For context, here's your scheme again: >> As I just said to Mikael, I don't think I worded that one well. I'm >> envisaging two thresholds, testing two stress levels. It a lower one, one >> marks ECN-capable traffic and drops non-ECN-capable traffic; at the higher >> one, one drops from all traffic. What "threshold" means in a given >> algorithm is algorithm-dependent, however. (Let's call the lower threshold M, and the higher one N.) Reading this again, I now see that I probably just misunderstood you - apologies. I had somehow thought that you'd *always* drop non-ECN-capable traffic at M, as opposed to the randomized behavior given by an AQM. This would have meant that only ECN-capable traffic can make the queue grow beyond M. I now see that this is surely not what you meant and agree that this makes sense - sorry. Cheers, Michael
