On 8. nov. 2013, at 12:34, Preethi Natarajan <[email protected]> wrote:
> 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. ok, sorry - > 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 Thanks for the link. My point was just (along with Naeem) that it would be useful to compare PIE (or CoDel) against something else except CoDel and RED. When I just look at the graphs in the HPSR paper (sorry, didn't get to read it yet), again I see only PIE, CoDel, RED. We tried ARED and were surprised to see how good it works - which is not to say that it is the ideal - but it was surprisingly often better than these newer schemes, despite its age of 10+ years... as we all know, there are many schemes out there, quite often designed with the goal of removing RED's dependence on parameters. Cheers, Michael
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
