IETF Logo Mail Archive

Re: [aqm] Questioning each PIE heuristic

Jonathan Morton <chromatix99@gmail.com> Tue, 28 March 2017 06:25 UTC

Return-Path: <chromatix99@gmail.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 74239129442; Mon, 27 Mar 2017 23:25:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 yFXJ6hSDeaQx; Mon, 27 Mar 2017 23:25:29 -0700 (PDT)
Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C043128CDB; Mon, 27 Mar 2017 23:25:28 -0700 (PDT)
Received: by mail-lf0-x230.google.com with SMTP id h125so32456926lfe.0; Mon, 27 Mar 2017 23:25:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9QKHxQul1VV0ET6/HK1FlJLmyHX3kM590g257eSlc1o=; b=KIgwnyByaQY73NT+OqUEndC6J4Qb1kdjj6DK7eiDxk2MeIMJY6G6e+b5BZG9vfkRNp 9TEjYe6csUVej7He8RwtEC6VDt68dC2wBCMJs5+VdV1wXJip9AZroaWBF/xkFF7AxKvf eQlNC79Zhn4ABG2dVMf2yr/OEa2s1sAQIQiEdshlEd6Es4FivLQ7nSeseBoTbHgS70FJ C7WA/+FlkXVBQ/mZPbeQmiPVloIx7VZNCMxYkV4mAG7aL/3Rb9Sw6fTYQ1bqQfBuZN/Z OPABEafo7NRjz9Jhpgn56jikDpYMEJF0k5O7LBdsHZGUJ/bbNGu2LBeux5giWoPsE/cC eFsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9QKHxQul1VV0ET6/HK1FlJLmyHX3kM590g257eSlc1o=; b=i4F+7IhLrK0JfFhqBBxKNnyaXeTFEqQ1qmF3keyT95i525vndhLXPGy5mMUlfkvZuh IwTSEHgb9D82EfgaTyY71x4ZWtgD/1sIAizQqVy2wYzitsQobm0a12qQ8OhTBSzAiQ7m ++dexbHoTw2zovECbs6gTWH+t1xBLbv4AU1o6PDNoLyBYvWO1a1KUdOMSvdU3OascsyH LVvVI6kCmC/LRIp878vxoOBS2tpnv6t1PfkUOIvheGgXC0/jG++ZYEghsmN5ARpGOn0a am0obDL9YUwuZ64alMfFkMpqk7/AYa02nlz6G0emW1yXKYCh3fJ42xhBlXtZ+RQddN/o DF4A==
X-Gm-Message-State: AFeK/H2udH0WeEGdmClqJgsm3I7FZMYb0OVX/Dy8u61BGl1mnBDRfwucD/qsUv9eG82ovw==
X-Received: by 10.46.22.92 with SMTP id 28mr971252ljw.55.1490682326531; Mon, 27 Mar 2017 23:25:26 -0700 (PDT)
Received: from [192.168.100.14] (37-219-158-10.nat.bb.dnainternet.fi. [37.219.158.10]) by smtp.gmail.com with ESMTPSA id f19sm493040lji.69.2017.03.27.23.25.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 27 Mar 2017 23:25:25 -0700 (PDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <D4FDD717.2636D%ropan@cisco.com>
Date: Tue, 28 Mar 2017 09:25:22 +0300
Cc: 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>, AQM IETF list <aqm@ietf.org>, "De Schepper, Koen (Koen)" <koen.de_schepper@nokia.com>, tsvwg IETF list <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com>
References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> <D4FDD717.2636D%ropan@cisco.com>
To: "Rong Pan (ropan)" <ropan@cisco.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/aqm/RbnHsz1uZDa1RLU2p4MmBeQbAMc>
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 06:25:30 -0000

> On 28 Mar, 2017, at 04:04, Rong Pan (ropan) <ropan@cisco.com> 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.

 - Jonathan Morton

v2.23.0 | Report a Bug | By Email