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

["Rong Pan (ropan)" <[e-mail]>]

Please see inline…

Thanks,

Rong


From: Michael Welzl <[e-mail]<mailto:[e-mail]>>
Date: Friday, November 15, 2013 3:06 AM
To: Cisco Employee <[e-mail]<mailto:[e-mail]>>
Cc: Naeem Khademi <[e-mail]<mailto:[e-mail]>>, Preethi Natarajan <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [aqm] AQM schemes: Queue length vs. delay based

Hi,

Interesting discussion!

I would like to say that in my opinion the real value of what Naeem has presented is not so much in pushing ARED, but in:

- reminding people that there was AQM stuff done between RED and CoDel, and some of this is worth looking at. Rong, we're aware of at least some of your previous work, and I'm personally a fan of CHOKe. However I do understand that CHOKe is probably not appropriate for the problem we're trying to solve here ... but you know, there were lots and lots of others made (e.g. AVQ, just to toss another name of an AQM that seemed to be well done to me when I read about it all these years ago)

------------------------------------------
>>>>>>>RP: Thank you! The comment about throwing away all experiences sounded ignorant.  I am aware of AVQ, and I am a fan of virtual queue concept (brought out by Frank Kelly ) in general. PCN that Bob is pushing is along these lines of work. I wish the industry as a whole can embrace the concept.
------------------------------------------


- hopefully helping set the bar a bit higher regarding evaluations. I'm not saying we did enough (e.g. we didn't get to look at anything else than bulk TCP transfers yet), but I think we've done more than I have seen documented elsewhere so far (apologies if we missed a study; we tried to cover them in the table in our tech. rep.).


I just personally found it a bit pathetic to first see CoDel and PIE presented with comparisons against only themselves and RED, and then see that the more-than-a-decade-old-ARED very often performs better than both of them. It makes me wonder how many other 5-10 year old AQMs are at least as good as CoDel and PIE.

------------------------------------------
>>>>>>>>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.

>>>>>>>>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?
-----------------------------------------







About this:


RP: If low latencies are achieved at the cost of losing quite a bit of throughput, it is a no-starter for AQM design.

That's rather obvious  :-)    but it's about the relationship between the two. e.g., the evaluations in the original CoDel paper essentially showed that CoDel gave higher throughput than RED at the expense of more latency. That's not exactly convincing either, given that latency reduction is the main goal we're pursuing now. And for ARED, we're only talking about a subset of scenarios (and perhaps not even the most relevant ones -  e.g. do we really care that much about the throughput of one single TCP connection?). Let's not forget that in many scenarios that we looked at (in fact, I'd say this was the majority of cases) it had better throughput AND lower delay than CoDel and PIE. I would also venture to guess that the problem with low multiplexing cases could be addressed relatively easily.

------------------------------------------
>>>>>>>>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.
------------------------------------------




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.

Best Regards,

Rong
-------------------------------------------


Cheers,
Michael