Hello Michael, all: Please see inline.
From: Michael Welzl <[email protected]> Date: Friday, November 8, 2013 2:11 PM To: Preethi Natarajan <[email protected]> Cc: Naeem Khademi <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [aqm] AQM schemes: Queue length vs. delay based > > On 8. nov. 2013, at 11:00, Preethi Natarajan <[email protected]> wrote: > >> Hi Naeem, all: >> >> Please see detailed responses inline. >> >> From: Naeem Khademi <[email protected]> >> Date: Thursday, November 7, 2013 10:50 PM >> To: Preethi Natarajan <[email protected]> >> Cc: "[email protected]" <[email protected]> >> Subject: Re: [aqm] AQM schemes: Queue length vs. delay based >> >> >> >>> >>> 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. >> >> We've experimented with timestamp-based delay inputs to PIE. We have not seen >> any noticeable difference between the dequeue-based scheme and the >> timestamp-based for all the scenarios Rong has presented at IETF thus far. >> Even in extreme bandwidth changing conditions dequeue-based scheme can adapt >> within few tupdate cycles. Again, PIE is flexible in its delay input >> mechanism and will go with whatever is the best possible option available on >> the platform. I don't think any latency based scheme can get better than that >> :). > > An AQM scheme should also work when the bandwidth is *not* changing. The > results that Naeem presented in ICCRG don't indicate that PIE is consistently > better than CoDel (which is also delay-based). I'm not trying to say if this > or that is better, just that statements like this one are rather handwavy. Just to clarify, my previous comment was w.r.t how queuing delay input to PIE or any latency based AQM scheme can't get better than the fact that the scheme should use the best possible queueing delay input available on the platform timestamp-based, dequeue-based or other flavors. There is nothing hand wavy in this statement. Of course, an AQM scheme should also work when the bandwidth is *not* changing. W.r.t the PIE results presented, there are few things we don't understand. We plan to follow-up with you on that, maybe on a separate thread. > > >>> 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! >> >> Our initial discussions considered more than just the RED varieties. As we've >> mentioned before, PIE is based on the concept of proportional integral (PI). >> PI is not something we discovered. PI controller has been around for long and >> you can refer to Hollot, Towsley et. al's paper from a decade ago for more >> information on PI based AQM scheme. We believe PI's strong theoretical >> stability is valuable for diverse deployment conditions and incorporated PI >> into our PIE design. We did our own set of theoretical analysis for PIE and >> we were proved right. You can find more details about that in our HPSR paper >> (http://www.ieee-hpsr.org/2013/) > > Another handwavy statement. Using a PI controller may be a good design idea, > but that alone doesn't really tell us much about the overall behavior. Again, I don't understand what is handwavy here. My comment was PI controller has theoretical backing on why its good for various deployment conditions. Here is the link to Hollot's paper I mentioned on PI design that also talks in detail about the overall behavior -- ftp://ftp.cs.umass.edu/pub/net/pub/MisraInfocom01-AQM-Controller.pdf Many thanks, Preethi
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
