Re: [aqm] AQM schemes: Queue length vs. delay based

["Scheffenegger, Richard" <[e-mail]>]

[chair hat off]

Hi Michael,

>
>------------------------------------------
>>>>>>>>RP:  Again, the tight delay control comes from narrow-band bang-bang control with hard drops. The scenarios >that throughputs are good are in higher congestion scenarios where there are enough packets showing up to fill the >pipe. That is not the effectiveness of AQM. Tail drop with shallow buffer will have high throughput in those cases >too. Try a scenario when link is congested and a burst comes, see how many packets of that burst can go through.
>------------------------------------------
>
> Maybe we disagree about the goals... why would you want to allow a burst on an already congested link?

How do you define congested link?

You will want to be burst-tolerant on a link running at full capacity - but is such a link already congested?

In any case, defining a scenario that would lead to excessive buffering delay in the drop-tail case, and comparing this for various AQMs should be documented.



Richard Scheffenegger


From: [e-mail] [mailto:[e-mail]] On Behalf Of Michael Welzl
Sent: Freitag, 15. November 2013 20:36
To: Rong Pan (ropan)
Cc: Naeem Khademi; Preethi Natarajan; [e-mail]
Subject: Re: [aqm] AQM schemes: Queue length vs. delay based

Hi,

In line, but snipping some things away:



[About evaluating against other-than-RED AQMs] 
------------------------------------------
>>>>>>>>RP:  RED is the only one out there that got wide adoptions. Compared with the state of the art in products (not in papers) is the idea. But that does not mean we don't know/learn from other AQM schemes. As matter of fact, PI controller and AVQ came out about the same time. PIE also adopts the PI controller design. From my years of experience, I think PI controller is a better controller in this space as queue and rate lend themselves to be the proportional and integral pair.

Ok, fair point about RED, and I agree that a PI controller can do well. The "SoA in products" bit makes me wonder - I never really knew, but since it's in principle easy to deploy an AQM scheme (you design it, you like it, you put it in your product?), I always assumed that RED wouldn't be the only one out there.

Now from this and other recent discussions I get the impression that RED *is* the only one that was ever turned on, and maybe the only one shipped? Do you know, is that the case? Just curious...  I guess that some products would sell with a strange secret AQM scheme that works very well, or not? That was just my imagination.



>>>>>>>>RP: I disagree with the notion that ARED often performs better. If tight delay control comes from narrow-band bang-bang control, the tail drop with shallow buffer would behave similarly. For example, if target_delay = 1ms, min_th = 0.5ms and max_th = 1.5ms, the queue really allows one packet in the queue. I don't see how this will be different from tail drop.  Your throughput plot showed 25% throughput loss. This is a case considered good?

By "often" I mean pretty much all cases except the very lightly loaded or extremely low target delay cases that you keep referring to.


------------------------------------------
>>>>>>>>RP:  Again, the tight delay control comes from narrow-band bang-bang control with hard drops. The scenarios that throughputs are good are in higher congestion scenarios where there are enough packets showing up to fill the pipe. That is not the effectiveness of AQM. Tail drop with shallow buffer will have high throughput in those cases too. Try a scenario when link is congested and a burst comes, see how many packets of that burst can go through.
------------------------------------------

Maybe we disagree about the goals... why would you want to allow a burst on an already congested link?



Naeem and Preethi have agreed that some significant design changes would be necessary to make use of ARED as a new delay-based AQM. I agree, but mainly I'd expect these significant changes to deal with ECN (where we made the point that ALL AQMs should be changed in fact (*), but that's another story) and with WLAN scenarios, where ARED performed quite badly. We'll see - mainly we conclude that it's probably worth playing around with it.


---------------------------------------------
>>>>>>>>RP:  Sure. The significant design changes to ARED won't be just for ECN, but to address the core issue of how effective ARED is as an AQM scheme. Don't get us wrong -- we would be happy to see these improvements on ARED.  Just a side note and you seemed to know what happened in the early 2000 time frame.  Sally's ARED paper did not eventually publish because there was a consensus in the community that control analysis is essential in AQM (other papers like AVQ and PI do have control analysis). It would be great if your group can add in this space too, especially auto-tuning needs deeper understanding of the knobs involved. 

Well, sounds like your opinion about that consensus; no doubt that analysis makes a paper stronger, but also no point in speculating about the reasons why she never got it published.

Getting back to the matter at hand, call me naive, but it seems to me that ARED was doing just the right thing in mildly loaded to overloaded scenarios, i.e. "bang bang" control may be just the right thing to do then? On that basis, isn't it a matter of just detecting the lightly loaded scenarios and becoming less aggressive under these circumstances? I suppose that the control could be tuned to do that. But this is just speculative...

Cheers,
Michael