Re: [aqm] Questioning each PIE heuristic

"Rong Pan (ropan)" <> Tue, 28 March 2017 01:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E6B0D1297D6; Mon, 27 Mar 2017 18:04:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wjE3vC5wyqV1; Mon, 27 Mar 2017 18:04:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7B3FE1297CB; Mon, 27 Mar 2017 18:04:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3668; q=dns/txt; s=iport; t=1490663097; x=1491872697; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iRnV0Hfbc6M2N5vYU9IiIqKxK+LF9Ps4DERtE/n+U/g=; b=eWpxPUq6NnVOic9zOPiLsJ3O9rrexqshvT6E/v6h7z+EQcCK6+AB9OyC z4OFMx9lRMfieKihxv7IZ7lHqO0qOnnBuoPDIQec8p+Lb7urjMHtZJbpW j/DukpUD4zkLrC8AzvHt9BCPlvXzsCfpypcoqiPIqGwUeeycVxGinpw32 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQBptdlY/51dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQsHjWqnG4IOHwuFeAKDHj8YAQIBAQEBAQEBayiFFgIBAwE?= =?us-ascii?q?BJS0aCxACAQgOOCcLJQIEAQ0FigcOrXc6ik8BAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEYBYZOhG+EJ4YSAQScWwGSS4F8hSqKC5NkAR84gQRZFUGEWB2BY3WHMYEvgQ0?= =?us-ascii?q?BAQE?=
X-IronPort-AV: E=Sophos;i="5.36,234,1486425600"; d="scan'208";a="7590223"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Mar 2017 01:04:56 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v2S14u7f016426 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Mar 2017 01:04:56 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 27 Mar 2017 20:04:55 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Mon, 27 Mar 2017 20:04:55 -0500
From: "Rong Pan (ropan)" <>
To: Bob Briscoe <>, Greg White <>, "" <>, "" <>
CC: AQM IETF list <>, "De Schepper, Koen (Koen)" <>, tsvwg IETF list <>
Thread-Topic: [aqm] Questioning each PIE heuristic
Thread-Index: AQHSpDHJy+lx1UjTYECfkxBsGJVX96GphvqA
Date: Tue, 28 Mar 2017 01:04:55 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [aqm] Questioning each PIE heuristic
X-Mailman-Version: 2.1.22
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: Tue, 28 Mar 2017 01:05:00 -0000


Sorry for the late reply. I have been traveling. Please see inlineŠ


On 3/23/17, 5:01 PM, "aqm on behalf of Bob Briscoe" <
on behalf of> wrote:

>Rong, Preethi, Greg, Fred, and others involved in PIE,
>You may recall that when we wrote PI2 we didn't include any of PIE's
>heuristics. Mostly because PI2 solved the issues they addressed
>intrinsically. But we left some until we had checked their benefit,
>which is what I'm doing now...
>My first question is about this heuristic in PIE:
>          //Safeguard PIE to be work conserving
>          if ( (PIE->qdelay_old_ < QDELAY_REF/2 && PIE->drop_prob_ < 0.2)
>                || (queue_.byte_length() <= 2 * MEAN_PKTSIZE) ) {
>               return ENQUE;
>          }
>If it tests true, this block doesn't stop the calculation of drop_prob_
>evolving, but it disables it being able to lead to any random packet drop.
>I can understand why you want to disable packet drop when the queue is
>no more than 2 packets.
>My question is about the first half of the logical OR. The drop_prob_ <
>20% test will be true under normal non-overloaded conditions. So I have
>just realized that the qdelay_old_ < QDELAY_REF/2 test will turn off
>random drop very often. I would expect this to radically impact the
>behaviour of PIE. It seems to be overriding the PI controller as if you
>are thinking "actually we don't really trust the PI controller to leave
>it to do its thing, so we've overridden it a lot of the time." For
>instance, whenever a single long-running TCP flow with RTT about the
>same as the target delay is saw-toothing, this test will disable random
>drop completely during the lower half of every saw-tooth in the queue.
>Maybe that's OK, but...
>Without this test, the PI controller should reduce drop probability as
>the queue sawtooths down anyway. If another flow causes the queue to
>rise rapidly while it is under half the target, the PI controller is
>designed to detect such an increase and translate it into drop. But this
>heuristic suppresses any drop until the queue has exceeded half the
>So my questions are:
>Q1. What were the reasons for introducing such a frequent suppression of
>the PI algorithm (the RFC just says what this code does, not why)?

To be work conserving and avoid any unnecessary drops are the main reasons
behind it. 
Cisco had a not so successful algorithm before that is not work
conserving. So we are
extra cautious about being work conserving...

>Q2. Why use qdelay_old_ in the test? This seems to drive suppression of
>drop using stale state.

qdelay_old_ is the latency state currently stored. This is for
Considerations as we don¹t want to calculate qdelay_ on per packet basis.

>Q3. Having said that it looks like this heuristic will significantly
>alter PIE's behaviour, in tests under a very wide range of traffic
>conditions, link rates, mixed RTTs, traffic models etc, we have found
>that removing the heuristics makes no measurable difference to PIE's
>performance. So if you added this heuristic for a specific scenario,
>please describe it, so we can test for it.

Again, to be work conserving and avoid drops are our goal. I don¹t
think it would be hurtful to add those safeguards.

>Bob Briscoe
>aqm mailing list