Re: [aqm] Questioning each PIE heuristic

Fred Baker <> Tue, 28 March 2017 11:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0ABC4129998; Tue, 28 Mar 2017 04:39:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 ojKIokzSYwQ7; Tue, 28 Mar 2017 04:39:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3020F129983; Tue, 28 Mar 2017 04:39:06 -0700 (PDT)
Received: by with SMTP id 76so2715986itj.0; Tue, 28 Mar 2017 04:39:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uzatusOboud4BsQ3OSffU2pCcQHUIg/brBfv/6SIjqE=; b=C0qHyN2wgvHGumpLrcD9E5Qe29T5Kk2KnpTJBW7BKQdqU2fR0+xGCO/b169oXIeI/d 9rdR7swWs9vPjIxv+81dZdnfeHD4xiTWV52+Mj4LDI8R01TfkHoM3L7k+2MPJqJ0oZFy iVVzhs+G+h/dEHSq61tVKS38C8Di4Nyo85pSVnXISc03pNPFh3VPjb0wKHOaAODgFSTe 6Hp+2W0fy7sYDKLQdC3cogpBV3vFPbHMpK6LSfFZqc8BC0t601p0wnbHXN6zTJlz35X6 jlxu6flOAXos4CUOeU4A6Hf0s/qWE3KB89IJ8eIUclLT0TCg4NLJFs1oPh/Pr8PbO+0z n7/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=uzatusOboud4BsQ3OSffU2pCcQHUIg/brBfv/6SIjqE=; b=TOT20sGhr/BT/XqUswj6pp31xvmB5YU9owEha0LnlQmGMblqkDUSLg+l9h2o86DdyH FZuifxulO8becDam63EU17C4RAyYgpdLt8k/4IF1iq2aa+Y63CrGXCTmNuGkDfmlT8Zd Ztx+bZH25U8T8nTz1P0aR2KjNPSuFHBGQQJFa1CK9b+Z+88EXvOvGmKyw73Om13r/bhP SIih8yXhyjDPHYi2dkklGajSZ1+qU7Cqn8p56nN0fs/GizY+17DonynuwIFxGxVP2du7 kkSywcezDUktnlIj0yhu+rGJPeJqNYDmbnrbyEYkOh+wBLomLsXnC5BlgZ+wkf7icoO9 Gh9A==
X-Gm-Message-State: AFeK/H0Ffv6YSLPMUCV6i4+n9UXUbkNI0VawAXj6lQBNE0agUxOLzSbeCG0A03RNTI97Vg==
X-Received: by with SMTP id f96mr25867600ioj.199.1490701145567; Tue, 28 Mar 2017 04:39:05 -0700 (PDT)
Received: from ?IPv6:2001:67c:1233::5c8b:aa3:1836:b8? ([2001:67c:1233:0:5c8b:aa3:1836:b8]) by with ESMTPSA id d12sm1761767iog.41.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 04:39:04 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Fred Baker <>
In-Reply-To: <>
Date: Tue, 28 Mar 2017 06:39:05 -0500
Cc: Rong Pan <>, Bob Briscoe <>, Greg White <>, Preethi Natarajan <>, AQM IETF list <>, "De Schepper, Koen (Koen)" <>, tsvwg IETF list <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Jonathan Morton <>
X-Mailer: Apple Mail (2.3259)
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 11:39:08 -0000

> On Mar 28, 2017, at 1:25 AM, Jonathan Morton <> wrote:
>> On 28 Mar, 2017, at 04:04, Rong Pan (ropan) <> wrote:
>>> 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...
> AQM algorithms are by definition *not* work-conserving, because they can drop packets.  By *definition*.  I therefore think you’re chasing a non-goal here, and you’re going to have to justify it much more clearly if it’s going to make it into an RFC.
> 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.

I'm not convinced I understand the definitions of "work conserving" and "non work conserving" in this context. A "work conserving" scheduling algorithm keeps an interface transmitting as long as there is data in the queue, while a non-work-conserving algorithm reduces the effective rate of the interface by spacing packets out.