Re: [aqm] Questioning each PIE heuristic

"Lautenschlaeger, Wolfram (Nokia - DE/Stuttgart)" <> Wed, 29 March 2017 06:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9DD3D129684; Tue, 28 Mar 2017 23:30:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 j2O_Q9rCRGLQ; Tue, 28 Mar 2017 23:30:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 394AB127601; Tue, 28 Mar 2017 23:30:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YDttaeAigfRNag3zH2kpXIUPg6pecN5DDYgvmpPADAg=; b=IHCt0Lby4jn4vQE9KEr4pEdGBQgMVhUlLSLiBlR0wwqlUvZCy0FpKo2JZOMtc46HQe3fkKQOkkapA/JkItwtHB/YOoVUPx1W8l/lYIqU8AE15m2ekeoS4wzRZofJAl48Ms7fgRJ1TBK2MsGRmMh259KZRNC/5UhtMahKvatZItA=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Wed, 29 Mar 2017 06:30:01 +0000
Received: from ([]) by ([]) with mapi id 15.01.1005.010; Wed, 29 Mar 2017 06:30:01 +0000
From: "Lautenschlaeger, Wolfram (Nokia - DE/Stuttgart)" <>
To: "Rong Pan (ropan)" <>, Luca Muscariello <>, "Bless, Roland (TM)" <>
CC: tsvwg IETF list <>, Fred Baker <>, Bob Briscoe <>, "De Schepper, Koen (Nokia - BE/Antwerp)" <>, Greg White <>, Jonathan Morton <>, AQM IETF list <>, Preethi Natarajan <>
Thread-Topic: [aqm] Questioning each PIE heuristic
Date: Wed, 29 Mar 2017 06:30:00 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: de-DE, en-US
Content-Language: en-US
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; DB6PR0701MB2117; 7:34nmCP3Sq6l6dvmL3IglD0K5zPJMfRHqZ7ZTcjQcK6Iw+rptP+a4umXyCZkJ+hb0nTNB8oBhEante78peLuL+4wjVfWmKHhe13kUo3xs+mreh1wcW6LhJ/htYC/V9MBnRP3FnNkhbHAmG1wQg14YwlhmkJ7EXQ+RFCkQQa1iXAkozzwA2JqPcVKebulm1teq7+q9qtKrYrP9PCQiU9DgU5VI1iGn82zZ3vKKPbdThCMkcZTq2gU1aWsSeXsu3VCHtoayRe2HUZ5ZGIZAT+KDNOstUJB1efMFlU+Fd6ICmYQ41ojhtJExx4ngxyCXO3HOyLykjvOlqMqYuEbWz8yinw==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(39410400002)(39400400002)(39850400002)(39860400002)(39840400002)(39450400003)(24454002)(377454003)(6436002)(39060400002)(606005)(8676002)(38730400002)(7696004)(77096006)(5660300001)(189998001)(81166006)(4326008)(6506006)(8936002)(54906002)(53936002)(7906003)(2900100001)(229853002)(7416002)(6116002)(54896002)(7736002)(55016002)(99286003)(53546009)(19609705001)(2950100002)(25786009)(6306002)(236005)(790700001)(3846002)(74316002)(102836003)(6246003)(9686003)(122556002)(33656002)(93886004)(3280700002)(2906002)(86362001)(2171002)(3660700001)(66066001)(50986999)(54356999)(76176999)(90052001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2117;; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
x-ms-office365-filtering-correlation-id: e27e70c7-a4db-46bd-9d12-08d4766d0740
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423072)(201703031133078); SRVR:DB6PR0701MB2117;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(82608151540597)(95692535739014)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040447)(601004)(2401047)(8121501046)(5005006)(93006041)(93001041)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(201703131423072)(201702281528072)(201703061421072)(201703061406072)(6072148); SRVR:DB6PR0701MB2117; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2117;
x-forefront-prvs: 0261CCEEDF
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB6PR0701MB294976A5C354DE281816E052E9350DB6PR0701MB2949_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2017 06:30:00.8167 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2117
Archived-At: <>
X-Mailman-Approved-At: Wed, 29 Mar 2017 08:04:17 -0700
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: Wed, 29 Mar 2017 06:34:12 -0000

To my understanding a proper operating AQM _is_ work-conserving. Packet drops occur, if any, when a reasonable queue is present. And as long as packets are present in the queue, the link runs at 100%. I cannot see any (AQM) mechanism that is holding back queued packets while the link is idle.


From: aqm [] On Behalf Of Rong Pan (ropan)
Sent: Dienstag, 28. März 2017 16:17
To: Luca Muscariello <>om>; Bless, Roland (TM) <>
Cc: tsvwg IETF list <>rg>; Fred Baker <>om>; Bob Briscoe <>et>; De Schepper, Koen (Nokia - BE/Antwerp) <>om>; Greg White <>om>; Jonathan Morton <>om>; AQM IETF list <>rg>; Preethi Natarajan <>
Subject: Re: [aqm] Questioning each PIE heuristic

Sorry for causing the confusion in choosing the word "work-conserving". If we apply AQM and can not achieving 100% line rate, i.e. losing throughput, it is a big No No. Since we are dealing with TCP traffic, excess drops can cause TCP to back off too much and under-utilize the link.


From: Luca Muscariello <<>>
Date: Tuesday, March 28, 2017 at 8:48 AM
To: "Bless, Roland (TM)" <<>>
Cc: Fred Baker <<>>, Jonathan Morton <<>>, tsvwg IETF list <<>>, Bob Briscoe <<>>, "De Schepper, Koen (Koen)" <<>>, Rong Pan <<>>, Greg White <<>>, AQM IETF list <<>>, Preethi Natarajan <<>>
Subject: Re: [aqm] Questioning each PIE heuristic

Work conserving is supposed to be referring to the scheduler.
I'm not familiar with work-conservation when it refers to active queue management.
I'm not sure it is actually defined.

I can understand that an AQM can produce under utilization of the link, but that is
different to work conservation. Or is it maybe more subtle than that?


On Tue, Mar 28, 2017 at 1:48 PM, Bless, Roland (TM) <<>> wrote:

Am 28.03.2017 um 13:39 schrieb Fred Baker:

> 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.

+1 (that's also the definition I use, so I'm lost here too)


aqm mailing list<>