Re: [aqm] Questioning each PIE heuristic

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

Return-Path: <ropan@cisco.com>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B0D1297D6; Mon, 27 Mar 2017 18:04:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjE3vC5wyqV1; Mon, 27 Mar 2017 18:04:57 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B3FE1297CB; Mon, 27 Mar 2017 18:04:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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 rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Mar 2017 01:04:56 +0000
Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by rcdn-core-6.cisco.com (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 xch-aln-017.cisco.com (173.36.7.27) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 27 Mar 2017 20:04:55 -0500
Received: from xch-aln-017.cisco.com ([173.36.7.27]) by XCH-ALN-017.cisco.com ([173.36.7.27]) with mapi id 15.00.1210.000; Mon, 27 Mar 2017 20:04:55 -0500
From: "Rong Pan (ropan)" <ropan@cisco.com>
To: Bob Briscoe <ietf@bobbriscoe.net>, Greg White <g.white@CableLabs.com>, "FredBaker.IETF@gmail.com" <FredBaker.IETF@gmail.com>, "prenatar@cisco.com" <prenatar@cisco.com>
CC: AQM IETF list <aqm@ietf.org>, "De Schepper, Koen (Koen)" <koen.de_schepper@nokia.com>, tsvwg IETF list <tsvwg@ietf.org>
Thread-Topic: [aqm] Questioning each PIE heuristic
Thread-Index: AQHSpDHJy+lx1UjTYECfkxBsGJVX96GphvqA
Date: Tue, 28 Mar 2017 01:04:55 +0000
Message-ID: <D4FDD717.2636D%ropan@cisco.com>
References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net>
In-Reply-To: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.0.161029
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.35.73]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <FEB6B396D619284C9B850B5AB95323AB@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/aqm/R_18dtm7uurRqX829dxDh_iTALM>
Subject: Re: [aqm] Questioning each PIE heuristic
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Mar 2017 01:05:00 -0000

Bob,

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

Rong

On 3/23/17, 5:01 PM, "aqm on behalf of Bob Briscoe" <aqm-bounces@ietf.org
on behalf of ietf@bobbriscoe.net>; 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
>target.
>
>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
implementation
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.


>
>
>Cheers
>
>
>Bob
>
>
>
>
>-- 
>________________________________________________________________
>Bob Briscoehttp://bobbriscoe.net/
>
>_______________________________________________
>aqm mailing list
>aqm@ietf.org
>https://www.ietf.org/mailman/listinfo/aqm