Re: [aqm] Questioning each PIE heuristic
"Rong Pan (ropan)" <ropan@cisco.com> Wed, 29 March 2017 17:58 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 517CE12025C; Wed, 29 Mar 2017 10:58:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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, URIBL_BLOCKED=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 hZUnD2jIif2X; Wed, 29 Mar 2017 10:58:12 -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 90C9F128708; Wed, 29 Mar 2017 10:58:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18294; q=dns/txt; s=iport; t=1490810290; x=1492019890; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=b2NGVXLDIoLjYvehCEXK9Wc7BdP/LLP6hHjQm6F6rbY=; b=KKWP/0A64qz8y/NehirE3NNTPHvD6iqhgPamLbAjblqIQZGH3uxAVO0J zkZ8PllRAPIQ9YIcsMNfHYOd/3zV8F/b/0vB0rzZY3cECMnzSceFv34XA 819CTsqEcNL4y1V1YkySL7BWcYv8E5jh2tz0xGV2Jd2ZMnXYyfrLkTn6S w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AbAQAO9NtY/4oNJK1dDgsBAQEBAQEBAQEBAQcBAQEBAYJuPCthgQsHjWyRUYgYiAWFMYIOHwEKhXgCg0M/GAECAQEBAQEBAWsohRUBAQEBAgEBAStBCwULAgEIEQMBAQEoByEGCxQJCAIEAQ0FiXIDDQgOsBiHJg2DHwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhk6Eb4JRgiMWhS8FkCKMBDoBiiaDcYQ4kTOKb4h6AR84PkZZFUGGGz11iCmBDQEBAQ
X-IronPort-AV: E=Sophos;i="5.36,242,1486425600"; d="scan'208,217";a="8368292"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Mar 2017 17:58:08 +0000
Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v2THw9xS007196 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Mar 2017 17:58:09 GMT
Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 29 Mar 2017 12:58:08 -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; Wed, 29 Mar 2017 12:58:08 -0500
From: "Rong Pan (ropan)" <ropan@cisco.com>
To: "Lautenschlaeger, Wolfram (Nokia - DE/Stuttgart)" <wolfram.lautenschlaeger@nokia-bell-labs.com>, Luca Muscariello <luca.muscariello@gmail.com>, "Bless, Roland (TM)" <roland.bless@kit.edu>
CC: tsvwg IETF list <tsvwg@ietf.org>, Fred Baker <fredbaker.ietf@gmail.com>, Bob Briscoe <ietf@bobbriscoe.net>, "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>, Greg White <g.white@cablelabs.com>, Jonathan Morton <chromatix99@gmail.com>, AQM IETF list <aqm@ietf.org>, Preethi Natarajan <prenatar@cisco.com>
Thread-Topic: [aqm] Questioning each PIE heuristic
Thread-Index: AQHSpDHJy+lx1UjTYECfkxBsGJVX96GphvqAgACcnACAAFemgIAAArAAgAAQ0AD//9WnAIABUtMAgAB9L4A=
Date: Wed, 29 Mar 2017 17:58:08 +0000
Message-ID: <D5016D98.265A4%ropan@cisco.com>
References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> <D4FDD717.2636D%ropan@cisco.com> <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> <D05425F7-4AA8-42E1-A7AC-E5757F21C29B@gmail.com> <48f5f485-5d34-a768-4180-c5df761de005@kit.edu> <CAHx=1M5gMmAgp=9sPP8xhM-6gNTLxfANV1B_2rHWb8=hFCqEUA@mail.gmail.com> <D4FFE7E3.2655B%ropan@cisco.com> <DB6PR0701MB294976A5C354DE281816E052E9350@DB6PR0701MB2949.eurprd07.prod.outlook.com>
In-Reply-To: <DB6PR0701MB294976A5C354DE281816E052E9350@DB6PR0701MB2949.eurprd07.prod.outlook.com>
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.25.27]
Content-Type: multipart/alternative; boundary="_000_D5016D98265A4ropanciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/aqm/aG-Tf4kdIP435npdQ0x_FxqH3yI>
X-Mailman-Approved-At: Wed, 29 Mar 2017 15:29:34 -0700
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: Wed, 29 Mar 2017 17:58:15 -0000
We are not holding back queued packets when the link is idle. We stop dropping packets when the queue is shallow in order to avoid unnecessary drops that could cause TCP traffic to back off and stop sending traffic that will cause link idle. Rong From: "Lautenschlaeger, Wolfram (Nokia - DE/Stuttgart)" <wolfram.lautenschlaeger@nokia-bell-labs.com<mailto:wolfram.lautenschlaeger@nokia-bell-labs.com>> Date: Wednesday, March 29, 2017 at 2:30 AM To: Rong Pan <ropan@cisco.com<mailto:ropan@cisco.com>>, Luca Muscariello <luca.muscariello@gmail.com<mailto:luca.muscariello@gmail.com>>, "Bless, Roland (TM)" <roland.bless@kit.edu<mailto:roland.bless@kit.edu>> Cc: tsvwg IETF list <tsvwg@ietf.org<mailto:tsvwg@ietf.org>>, Fred Baker <fredbaker.ietf@gmail.com<mailto:fredbaker.ietf@gmail.com>>, Bob Briscoe <ietf@bobbriscoe.net<mailto:ietf@bobbriscoe.net>>, "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com<mailto:koen.de_schepper@nokia-bell-labs.com>>, Greg White <g.white@cablelabs.com<mailto:g.white@cablelabs.com>>, Jonathan Morton <chromatix99@gmail.com<mailto:chromatix99@gmail.com>>, AQM IETF list <aqm@ietf.org<mailto:aqm@ietf.org>>, Preethi Natarajan <prenatar@cisco.com<mailto:prenatar@cisco.com>> Subject: RE: [aqm] Questioning each PIE heuristic 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. Wolfram From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Rong Pan (ropan) Sent: Dienstag, 28. März 2017 16:17 To: Luca Muscariello <luca.muscariello@gmail.com<mailto:luca.muscariello@gmail.com>>; Bless, Roland (TM) <roland.bless@kit.edu<mailto:roland.bless@kit.edu>> Cc: tsvwg IETF list <tsvwg@ietf.org<mailto:tsvwg@ietf.org>>; Fred Baker <fredbaker.ietf@gmail.com<mailto:fredbaker.ietf@gmail.com>>; Bob Briscoe <ietf@bobbriscoe.net<mailto:ietf@bobbriscoe.net>>; De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com<mailto:koen.de_schepper@nokia-bell-labs.com>>; Greg White <g.white@cablelabs.com<mailto:g.white@cablelabs.com>>; Jonathan Morton <chromatix99@gmail.com<mailto:chromatix99@gmail.com>>; AQM IETF list <aqm@ietf.org<mailto:aqm@ietf.org>>; Preethi Natarajan <prenatar@cisco.com<mailto:prenatar@cisco.com>> 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. Rong From: Luca Muscariello <luca.muscariello@gmail.com<mailto:luca.muscariello@gmail.com>> Date: Tuesday, March 28, 2017 at 8:48 AM To: "Bless, Roland (TM)" <roland.bless@kit.edu<mailto:roland.bless@kit.edu>> Cc: Fred Baker <fredbaker.ietf@gmail.com<mailto:fredbaker.ietf@gmail.com>>, Jonathan Morton <chromatix99@gmail.com<mailto:chromatix99@gmail.com>>, tsvwg IETF list <tsvwg@ietf.org<mailto:tsvwg@ietf.org>>, Bob Briscoe <ietf@bobbriscoe.net<mailto:ietf@bobbriscoe.net>>, "De Schepper, Koen (Koen)" <koen.de_schepper@nokia.com<mailto:koen.de_schepper@nokia.com>>, Rong Pan <ropan@cisco.com<mailto:ropan@cisco.com>>, Greg White <g.white@cablelabs.com<mailto:g.white@cablelabs.com>>, AQM IETF list <aqm@ietf.org<mailto:aqm@ietf.org>>, Preethi Natarajan <prenatar@cisco.com<mailto:prenatar@cisco.com>> 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? Luca On Tue, Mar 28, 2017 at 1:48 PM, Bless, Roland (TM) <roland.bless@kit.edu<mailto:roland.bless@kit.edu>> wrote: Hi, 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) Regards, Roland _______________________________________________ aqm mailing list aqm@ietf.org<mailto:aqm@ietf.org> https://www.ietf.org/mailman/listinfo/aqm
- [aqm] Questioning each PIE heuristic Bob Briscoe
- Re: [aqm] Questioning each PIE heuristic Rong Pan (ropan)
- Re: [aqm] Questioning each PIE heuristic Jonathan Morton
- Re: [aqm] Questioning each PIE heuristic Fred Baker
- Re: [aqm] Questioning each PIE heuristic Jonathan Morton
- Re: [aqm] Questioning each PIE heuristic Bless, Roland (TM)
- Re: [aqm] Questioning each PIE heuristic Bob Briscoe
- Re: [aqm] Questioning each PIE heuristic Rong Pan (ropan)
- Re: [aqm] Questioning each PIE heuristic Luca Muscariello
- Re: [aqm] Questioning each PIE heuristic Rong Pan (ropan)
- Re: [aqm] Questioning each PIE heuristic Lautenschlaeger, Wolfram (Nokia - DE/Stuttgart)
- Re: [aqm] Questioning each PIE heuristic Bob Briscoe
- Re: [aqm] Questioning each PIE heuristic Rong Pan (ropan)
- Re: [aqm] Questioning each PIE heuristic Bob Briscoe
- Re: [aqm] Questioning each PIE heuristic Jonathan Morton
- Re: [aqm] Questioning each PIE heuristic - moving… Michael Menth
- Re: [aqm] Questioning each PIE heuristic Dave Dolson
- Re: [aqm] Questioning each PIE heuristic - moving… Bob Briscoe
- Re: [aqm] Questioning each PIE heuristic - moving… Michael Menth
- Re: [aqm] Questioning each PIE heuristic - moving… Bob Briscoe
- Re: [aqm] Questioning each PIE heuristic - moving… Rong Pan (ropan)
- Re: [aqm] Questioning each PIE heuristic - moving… Rong Pan (ropan)
- Re: [aqm] Questioning each PIE heuristic - moving… Bob Briscoe