Re: [aqm] Questioning each PIE heuristic

Bob Briscoe <> Thu, 30 March 2017 07:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5AB2D129542; Thu, 30 Mar 2017 00:46:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WWmNVnq3VXoh; Thu, 30 Mar 2017 00:46:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3CBAB1293E9; Thu, 30 Mar 2017 00:46:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=tfvhEbHj7ngsgBRHLmm5MuEEeNWTKf3ywkeciavyjgU=; b=KKJSX0O9dttmo2CpLBcDb2Mfs5 X+HY5n1ZZE/JEQRHYxb+ruBG6BNDri8QtjWA97DRNpvL+RI+olcCb2Ak08e9nO2BzUBR7Igxd60Pm 6G2byMEGIW6sHV5GwVcSflIv6+NRoDt2yCjMs2cIWZmpAYCSqihFSV4funFirYU0+/kN21RMEg8th b4Bz6B2ED2e9+t0jE6x197nXAW+eXp8/YFNqdG3A28pyblF9vJUNSscB2ySPRKs54UiphwMwJo05S 02uc6gM+cpS2bHWt+bpA7vud7RocfkL+axcnboKby9+zrwitdcC3qyuwlNpwpoXhokQ3TGFFz8HsW Y1G01BiQ==;
Received: from [] (port=62123 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from <>) id 1ctUn8-000056-0Z; Thu, 30 Mar 2017 08:46:46 +0100
To: Jonathan Morton <>, "Rong Pan (ropan)" <>
References: <> <> <>
Cc: Greg White <>, "" <>, AQM IETF list <>, tsvwg IETF list <>
From: Bob Briscoe <>
Message-ID: <>
Date: Thu, 30 Mar 2017 08:46:44 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
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: Thu, 30 Mar 2017 07:46:50 -0000


Picking up on an earlier point you made about avoiding heuristics by 
ensuring the underlying algo is sound,... that's precisely why I'm going 
through all the (9) PIE heuristics...

For PI2 we removed all but 2 and it worked the same or better than PIE 
in all our tests. I have been assessing each of the other 7 one by one 
for reinstatement. So far I've rejected 6. I think I can reject this 
last one by making the sampling time of the base PI algo dependent on 
the max link rate. Then when the queue goes idle, the base PI algo will 
decay drop down to zero no slower than the queue drains, without needing 
this extra heuristic. But I need to check that's realistic.

We will be writing all this up (probably in an update to the PI2 paper - 
I don't think the IETF PI2 spec is the right place for a critique of 
heuristics that it doesn't use).

Our aim is a completely sound AQM in a few lines of code and a few 
operations so it can be implemented everywhere with minimal resistance 
from developers due to performance concerns (e.g. cheap ethernet 
switches, cheap home gateways, carrier-grade equipment for thousands of 
users, etc).


On 28/03/17 07:25, Jonathan Morton wrote:
> By all means, avoid dropping packets when the queue is actually empty - that is, when you’re delivering the last packet in the queue.  In that case, there is no congestion to signal for.  But there really is no need to have any complex state-switching logic for that.  If your underlying algorithm is sound, it will naturally decay to zero packet drops if the empty-queue condition persists.
>   - Jonathan Morton

Bob Briscoe