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 > 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. Of course. Our initial discussions considered a latency based RED derivative. We later decided to focus on a proportional integral based control law instead of RED (see below for more). > > 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. Any latency based scheme requires the queueing delay to work with. The fact of the matter is, the queueing delay is not directly available on platforms. Some platforms can afford timestamping to figure the queuing delay but not all platforms can. In fact, over the past months we've come to realize that a latency based scheme is actually two different items at work (i) the control law and (ii) the mechanism which provides the queueing delay to this control law. This would be true for any latency based scheme, be it, PIE, CoDEL, FQ_CoDEL or xRED. Based on this observation, we plan to separate out the two components in PIE, possibly in the next version of the draft. The objective being that (ii) would vary with the platform and it could be direct input (if platform maintains it), timestamp-based (like in CoDEL derivatives), dequeue-based, or even others that we are exploring at the moment. The current version of the PIE draft fully acknowledges the fact that what PIE acquires with the dequee-based rate estimation is only an estimate of the queuing delay and not the actual (Section 4.2 of v00). The larger point for discussion here is a latency based AQM that uses queuing delay instead of queue length. > > 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 :). > > 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/) Thanks, Preethi
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
