Re: [aqm] PIE departure rate estimation

["Rong Pan (ropan)" <[e-mail]>]

Please see inline…

Rong

From: Dave Dolson <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, April 1, 2015 2:43 PM
To: rong <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [aqm] PIE departure rate estimation

Inline [DD]

From: Rong Pan (ropan) [mailto:[e-mail]]
Sent: Wednesday, April 01, 2015 5:23 PM
To: Dave Dolson; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, April 1, 2015 1:22 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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.