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 > >> 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 > :). 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. >> 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. Cheers, Michael
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
