Re: [aqm] PIE departure rate estimation

Dave Dolson <> Wed, 01 April 2015 21:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 01CD01A1E0B for <>; Wed, 1 Apr 2015 14:43:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.309
X-Spam-Status: No, score=-1.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3cvDzAk-j3nP for <>; Wed, 1 Apr 2015 14:43:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9288E1A19F4 for <>; Wed, 1 Apr 2015 14:43:04 -0700 (PDT)
Received: from ([fe80::68ac:f071:19ff:3455]) by ([::1]) with mapi id 14.03.0195.001; Wed, 1 Apr 2015 17:43:04 -0400
From: Dave Dolson <>
To: "Rong Pan (ropan)" <>, "" <>
Thread-Topic: [aqm] PIE departure rate estimation
Thread-Index: AQHQbMIGW+ot0iZ1OU6OZ2/eKhmRQZ04qyFA
Date: Wed, 1 Apr 2015 21:43:03 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830BB0BF4wtlexchp2sandvi_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [aqm] PIE departure rate estimation
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Apr 2015 21:43:08 -0000

Inline [DD]

From: Rong Pan (ropan) []
Sent: Wednesday, April 01, 2015 5:23 PM
To: Dave Dolson;
Subject: Re: [aqm] PIE departure rate estimation


Thanks for the valuable comments. We will see how we can incorporate them. For the comments below, please see inline.



From: Dave Dolson <<>>
Date: Wednesday, April 1, 2015 1:22 PM
To: "<>" <<>>
Subject: [aqm] PIE departure rate estimation


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.

Section 4.2 cites Little's Law as "est_del = qlen/depart_rate",
but according to Wikipedia<>aw>, 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.'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..."

David Dolson
Senior Software Architect, Sandvine Inc.