I fully agree with the need to have AQMs that use "queuing delay" as metric and not "queue length" and this is already a bonus for algorithms that use this metric (e.g. PIE). However, I believe that one can possibly modify RED or its derivatives (e.g. Adaptive RED) to set their thresholds based on "queuing delay" as well (although such algorithms don't exists yet as of now). Whether the outcome of these modifications to xRED algorithms would make them better than PIE and/or CoDel is another subject and I'm not going to speculate on that here.
One specific issue with PIE is that it tries to *estimate* the queuing delay over a certain time interval (t_update) and still somehow uses the "queue length" and departure rate (over the interval) to estimate the queuing delay. So saying that PIE uses the queueing delay instead of queue length may not be 100% accurate. Moreover, in a varying bandwidth scenario, depending on how often the bandwidth changes and at what granularity, the derived "estimated queuing delay" by PIE might be an outdated information e.g. it shows how the channel has been (in term of delay) in the last 30ms and now how it is now! if I'm not mistaken that has been somehow resolved in DOCSIS 3.1 by coupling PIE's departure rate to the actual link layer rate. In overall, while there are of course significant improvements made in PIE's (and (FQ)-CoDel's) design, there are probably still lessons to be learned from xRED family (check http://urn.nb.no/URN:NBN:no-38868 to see some examples). Throwing away all the knowledge and improvement gained from RED-like AQMs, CHoKe, etc and coming up with brand-new AQMs without (experimentally) comparing them to the gallery of existing ones wouldn't be great! Cheers, Naeem On Thu, Nov 7, 2013 at 5:46 PM, Preethi Natarajan <[email protected]>wrote: > Hello AQMers: > > Just wanted to bring up the following item for discussion either as part > of the recommendations draft or the evaluation criteria during Friday's > session/mailing list. > > In access, edge and core routers the draining rate of a queue is affected > by traffic on other queues and thus can vary a lot (depending on the > deployment and traffic conditions). A queue length based AQM scheme such as > RED or derivatives tries to maintain the average queue size around a > predictable value under these changing draining rates. However, this queue > size translates to high queuing delay under low draining rates and > vice-versa. The unpredictability in resulting queueing delay was one of the > reasons why we opted PIE to be a latency-based scheme. > > A queue length based AQM scheme could be perfectly valid for certain > deployments. For deployments where predictable queuing delay is expected > under varying draining rates, a latency based AQM is critical. We believe > this should be brought about in discussions somewhere at AQM — perhaps in > the recommendations draft or w.r.t evaluation criteria. > > Thanks, > Preethi (on behalf of PIE team) > > > > _______________________________________________ > aqm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/aqm > >
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
