Re: [aqm] PIE departure rate estimation

"Rong Pan (ropan)" <> Wed, 01 April 2015 22:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BE3D51A87A1 for <>; Wed, 1 Apr 2015 15:27:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -13.91
X-Spam-Status: No, score=-13.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tqspeCDbGbbk for <>; Wed, 1 Apr 2015 15:27:37 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1E48C1A0451 for <>; Wed, 1 Apr 2015 15:27:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=17680; q=dns/txt; s=iport; t=1427927258; x=1429136858; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=dFeKMjphRSgRfRe22tSOcjJuNxZzMW2H1vZhyqbsXcw=; b=LH5rudNU+Dmrf+MlQ96dRYehh86GR1+/U5XjeK4yQzSsvEaN/p69LmWz hfMr8/w/OEzTWwOcV6MPl04dFe178djZ7VRQcMVfnNdeLPUYQWdE3RsrZ UCdI4G0ZR9eYC4VQqEzmrHmsLNrnb9q5EWTnHHsMxoJd/ZLWYg8Bg7pbL 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.11,506,1422921600"; d="scan'208,217";a="408874123"
Received: from ([]) by with ESMTP; 01 Apr 2015 22:27:37 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t31MRaR4003054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Apr 2015 22:27:36 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Wed, 1 Apr 2015 17:27:36 -0500
From: "Rong Pan (ropan)" <>
To: Dave Dolson <>, "" <>
Thread-Topic: [aqm] PIE departure rate estimation
Thread-Index: AQHQbMIGW+ot0iZ1OU6OZ2/eKhmRQZ04qyFA///v6gA=
Date: Wed, 1 Apr 2015 22:27:35 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D141BCEAD9C1ropanciscocom_"
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 22:27:39 -0000

Please see inline…


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

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.

>>>>>>>>>>>>>>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<>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…”

>>>>>>>>>>>>>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.