Please see inline… Rong
From: Dave Dolson <[email protected]<mailto:[email protected]>> Date: Wednesday, April 1, 2015 2:43 PM To: rong <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: RE: [aqm] PIE departure rate estimation Inline [DD] From: Rong Pan (ropan) [mailto:[email protected]] Sent: Wednesday, April 01, 2015 5:23 PM To: Dave Dolson; [email protected]<mailto:[email protected]> Subject: Re: [aqm] PIE departure rate estimation Dave, Thanks for the valuable comments. We will see how we can incorporate them. For the comments below, please see inline. Regards, Rong From: Dave Dolson <[email protected]<mailto:[email protected]>> Date: Wednesday, April 1, 2015 1:22 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: [aqm] PIE departure rate estimation In https://tools.ietf.org/html/draft-ietf-aqm-pie-00#section-4.3, it says, “We only measure the departure rate when there are sufficient data in the buffer” Why can’t departure rate be estimated regardless of queue size? Just count packets leaving over time? I’m wondering how to avoid the estimate getting stuck at the last value sampled when the queue had a certain quantity in it. >>>>>>>>>>>>RP: We need to make sure that there are enough data in the queue to >>>>>>>>>>>>guarantee a rate sample. The reason is that if a queue is empty >>>>>>>>>>>>from time to time, we can't measure its true draining rate. The >>>>>>>>>>>>time when the queue empty should be cut out of the drain time >>>>>>>>>>>>calculation. For simplicity, it is better to make sure we have >>>>>>>>>>>>enough data in the queue to ensure accurate rate measurement sample. [DD] I understand the rationale, but supposing p=0.1, but the queue has very few items in it, too few to obtain a rate calculation. What causes p to go to zero, since an update is not permitted? It isn’t obvious to me that the algorithm always stops for all input traffic patterns. >>>>>>>>>>>>>>RP: There are two calculations in the PIE algorithm: one is for p >>>>>>>>>>>>>>update and one is for calculate the rate. They are independent >>>>>>>>>>>>>>from each other. If there are not enough packets in the buffer, >>>>>>>>>>>>>>we simply don't update depart rate estimation, instead we use >>>>>>>>>>>>>>the previous value. However, the drop probability calculation is >>>>>>>>>>>>>>always updated. Hence, the "p" in your example will go down to 0. Section 4.2 cites Little’s Law as “est_del = qlen/depart_rate”, but according to Wikipedia<http://en.wikipedia.org/wiki/Little%27s_law>, the law uses arrival rate, not departure rate. I don’t know if it matters (I didn’t read Little’s proof), but this gives credence to the suggestion in section 6 that the algorithm could use arrival rate. And I think it might be easier to measure when the queue has few items in it. >>>>>>>>>>>>RP: what you mentioned is to calculate average number of customers >>>>>>>>>>>>in a system using the arrival. >>>>>>>>>>>>http://en.wikipedia.org/wiki/Little's_law Wikipedia also mentions >>>>>>>>>>>>that mean responseTime = MeanNumberInSystem / MeanThroughput. What >>>>>>>>>>>>we measure is the mean response time (latency). Hence, it is >>>>>>>>>>>>correct in our draft. [DD] Arrival (post drop) and departure rates are almost never the same at any instant. I guess they must average to the same value. Practically, it might not matter which is used, but I thought Little’s law should be cited correctly. In Wikipedia the law is cited one way and the example is shown another way. Furthermore there is this ominous comment: “When exploring Little’s law and learning to trust it, be aware of the common mistakes of using arrivals(work arriving) when throughput(work completed) is called for…” >>>>>>>>>>>>>RP: I understand the concern. But I think we have used it in the >>>>>>>>>>>>>right way. Arrival is related to how many customers/packets in a >>>>>>>>>>>>>system. However, given #of customers/packets in a system, the wait >>>>>>>>>>>>>time is directly related to the service time (inverse of >>>>>>>>>>>>>throughput), not arrival rate any more. David Dolson Senior Software Architect, Sandvine Inc.
_______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
