From nobody Tue Mar 7 14:18:36 2017 Return-Path: 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 1115112961E; Tue, 7 Mar 2017 14:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 GN94iaKrzFtz; Tue, 7 Mar 2017 14:18:33 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C071B12963E; Tue, 7 Mar 2017 14:18:16 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 387A5B819B3; Tue, 7 Mar 2017 14:18:15 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20170307221815.387A5B819B3@rfc-editor.org> Date: Tue, 7 Mar 2017 14:18:15 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, aqm@ietf.org, rfc-editor@rfc-editor.org Subject: [aqm] RFC 8087 on The Benefits of Using Explicit Congestion Notification (ECN) X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.17 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, 07 Mar 2017 22:18:35 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8087 Title: The Benefits of Using Explicit Congestion Notification (ECN) Author: G. Fairhurst, M. Welzl Status: Informational Stream: IETF Date: March 2017 Mailbox: gorry@erg.abdn.ac.uk, michawe@ifi.uio.no Pages: 19 Characters: 46449 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-aqm-ecn-benefits-08.txt URL: https://www.rfc-editor.org/info/rfc8087 DOI: 10.17487/RFC8087 The goal of this document is to describe the potential benefits of applications using a transport that enables Explicit Congestion Notification (ECN). The document outlines the principal gains in terms of increased throughput, reduced delay, and other benefits when ECN is used over a network path that includes equipment that supports Congestion Experienced (CE) marking. It also discusses challenges for successful deployment of ECN. It does not propose new algorithms to use ECN nor does it describe the details of implementation of ECN in endpoint devices (Internet hosts), routers, or other network devices. This document is a product of the Active Queue Management and Packet Scheduling Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Mar 10 09:56:26 2017 Return-Path: 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 512371294C8 for ; Fri, 10 Mar 2017 09:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk 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 EcQgic0fliyj for ; Fri, 10 Mar 2017 09:56:22 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C86501295E4 for ; Fri, 10 Mar 2017 09:56:15 -0800 (PST) Received: from mail.toke.dk (localhost.localdomain [127.0.0.1]) by mail.toke.dk (Postfix) with ESMTPS id 635928FF8D; Fri, 10 Mar 2017 18:56:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1489168573; bh=HSDhswSaX9qt+i/PUqPzUWE1Wf1lAQwn6/8g+eBQ9x0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Mk6mYPN/A0yy3BZ9KCL/fgRKecfq0yx4mSr7b6kmKus9tadHsHgu8OcOc7DeoLpiM I2jrvF664yf2mBaccpRcKNuHF7G7CrerAOHUy1ecW8ugYuCcBBf9qsoRVHzuBC7QRn UJ34CNR9ZeaJX5QPbh8n2+9fa/9na5rHbAW3sZqmH3P/CuP1ggKtlBEVQQ3CPhxTtA 9bDW18jiR2K4JoKiH2Pizyh2IQe1kr4WrJ+VvrWG26VSSIWUqRN3WXJ6TloZqYT4TD EGy/LQ/miRhGreDvWen4l+4iXZDNPQPtTyX+h9pryxP5B1DEe6XEWrbNkVKnbw3WCQ mQVsFWKiLcuvg== Received: by alrua-karlstad.karlstad.toke.dk (Postfix, from userid 1000) id 438E5AA996C; Fri, 10 Mar 2017 18:56:13 +0100 (CET) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Jana Iyengar References: Date: Fri, 10 Mar 2017 18:56:13 +0100 In-Reply-To: (Jana Iyengar's message of "Tue, 14 Feb 2017 10:29:26 -0800") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87r325t3r6.fsf@alrua-karlstad> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: Wesley Eddy , aqm@ietf.org Subject: Re: [aqm] I am setting up a per holiday cron job X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 10 Mar 2017 17:56:24 -0000 Jana Iyengar writes: > As Wes responded, we're working out the bits of code and the license > in the draft. We have resolution, and I need to get a revised draft to > the AD with some changes in. Sooo... how's it going with that? ;) -Toke From nobody Sun Mar 12 17:40:33 2017 Return-Path: X-Original-To: aqm@ietf.org Delivered-To: aqm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F3B12940C; Sun, 12 Mar 2017 17:40:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148936563244.24757.2205372931452007647@ietfa.amsl.com> Date: Sun, 12 Mar 2017 17:40:32 -0700 Archived-At: Cc: aqm@ietf.org Subject: [aqm] I-D Action: draft-ietf-aqm-codel-07.txt X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 13 Mar 2017 00:40:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Active Queue Management and Packet Scheduling of the IETF. Title : Controlled Delay Active Queue Management Authors : Kathleen Nichols Van Jacobson Andrew McGregor Janardhan Iyengar Filename : draft-ietf-aqm-codel-07.txt Pages : 24 Date : 2017-03-10 Abstract: This document describes a general framework called CoDel (Controlled Delay) that controls bufferbloat-generated excess delay in modern networking environments. CoDel consists of an estimator, a setpoint, and a control loop. It requires no configuration in normal Internet deployments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-aqm-codel-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-aqm-codel-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 12:58:03 2017 Return-Path: X-Original-To: aqm@ietf.org Delivered-To: aqm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5083129AEE; Mon, 13 Mar 2017 12:58:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <148943508093.20370.11677117453897716490.idtracker@ietfa.amsl.com> Date: Mon, 13 Mar 2017 12:58:00 -0700 Archived-At: Cc: wes@mti-systems.com, aqm-chairs@ietf.org, ietf@kuehlewind.net, aqm@ietf.org, draft-ietf-aqm-codel@ietf.org Subject: [aqm] Last Call: (Controlled Delay Active Queue Management) to Experimental RFC X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org 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: Mon, 13 Mar 2017 19:58:02 -0000 The IESG has received a request from the Active Queue Management and Packet Scheduling WG (aqm) to consider the following document: - 'Controlled Delay Active Queue Management' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-03-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a general framework called CoDel (Controlled Delay) that controls bufferbloat-generated excess delay in modern networking environments. CoDel consists of an estimator, a setpoint, and a control loop. It requires no configuration in normal Internet deployments. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Mar 16 07:26:19 2017 Return-Path: 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 793EC129527 for ; Thu, 16 Mar 2017 07:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.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 yaDujOZxmNNy for ; Thu, 16 Mar 2017 07:26:14 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 7141012953B for ; Thu, 16 Mar 2017 07:26:12 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id o4so32875176ywd.3 for ; Thu, 16 Mar 2017 07:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=Q7nkoROmLy8vivCWhzp8oDHBL3o7wJX0oTamRbOc4JQ=; b=z3pS9p7CO1yNezGjgU+KjaToS5DxwaorbJFgTKJTay3Zw+VNR5CbBs6iKzGWm9Qmd2 Xo/T3k+OVdUmukWc41oi8Hs6oCvFVtDz+N4jJrkDUfa4ovIjaFUlQntBktHDsjQejHRM XAdKtKLuZPmIRE4lRl1Z705SuBjefnL8CCitxgGdmz2KoDee94+EtGGMfVSH1iMiaTz1 lGB0B0reDk6peqjepHGf16MSq3vC12pOC+dmILKjpXIhel51JWum09TOze34053gfyRj UoXvclpEaGF1hGF0ocMG8J0/hZQlT2C7Q08jrE9kvHZz6j93l33qigke7+5jWsA8WDDz 3Qgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=Q7nkoROmLy8vivCWhzp8oDHBL3o7wJX0oTamRbOc4JQ=; b=IuHE6l/zyPwZYRoihChDotqCqW8IMhhCjSFdxaDrsixtPLDQ/6bx3o6nQeLVnnf0GU fHJr09UvupQzhvcY0ShpKuHzdrH+Mgkb6dtyaNuO3vPzSXw02G+BEMPjLkCYMt5Z+Dty l/+cJeAK5J7jmX+MAq7y81heE3wxVCwWKWyz0X95m2cwOHKF+iBo3zXiS/RDi64O39+K 1Pd5PwMARLsVvBDQI5klWqAksDsm/3PKfXDW7WMTmzx1YjpD7BxkrVnkghRXpph7N+/W Dw2FbvFxPK70z+K68ADUTHK+n6EWOjof9/8ObQ6ZWvsqowdZMnh/CMAhU8cByw08YMuU 7c8w== X-Gm-Message-State: AFeK/H2MjMqg9SjT9HQuvZmOCq3L1+fWl1OhdR70g2qcoY4ITZgNiGilJmydY9b80CWY3Q== X-Received: by 10.107.16.217 with SMTP id 86mr10243098ioq.228.1489674371454; Thu, 16 Mar 2017 07:26:11 -0700 (PDT) Received: from [192.168.1.104] (cpe-76-188-215-129.neo.res.rr.com. [76.188.215.129]) by smtp.gmail.com with ESMTPSA id n10sm1697431itg.8.2017.03.16.07.26.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Mar 2017 07:26:10 -0700 (PDT) To: "aqm@ietf.org" From: Wesley Eddy Message-ID: <9ca75fc4-c92c-fd92-fe53-d732189e2bec@mti-systems.com> Date: Thu, 16 Mar 2017 10:26:06 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [aqm] WG status X-BeenThere: aqm@ietf.org 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, 16 Mar 2017 14:26:16 -0000 I think there are no surprises here, but as there is an IETF meeting coming up, I wanted to make sure the AQM WG status is clear. The final working group document (on CoDel) is now in IETF Last Call, on the main IETF list. AQM does not plan to meet in Chicago, and should be closed down as the CoDel draft becomes published. HOWEVER, the work on L4S and DualQ that has been discussed here is continuing in the TSVWG. People that are interested in this should definitely be joining the TSVWG list and discussing it there: https://www.ietf.org/mailman/listinfo/tsvwg TSVWG has agenda time planned in Chicago for L4S, so you may wish to participate there. For any additional or future work on AQM algorithms, implementation, etc., I think there will be several possible options that can apply depending on what the work is, including: ICCRG, TSVWG, AD-sponsoring, individual submissions, etc. As usual, ask the ADs when in doubt :) From nobody Fri Mar 17 01:39:12 2017 Return-Path: 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 83C2C126BF6 for ; Fri, 17 Mar 2017 01:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 EF0VJ3iMYzuC for ; Fri, 17 Mar 2017 01:39:09 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48A3C124D68 for ; Fri, 17 Mar 2017 01:39:08 -0700 (PDT) Received: from mail-mx01.uio.no ([129.240.10.26]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1conPd-0007cs-3k for aqm@ietf.org; Fri, 17 Mar 2017 09:39:05 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx01.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1conPc-0005OF-Eq for aqm@ietf.org; Fri, 17 Mar 2017 09:39:05 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <9ca75fc4-c92c-fd92-fe53-d732189e2bec@mti-systems.com> Date: Fri, 17 Mar 2017 09:39:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <089311A2-192B-4BF1-97C1-98D8F6E11770@ifi.uio.no> References: <9ca75fc4-c92c-fd92-fe53-d732189e2bec@mti-systems.com> To: "aqm@ietf.org" X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx01.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 4 sum rcpts/h 17 sum msgs/h 8 total rcpts 52838 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=-0.008, RP_MATCHES_RCVD=-0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 4BE7A014C31F0E9B20067CE74CE4C68A8E0749E1 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 12656 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [aqm] WG status X-BeenThere: aqm@ietf.org 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: Fri, 17 Mar 2017 08:39:11 -0000 Hi all, Please note that we also have a talk on TCP Prague scheduled in ICCRG: https://datatracker.ietf.org/meeting/98/agenda/iccrg/ Cheers, Michael > On 16 Mar 2017, at 15:26, Wesley Eddy wrote: >=20 > I think there are no surprises here, but as there is an IETF meeting = coming up, I wanted to make sure the AQM WG status is clear. >=20 > The final working group document (on CoDel) is now in IETF Last Call, = on the main IETF list. >=20 > AQM does not plan to meet in Chicago, and should be closed down as the = CoDel draft becomes published. HOWEVER, the work on L4S and DualQ that = has been discussed here is continuing in the TSVWG. People that are = interested in this should definitely be joining the TSVWG list and = discussing it there: >=20 > https://www.ietf.org/mailman/listinfo/tsvwg >=20 > TSVWG has agenda time planned in Chicago for L4S, so you may wish to = participate there. >=20 > For any additional or future work on AQM algorithms, implementation, = etc., I think there will be several possible options that can apply = depending on what the work is, including: ICCRG, TSVWG, AD-sponsoring, = individual submissions, etc. As usual, ask the ADs when in doubt :) >=20 >=20 >=20 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm From nobody Tue Mar 21 01:03:07 2017 Return-Path: X-Original-To: aqm@ietf.org Delivered-To: aqm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2793D12964F; Tue, 21 Mar 2017 01:03:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoav Nir To: Cc: draft-ietf-aqm-codel.all@ietf.org, ietf@ietf.org, aqm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149008338604.24977.6083947817909590331@ietfa.amsl.com> Date: Tue, 21 Mar 2017 01:03:06 -0700 Archived-At: Subject: [aqm] Review of draft-ietf-aqm-codel-07 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.22 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, 21 Mar 2017 08:03:06 -0000 Reviewer: Yoav Nir Review result: Has Nits Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document describes the CoDel (controlled delay) framework for reducing bufferbloat. It does a good job of describing the problem, outlining the solution and providing both a description of the algorithm (including pseudo-code) and linking to real world implementations. Two nits: 1. A lot of terms are used long before they are explained, such as Estimator, Sojourn time, Interval (BTW: if this is a moving interval the spec should probably say so). When reading sections 3 I concluded that the document was aimed at peopel who already knew all these terms and didn't need definitions, but then reading section 5 gave me a lot of a-ha moments about what I had read previously. 2. The security considerations section says "There are no specific security exposures associated with CoDel." CoDel is about dropping packets, so immediately I have to think how I could subvert a router running CoDel to drop other people's packets. Perhaps it is fine to say that there are no known attacks on CoDel and no steps necessary to mitigate such, but I think it's tempting fate and hackers to say that CoDel has no security exposures. From nobody Tue Mar 21 19:04:49 2017 Return-Path: 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 EA398129431; Tue, 21 Mar 2017 19:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 9C_m8rpmaEmZ; Tue, 21 Mar 2017 19:04:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A877126BF7; Tue, 21 Mar 2017 19:04:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DDF00375; Wed, 22 Mar 2017 02:04:36 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 22 Mar 2017 02:04:34 +0000 Received: from DGGEMA403-HUB.china.huawei.com (10.3.20.44) by nkgeml411-hub.china.huawei.com (10.98.56.70) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 22 Mar 2017 10:04:32 +0800 Received: from DGGEMA501-MBS.china.huawei.com ([169.254.4.56]) by DGGEMA403-HUB.china.huawei.com ([10.3.20.44]) with mapi id 14.03.0301.000; Wed, 22 Mar 2017 10:04:30 +0800 From: "Gengxuesong (Geng Xuesong)" To: Yoav Nir , "secdir@ietf.org" CC: "draft-ietf-aqm-codel.all@ietf.org" , "ietf@ietf.org" , "aqm@ietf.org" Thread-Topic: [aqm] Review of draft-ietf-aqm-codel-07 Thread-Index: AQHSohmrIModH2ljM06Ghh8sQcqdUqGgGhzw Date: Wed, 22 Mar 2017 02:04:30 +0000 Message-ID: References: <149008338604.24977.6083947817909590331@ietfa.amsl.com> In-Reply-To: <149008338604.24977.6083947817909590331@ietfa.amsl.com> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.169.123] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.58D1DBB4.01E4, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.56, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d1de04b9f72ef8ec43a766f971f4a0f3 Archived-At: Subject: Re: [aqm] Review of draft-ietf-aqm-codel-07 X-BeenThere: aqm@ietf.org 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, 22 Mar 2017 02:04:43 -0000 Hi,=20 I can not agree more on this. It is well written, but I really think I can get the point of the draft fas= ter if I can read the section 5 before section 3. Best Regards, Emma (Xuesong) -----Original Message----- From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Tuesday, March 21, 2017 4:03 PM To: secdir@ietf.org Cc: draft-ietf-aqm-codel.all@ietf.org; ietf@ietf.org; aqm@ietf.org Subject: [aqm] Review of draft-ietf-aqm-codel-07 Reviewer: Yoav Nir Review result: Has Nits Hi, I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. The document describes the CoDel (controlled delay) framework for reducing = bufferbloat. It does a good job of describing the problem, outlining the so= lution and providing both a description of the algorithm (including pseudo-= code) and linking to real world implementations.=20 Two nits: 1. A lot of terms are used long before they are explained, such as Estimato= r, Sojourn time, Interval (BTW: if this is a moving interval the spec shoul= d probably say so). When reading sections 3 I concluded that the document w= as aimed at peopel who already knew all these terms and didn't need definit= ions, but then reading section 5 gave me a lot of a-ha moments about what I= had read previously. 2. The security considerations section says "There are no specific security= exposures associated with CoDel." CoDel is about dropping packets, so imm= ediately I have to think how I could subvert a router running CoDel to drop= other people's packets. Perhaps it is fine to say that there are no known = attacks on CoDel and no steps necessary to mitigate such, but I think it's = tempting fate and hackers to say that CoDel has no security exposures. _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm From nobody Tue Mar 21 22:10:19 2017 Return-Path: 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 4ADA412945A for ; Tue, 21 Mar 2017 22:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 VanYPBYgSjf8 for ; Tue, 21 Mar 2017 22:10:15 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::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 B1F40129459 for ; Tue, 21 Mar 2017 22:10:15 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id r69so5253765vke.2 for ; Tue, 21 Mar 2017 22:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5Gm2jlSTFBRw+QETQ1oGEA0bzyEcP/oREwyeO7z1t+8=; b=F6RYfmt29GLe7A+S6p/TrlVfpFhHPQXRBdVkmylwAhymusm9jgzEinFjv1+8rZCXTX lGakX67QZAWi+oCaaKnxZu2v/1lLzHHBS0D4JsL6Au8Vf9CYMy1poS9WaPCF8rwInnOu kl4KeEDOSjHDJX+IhCyZNOJ/EPo7iNKes2Ct02G3fONzFXUIvV8d3CYLiw3JfEuIPQrJ s4zROaP1myX+Mm3x1VcmxavW5IBtKbMg09g2oJHeDo1zE+Qzu3Qqh0zBD8BM6zaz4Ccu sBf07zI/pZOTez17jRWjHTGFHvEdzCfAk+NwFSvZpKAAwzWtZSI3BkqInb4jZviwAxj9 BGmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5Gm2jlSTFBRw+QETQ1oGEA0bzyEcP/oREwyeO7z1t+8=; b=FBWdoCmZCIo1s3sukNsX/w1cCTiECvBgi4AePQEnp0M/61BSH55lDc+8O6kImHnRIa VBKAHLOaZBxoayPFa7IwRfgFAjPXBoracCE7Xr/DR9QQTkfgkZUhZ3A0JFdE3JR+qyqE TULYmTkQ+myeG83kkzvHALLB4ClppNnFQG/xXVvusgj+yB2qiqHF9kRrAYFdiYB9Lb7b SQWZ02GCj9OkM3fpwvys5A2SQoaidQ6Q/NsRxgb1fPmfq966w45oE1eB4MQCRyWRUR3X dx1MpUDX4YgcYVNsPGor8X1H0yEP+xs2/iG4RissMaHF5vlSxbXEzGuiXaV99Tk94DtS +qJg== X-Gm-Message-State: AFeK/H3eeHbhxqC5C9mW6dTw2x6lByF0gUuculh/TqBQn40BfVXijMleuwCmrwyjPzs4IdYv6Mzb9I1Tgk9hoE1d X-Received: by 10.176.74.155 with SMTP id s27mr14109789uae.143.1490159414417; Tue, 21 Mar 2017 22:10:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Tue, 21 Mar 2017 22:10:13 -0700 (PDT) In-Reply-To: References: <149008338604.24977.6083947817909590331@ietfa.amsl.com> From: Jana Iyengar Date: Tue, 21 Mar 2017 22:10:13 -0700 Message-ID: To: "Gengxuesong (Geng Xuesong)" Cc: Yoav Nir , "secdir@ietf.org" , "draft-ietf-aqm-codel.all@ietf.org" , "ietf@ietf.org" , "aqm@ietf.org" Content-Type: multipart/alternative; boundary=f403045ef6548e677b054b4ac607 Archived-At: Subject: Re: [aqm] Review of draft-ietf-aqm-codel-07 X-BeenThere: aqm@ietf.org 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, 22 Mar 2017 05:10:18 -0000 --f403045ef6548e677b054b4ac607 Content-Type: text/plain; charset=UTF-8 Thanks Yoav, Emma. I can try to move Sec 5 before Sec 3, if that helps. Yoav: What do you suggest we add for security considerations? Thanks for the reviews! - jana On Tue, Mar 21, 2017 at 7:04 PM, Gengxuesong (Geng Xuesong) < gengxuesong@huawei.com> wrote: > Hi, > > I can not agree more on this. > It is well written, but I really think I can get the point of the draft > faster if I can read the section 5 before section 3. > > > Best Regards, > Emma (Xuesong) > > -----Original Message----- > From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Yoav Nir > Sent: Tuesday, March 21, 2017 4:03 PM > To: secdir@ietf.org > Cc: draft-ietf-aqm-codel.all@ietf.org; ietf@ietf.org; aqm@ietf.org > Subject: [aqm] Review of draft-ietf-aqm-codel-07 > > Reviewer: Yoav Nir > Review result: Has Nits > > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments just > like any other last call comments. > > The document describes the CoDel (controlled delay) framework for reducing > bufferbloat. It does a good job of describing the problem, outlining the > solution and providing both a description of the algorithm (including > pseudo-code) and linking to real world implementations. > > Two nits: > > 1. A lot of terms are used long before they are explained, such as > Estimator, Sojourn time, Interval (BTW: if this is a moving interval the > spec should probably say so). When reading sections 3 I concluded that the > document was aimed at peopel who already knew all these terms and didn't > need definitions, but then reading section 5 gave me a lot of a-ha moments > about what I had read previously. > > 2. The security considerations section says "There are no specific > security exposures associated with CoDel." CoDel is about dropping > packets, so immediately I have to think how I could subvert a router > running CoDel to drop other people's packets. Perhaps it is fine to say > that there are no known attacks on CoDel and no steps necessary to mitigate > such, but I think it's tempting fate and hackers to say that CoDel has no > security exposures. > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > --f403045ef6548e677b054b4ac607 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Yoav, Emma. I can try to move Sec 5 before Sec 3, i= f that helps.
Yoav: What do you suggest we add for security considerati= ons?

Thanks for the reviews!
- jana<= /div>


On Tue, Mar 21, 2017 at 7:04 PM, Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com> wrote:
Hi,

I can not agree more on this.
It is well written, but I really think I can get the point of the draft fas= ter if I can read the section 5 before section 3.


Best Regards,
Emma (Xuesong)

-----Original Message-----
From: aqm [mailto:aqm-bounces@ietf.= org] On Behalf Of Yoav Nir
Sent: Tuesday, March 21, 2017 4:03 PM
To: secdir@ietf.org
Cc: draft-ietf-aqm-cod= el.all@ietf.org; ietf@ietf.org; aqm@ietf.org
Subject: [aqm] Review of draft-ietf-aqm-codel-07

Reviewer: Yoav Nir
Review result: Has Nits

Hi,

I have reviewed this document as part of the security directorate's ong= oing effort to review all IETF documents being processed by the IESG.=C2=A0= These comments were written primarily for the benefit of the security area= directors.=C2=A0 Document editors and WG chairs should treat these comment= s just like any other last call comments.

The document describes the CoDel (controlled delay) framework for reducing = bufferbloat. It does a good job of describing the problem, outlining the so= lution and providing both a description of the algorithm (including pseudo-= code) and linking to real world implementations.

Two nits:

1. A lot of terms are used long before they are explained, such as Estimato= r, Sojourn time, Interval (BTW: if this is a moving interval the spec shoul= d probably say so). When reading sections 3 I concluded that the document w= as aimed at peopel who already knew all these terms and didn't need def= initions, but then reading section 5 gave me a lot of a-ha moments about wh= at I had read previously.

2. The security considerations section says "There are no specific sec= urity exposures associated with CoDel."=C2=A0 CoDel is about dropping = packets, so immediately I have to think how I could subvert a router runnin= g CoDel to drop other people's packets. Perhaps it is fine to say that = there are no known attacks on CoDel and no steps necessary to mitigate such= , but I think it's tempting fate and hackers to say that CoDel has no s= ecurity exposures.

_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

--f403045ef6548e677b054b4ac607-- From nobody Tue Mar 21 22:15:34 2017 Return-Path: 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 43E45126B7F; Tue, 21 Mar 2017 22:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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, 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 PTrnNTS0L5OA; Tue, 21 Mar 2017 22:15:31 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 6AB7B1242F5; Tue, 21 Mar 2017 22:15:31 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id n11so26834026wma.0; Tue, 21 Mar 2017 22:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=lo9cWTZMulBLNJJsPrLhryDEhcoNvKm8b8lmD+hyHxg=; b=LcoMAD7nI9axHFd2bJmMgBoutPMxk+0BRW1SpQgMJ/tpA+JDd0fehwQ/O+mj4LVAhr imlbctRM8GZzP5Jsj4YOJx7YoFEGztLIbWqmL/AM7jtOjbckB4/xveSiyLKDUMjGy7IN eOQzO9SpYxvlQNI6FhKRZevyRMLtNuFm9TNjSMPQ0mEFzWFQoAZVtMsFEkaA1uPBDnB0 wWMRE42ls5pxrGNl5Jij3TAz9EzOs8ThkGogaLrHYU0rymaZ+Bk8IdbJOI7+6TEf5OQ8 SBQlCL0OHyAm4oiP48JENuNLY6r7DxXxX0P1Mn1gz+QsjiCIraerzgsLZ3auVQof5/27 6q0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=lo9cWTZMulBLNJJsPrLhryDEhcoNvKm8b8lmD+hyHxg=; b=snVewC/cZhygS8vUdjnjegbQojeiBdITGp5RTYJM4oO1GPWFchvI/FUSzvQdnfvDWf 5GdoN1I2zJbPtRlKMhZYRXy3YmbAQ11D2YhQxWqDp7v90Ll4VUKkuPTikrXdrZF/unc2 TzIZVIh3Ibqfv3beGehjB/2ey+J9Pfu56XEpPmEuS9yiTmFPv/zqEEJD8MM/V8fKxv67 FBdeiPL9RuamV2ws/AMC87OvyXefoHwCOA/LwqI1m3CjcIYs09aMKnoM/2uup1ZRphZy ClzHyEbg/tAF7mfqhLJFUlYLh17gLTWxd3pNs49gmJs/R2QwMbml1JG/RCDKHjn6e0r1 nHOw== X-Gm-Message-State: AFeK/H04eV41kUhy8RGzHGGkSLOziWkPZxq4sowndOsu6m2N/vd+JQtxzXGUSGS6aE0XsA== X-Received: by 10.28.55.138 with SMTP id e132mr5599740wma.6.1490159729938; Tue, 21 Mar 2017 22:15:29 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id u81sm328401wrb.67.2017.03.21.22.15.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Mar 2017 22:15:29 -0700 (PDT) From: Yoav Nir Message-Id: <3C9CECA3-D84E-4471-B4AF-EA1C5061CC90@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_A6D557CA-D55A-4A0A-8AE8-B5A59B241ECD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 22 Mar 2017 07:15:26 +0200 In-Reply-To: Cc: "Gengxuesong (Geng Xuesong)" , "secdir@ietf.org" , "draft-ietf-aqm-codel.all@ietf.org" , "ietf@ietf.org" , "aqm@ietf.org" To: Jana Iyengar References: <149008338604.24977.6083947817909590331@ietfa.amsl.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [aqm] Review of draft-ietf-aqm-codel-07 X-BeenThere: aqm@ietf.org 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, 22 Mar 2017 05:15:33 -0000 --Apple-Mail=_A6D557CA-D55A-4A0A-8AE8-B5A59B241ECD Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On 22 Mar 2017, at 7:10, Jana Iyengar wrote: > > Thanks Yoav, Emma. I can try to move Sec 5 before Sec 3, if that helps. Thanks. I think it will. > Yoav: What do you suggest we add for security considerations? How about: OLD: There are no specific security exposures associated with CoDel NEW: There are no known security exposures associated with CoDel at this time. Yoav --Apple-Mail=_A6D557CA-D55A-4A0A-8AE8-B5A59B241ECD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJY0ghvAAoJELhJCxUKWMyZ0qMIAMFaV/1VwjJx6+zZLL/Zr+Lq 1X1Mt70dc0cDK1/l/iHQvo0RFnLCD9sJUVoQzv0LBbvV5FNy6R96KwpoR4sRMjXD +z7YF7+LBCqAdAo/z1091bJ6h+LDwxbn8aZf7pqnxC6NkWEE1IR4B8BJbOOFy8yA 2lKP45G0tet6pvIrFM5qP4usPxmSzi0dw0+py/9R9jBQN2bTdtLAO2AqOm2WroHU UY7nVn9P/hZw5At5qH9dPMTACSE6gt+uuQVw9FLHw6SDwQb37M0+HPE6k1JLHPVI /ZVA0ni+1m6feOJtlyKTyp2vKwvdbHNqjV9QNSBizWDxJhEaDYJl5AodVBS8e5w= =+3oo -----END PGP SIGNATURE----- --Apple-Mail=_A6D557CA-D55A-4A0A-8AE8-B5A59B241ECD-- From nobody Tue Mar 21 22:20:56 2017 Return-Path: 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 020C5124281 for ; Tue, 21 Mar 2017 22:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 yzSEdmX9kCxd for ; Tue, 21 Mar 2017 22:20:47 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 676E31242F5 for ; Tue, 21 Mar 2017 22:20:47 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id d188so115339359vka.0 for ; Tue, 21 Mar 2017 22:20:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FEYvf2mRafRqOtc+czZVd9CIIrv/29TN0hWnEjVyAtw=; b=e8QvGkl1NvLOY1pZEzz64fc4Xxz936JCdYtsTScb0a3yWWtkX0no3PzXg9tJztfFLJ 8A/+JKPjyx3t5Sc4VKFegwIydDbf9fbYag2KOK4W4ATPeKMDE4QENb29u7mGh6WDlawA TQANsNEIl9jgzV6Z6U//4aFyXnkuod478UF4KihY+Ajfad7qOrZRc2Z6JBSiBGghSnku Wn3bFlWrAHdPte3FtJ3KCOLGbSX+lhin+hRPEMSbCSu6ccLZQS4CoCEnWAuG7D1Ju/Wy yjj26hnr5LlPIQDPrDO7p5gbBv4mJFTu+oIHinqmoZP1zqrJSojzASchyxbnQHU4+7pE bKIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FEYvf2mRafRqOtc+czZVd9CIIrv/29TN0hWnEjVyAtw=; b=qwMW6j+l3fpJkBEpJAsbZUphswd38Lk9dm5+/IaoNP+iZln3u2m0/9zSQtjpXLbNAC fXlk7LX8XEo7oda2JZWZfzYsYiNnE1fvbY0c6mbZTXHrjhMFvsfXVJQUWMJPapkcnMH8 JOQQPtvO5DIq2aeMgQvk90yS3oNoQvgA7GmEL3OnC1jXv5TsoujDVw37kPIfcFGtXdLD XsRxzWFlPlj3sW+98GCVKPH5mluA/uWd9WoqrURA4El+dLvBMiPohg1xNzPNb9RF9NWl yp44g3cEqYAkqzs9U8M9F9F4AaKZbvssofkKX0eVSJ7D5tSQL0/vXrulFHscnJHaxYw0 kWnw== X-Gm-Message-State: AFeK/H2++vTvBu7+DXumMz1ByLSZQBWBM2C6AY77c5Iijr1ec8XauIvQx5afCwFBBmHDeU4mZ04vTaOk6FzDpdS4 X-Received: by 10.176.16.5 with SMTP id f5mr13978324uab.13.1490160046244; Tue, 21 Mar 2017 22:20:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Tue, 21 Mar 2017 22:20:45 -0700 (PDT) In-Reply-To: <3C9CECA3-D84E-4471-B4AF-EA1C5061CC90@gmail.com> References: <149008338604.24977.6083947817909590331@ietfa.amsl.com> <3C9CECA3-D84E-4471-B4AF-EA1C5061CC90@gmail.com> From: Jana Iyengar Date: Tue, 21 Mar 2017 22:20:45 -0700 Message-ID: To: Yoav Nir Cc: "Gengxuesong (Geng Xuesong)" , "secdir@ietf.org" , "draft-ietf-aqm-codel.all@ietf.org" , "ietf@ietf.org" , "aqm@ietf.org" Content-Type: multipart/alternative; boundary=f403045e345e37540b054b4aec50 Archived-At: Subject: Re: [aqm] Review of draft-ietf-aqm-codel-07 X-BeenThere: aqm@ietf.org 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, 22 Mar 2017 05:20:50 -0000 --f403045e345e37540b054b4aec50 Content-Type: text/plain; charset=UTF-8 SGTM. Thanks! On Tue, Mar 21, 2017 at 10:15 PM, Yoav Nir wrote: > > > On 22 Mar 2017, at 7:10, Jana Iyengar wrote: > > > > Thanks Yoav, Emma. I can try to move Sec 5 before Sec 3, if that helps. > > Thanks. I think it will. > > > Yoav: What do you suggest we add for security considerations? > > How about: > > OLD: > There are no specific security exposures associated with CoDel > > NEW: > There are no known security exposures associated with CoDel at this > time. > > Yoav > > --f403045e345e37540b054b4aec50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
SGTM. Thanks!

On Tue, Mar 21, 2017 at 10:15 PM, Yoav Nir <ynir.ietf= @gmail.com> wrote:

> On 22 Mar 2017, at 7:10, Jana Iyengar <jri@google.com> wrote:
>
> Thanks Yoav, Emma. I can try to move Sec 5 before Sec 3, if that helps= .

Thanks. I think it will.

> Yoav: What do you suggest we add for security considerations?

How about:

OLD:
=C2=A0 =C2=A0There are no specific security exposures asso= ciated with CoDel

NEW:
=C2=A0 =C2=A0There are no known security exposures associated with CoDel at= this time.

Yoav


--f403045e345e37540b054b4aec50-- From nobody Thu Mar 23 17:01:09 2017 Return-Path: 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 E51D0128B4E; Thu, 23 Mar 2017 17:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 hC7igNsjZSWq; Thu, 23 Mar 2017 17:01:05 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C414B1288B8; Thu, 23 Mar 2017 17:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Cc:To:Subject:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=4R5bWXdKmR298kj1rF0bOoguGSq7llARF57Q8bCfoAU=; b=gwETugiL4LnlQ4egwLaYbqsALn HdH6UYNB3aRDOdN+jLR43vIbkwonxX0FEw1RU8DK2dKAL4eNrjOgzenY/cE3M8yle+Ch0w3Hzj6r4 BBXpY4VvnqmMtwzzHr3UEwkMH5YKS2E3aN606cHFYAwcFS9xBpcgJ7pRwABqJwF+/dAcrN2bfYB7+ m7v9Y6+Kg3QxNjT6tG1I+V3Qjs/oK6LxbJapOyQxEePAl27J7W5UzxADZsHEt6x+okvVvfoUeIx2E Xy4hUt6xGYb9QUTQuG3XJNKaPfA0Gxq7B8ERL10hyx7a/x6KqzJu8DLxtX8XHAfPuyOvA6MDNeEc1 PX23dqkg==; Received: from 203.6.208.46.dyn.plus.net ([46.208.6.203]:35334 helo=[192.168.0.3]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1crCf7-00015A-Ro; Fri, 24 Mar 2017 00:01:02 +0000 From: Bob Briscoe To: "Rong Pan (ropan)" , Greg White , FredBaker.IETF@gmail.com, prenatar@cisco.com Cc: "De Schepper, Koen (Koen)" , AQM IETF list , tsvwg IETF list Message-ID: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> Date: Fri, 24 Mar 2017 00:01:01 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 00:01:08 -0000 Rong, Preethi, Greg, Fred, and others involved in PIE, You may recall that when we wrote PI2 we didn't include any of PIE's heuristics. Mostly because PI2 solved the issues they addressed intrinsically. But we left some until we had checked their benefit, which is what I'm doing now... My first question is about this heuristic in PIE: //Safeguard PIE to be work conserving if ( (PIE->qdelay_old_ < QDELAY_REF/2 && PIE->drop_prob_ < 0.2) || (queue_.byte_length() <= 2 * MEAN_PKTSIZE) ) { return ENQUE; } If it tests true, this block doesn't stop the calculation of drop_prob_ evolving, but it disables it being able to lead to any random packet drop. I can understand why you want to disable packet drop when the queue is no more than 2 packets. My question is about the first half of the logical OR. The drop_prob_ < 20% test will be true under normal non-overloaded conditions. So I have just realized that the qdelay_old_ < QDELAY_REF/2 test will turn off random drop very often. I would expect this to radically impact the behaviour of PIE. It seems to be overriding the PI controller as if you are thinking "actually we don't really trust the PI controller to leave it to do its thing, so we've overridden it a lot of the time." For instance, whenever a single long-running TCP flow with RTT about the same as the target delay is saw-toothing, this test will disable random drop completely during the lower half of every saw-tooth in the queue. Maybe that's OK, but... Without this test, the PI controller should reduce drop probability as the queue sawtooths down anyway. If another flow causes the queue to rise rapidly while it is under half the target, the PI controller is designed to detect such an increase and translate it into drop. But this heuristic suppresses any drop until the queue has exceeded half the target. So my questions are: 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)? Q2. Why use qdelay_old_ in the test? This seems to drive suppression of drop using stale state. Q3. Having said that it looks like this heuristic will significantly alter PIE's behaviour, in tests under a very wide range of traffic conditions, link rates, mixed RTTs, traffic models etc, we have found that removing the heuristics makes no measurable difference to PIE's performance. So if you added this heuristic for a specific scenario, please describe it, so we can test for it. Cheers Bob -- ________________________________________________________________ Bob Briscoehttp://bobbriscoe.net/ From nobody Sat Mar 25 20:02:12 2017 Return-Path: X-Original-To: aqm@ietf.org Delivered-To: aqm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF79A1294CF; Sat, 25 Mar 2017 20:02:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Fernando Gont To: Cc: draft-ietf-aqm-codel.all@ietf.org, ietf@ietf.org, aqm@ietf.org, fgont@si6networks.com X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149049732959.11830.18161576308900341179@ietfa.amsl.com> Date: Sat, 25 Mar 2017 20:02:09 -0700 Archived-At: Subject: [aqm] Review of draft-ietf-aqm-codel-07 X-BeenThere: aqm@ietf.org X-Mailman-Version: 2.1.22 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: Sun, 26 Mar 2017 03:02:10 -0000 Reviewer: Fernando Gont Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-aqm-codel-07 Reviewer: Fernando Gont Review Date: 2017-03-25 IETF LC End Date: 2017-03-27 IESG Telechat date: 2017-04-13 Summary: The document is well written. However, there seem to be too many details that are left out in other associated documents. Whereas such details (including figures) are needed to understand this document, they should be included here. Either provide full explanations or summarize the outcome without details (there's text that somehow relies on the reading finding such figures elsewhere). Major issues: * Section 5.1, page 16: > A more detailed explanation with many pictures can be found in > http://www.ietf.org/proceedings/84/slides/slides-84-tsvarea-4.pdf . Unless I'm missing something, if this document is specifying CoDel, then all such details should be here. Minor issues: * General: The document would benefit from a terminology section. For example, only well into the I-D one finds definitions of terms such as "sojourn times" or "target setpoint". Not sure if those terms are supposed to be trivial/obvious to most people reading this document, but their non-definition left me trying to figure out what the terms were about before I was ale to better understand what you were describing. Page 3, Section 1: > o simple and efficient implementation (can easily span the spectrum > from low-end, linux-based access points and home routers up to > high-end commercial router silicon) There seems to be an unnecesary implicit "judgement" here, associating linux-based with low-end, and commercial with high end. I suggest you modify the text. Page 10: > count_ = (delta > 1 && now - drop_next_ < 16*interval_)? For clarity, I'd use additional parenthesis here. Nits/editorial comments: * Page 17: > The power vs. f curve for any AIMD TCP is monotone decreasing. Please expand the acronym. * Page 17: > simulation that this result holds for Reno, Cubic, and > Westwood[TSV84]. Missing space. Thanks! Fernando From nobody Mon Mar 27 18:05:01 2017 Return-Path: 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 E6B0D1297D6; Mon, 27 Mar 2017 18:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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_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, 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 wjE3vC5wyqV1; Mon, 27 Mar 2017 18:04:57 -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 7B3FE1297CB; Mon, 27 Mar 2017 18:04:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3668; q=dns/txt; s=iport; t=1490663097; x=1491872697; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iRnV0Hfbc6M2N5vYU9IiIqKxK+LF9Ps4DERtE/n+U/g=; b=eWpxPUq6NnVOic9zOPiLsJ3O9rrexqshvT6E/v6h7z+EQcCK6+AB9OyC z4OFMx9lRMfieKihxv7IZ7lHqO0qOnnBuoPDIQec8p+Lb7urjMHtZJbpW j/DukpUD4zkLrC8AzvHt9BCPlvXzsCfpypcoqiPIqGwUeeycVxGinpw32 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQBptdlY/51dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQsHjWqnG4IOHwuFeAKDHj8YAQIBAQEBAQEBayiFFgIBAwE?= =?us-ascii?q?BJS0aCxACAQgOOCcLJQIEAQ0FigcOrXc6ik8BAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEYBYZOhG+EJ4YSAQScWwGSS4F8hSqKC5NkAR84gQRZFUGEWB2BY3WHMYEvgQ0?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.36,234,1486425600"; d="scan'208";a="7590223" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Mar 2017 01:04:56 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v2S14u7f016426 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Mar 2017 01:04:56 GMT Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 27 Mar 2017 20:04:55 -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; Mon, 27 Mar 2017 20:04:55 -0500 From: "Rong Pan (ropan)" To: Bob Briscoe , Greg White , "FredBaker.IETF@gmail.com" , "prenatar@cisco.com" CC: AQM IETF list , "De Schepper, Koen (Koen)" , tsvwg IETF list Thread-Topic: [aqm] Questioning each PIE heuristic Thread-Index: AQHSpDHJy+lx1UjTYECfkxBsGJVX96GphvqA Date: Tue, 28 Mar 2017 01:04:55 +0000 Message-ID: References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> In-Reply-To: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> 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.35.73] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 01:05:00 -0000 Bob, Sorry for the late reply. I have been traveling. Please see inline=8A Rong On 3/23/17, 5:01 PM, "aqm on behalf of Bob Briscoe" wrote: >Rong, Preethi, Greg, Fred, and others involved in PIE, > >You may recall that when we wrote PI2 we didn't include any of PIE's >heuristics. Mostly because PI2 solved the issues they addressed >intrinsically. But we left some until we had checked their benefit, >which is what I'm doing now... > >My first question is about this heuristic in PIE: > > //Safeguard PIE to be work conserving > if ( (PIE->qdelay_old_ < QDELAY_REF/2 && PIE->drop_prob_ < 0.2) > || (queue_.byte_length() <=3D 2 * MEAN_PKTSIZE) ) { > return ENQUE; > } > >If it tests true, this block doesn't stop the calculation of drop_prob_ >evolving, but it disables it being able to lead to any random packet drop. > >I can understand why you want to disable packet drop when the queue is >no more than 2 packets. >My question is about the first half of the logical OR. The drop_prob_ < >20% test will be true under normal non-overloaded conditions. So I have >just realized that the qdelay_old_ < QDELAY_REF/2 test will turn off >random drop very often. I would expect this to radically impact the >behaviour of PIE. It seems to be overriding the PI controller as if you >are thinking "actually we don't really trust the PI controller to leave >it to do its thing, so we've overridden it a lot of the time." For >instance, whenever a single long-running TCP flow with RTT about the >same as the target delay is saw-toothing, this test will disable random >drop completely during the lower half of every saw-tooth in the queue. >Maybe that's OK, but... > >Without this test, the PI controller should reduce drop probability as >the queue sawtooths down anyway. If another flow causes the queue to >rise rapidly while it is under half the target, the PI controller is >designed to detect such an increase and translate it into drop. But this >heuristic suppresses any drop until the queue has exceeded half the >target. > >So my questions are: > >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.=20 Cisco had a not so successful algorithm before that is not work conserving. So we are extra cautious about being work conserving... > >Q2. Why use qdelay_old_ in the test? This seems to drive suppression of >drop using stale state. qdelay_old_ is the latency state currently stored. This is for implementation Considerations as we don=B9t want to calculate qdelay_ on per packet basis. > >Q3. Having said that it looks like this heuristic will significantly >alter PIE's behaviour, in tests under a very wide range of traffic >conditions, link rates, mixed RTTs, traffic models etc, we have found >that removing the heuristics makes no measurable difference to PIE's >performance. So if you added this heuristic for a specific scenario, >please describe it, so we can test for it. Again, to be work conserving and avoid drops are our goal. I don=B9t think it would be hurtful to add those safeguards. > > >Cheers > > >Bob > > > > >--=20 >________________________________________________________________ >Bob Briscoehttp://bobbriscoe.net/ > >_______________________________________________ >aqm mailing list >aqm@ietf.org >https://www.ietf.org/mailman/listinfo/aqm From nobody Mon Mar 27 23:25:32 2017 Return-Path: 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 In-Reply-To: Date: Tue, 28 Mar 2017 09:25:22 +0300 Cc: Bob Briscoe , Greg White , "FredBaker.IETF@gmail.com" , "prenatar@cisco.com" , AQM IETF list , "De Schepper, Koen (Koen)" , tsvwg IETF list Content-Transfer-Encoding: quoted-printable Message-Id: <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> To: "Rong Pan (ropan)" X-Mailer: Apple Mail (2.3124) Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 06:25:30 -0000 > On 28 Mar, 2017, at 04:04, Rong Pan (ropan) wrote: >=20 >> 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)? >=20 > To be work conserving and avoid any unnecessary drops are the main = reasons > behind it.=20 > 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=92re chasing a = non-goal here, and you=92re going to have to justify it much more = clearly if it=92s going to make it into an RFC. By all means, avoid dropping packets when the queue is actually empty - = that is, when you=92re 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 From nobody Tue Mar 28 04:39:09 2017 Return-Path: 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 0ABC4129998; Tue, 28 Mar 2017 04:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: 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: 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 ojKIokzSYwQ7; Tue, 28 Mar 2017 04:39:06 -0700 (PDT) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (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 3020F129983; Tue, 28 Mar 2017 04:39:06 -0700 (PDT) Received: by mail-it0-x243.google.com with SMTP id 76so2715986itj.0; Tue, 28 Mar 2017 04:39:06 -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=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; 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=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 10.107.169.227 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 smtp.gmail.com with ESMTPSA id d12sm1761767iog.41.2017.03.28.04.39.04 (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: <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> 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: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.3259) Archived-At: 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." 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: >=20 >=20 >> On 28 Mar, 2017, at 04:04, Rong Pan (ropan) wrote: >>=20 >>> 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)? >>=20 >> To be work conserving and avoid any unnecessary drops are the main = reasons >> behind it.=20 >> Cisco had a not so successful algorithm before that is not work >> conserving. So we are extra cautious about being work conserving... >=20 > AQM algorithms are by definition *not* work-conserving, because they = can drop packets. By *definition*. I therefore think you=E2=80=99re = chasing a non-goal here, and you=E2=80=99re going to have to justify it = much more clearly if it=E2=80=99s going to make it into an RFC. >=20 > By all means, avoid dropping packets when the queue is actually empty = - that is, when you=E2=80=99re 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.=20= From nobody Tue Mar 28 04:47:05 2017 Return-Path: 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 2CE1D1299B2; Tue, 28 Mar 2017 04:46:59 -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 VWASFV908Eku; Tue, 28 Mar 2017 04:46:57 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (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 EAC421299BC; Tue, 28 Mar 2017 04:46:53 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id x137so36285861lff.3; Tue, 28 Mar 2017 04:46:53 -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=cP2VIevEqGr2DvrVqfqVGJwKLEzRJzalYawF/qXpGcw=; b=ElK/ZQDWaJDIadpzzEzoKWv3+BDtiwtNJv34E0s/LvczabpeCSQPU+9SnbVUY28NXV wR3MtFogWfqWQQ1892k/LopaEA8UG+/gbTW1pMVaQXhbhEk0rm/DJhXGP1IXyy0DSHa+ 6H4eWv6Jk1qJzE/UaQ9TygGNWZnVcP4GnRCRFwtps4QLu0CiaSM2BBv5bnYVeD7pBEpt +zZn5eKRCd56fwb+qAwvoIlgsmijPaH2ZVjB47cUj9YyLIV04WlaebCf/KyUqRA6LWZV /PscKtf1VAsf20gUFfsrKimW+CZHITKnIAo8e3VYHFphIpw3/BU98t05vAg2QZv8d4V5 v8Aw== 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=cP2VIevEqGr2DvrVqfqVGJwKLEzRJzalYawF/qXpGcw=; b=B+hRn2KfKc/JIZ98Csg4GNkGgYv6bXDN54/2/0txEAJMXnq9y1kbNjwsbELAJg/e72 Girzn+mGm/IB8qzfn6ejmn/buQxTY37vSjgFBq7XNe2XV5XplIKy5RcgFu/oeQNOzKsR VJ0YHtwrZRSq9IKqDWo5QCi51ljEjoqtdd40v7EgnI80omSk5SQC3jhS161S2cLECw/W mGFF3JI7UfTsHXflOlDbPGaBUlYsOzm8dulCwPuJzJGBSs6RSuidXrUqkFcOkN11O3qL ChHTPztI8Bm7OML0Go54sf0WFeMjFw2du8DdRoTfhP5zERxHWDNbIDu1twt8aZknrwVH 0ESg== X-Gm-Message-State: AFeK/H2tjs4A/5m+NQE711t4OXRqhcnqBaJTDMu26oiNHqbeITfVLVzbt0NwLhLsn4BrAQ== X-Received: by 10.25.211.2 with SMTP id k2mr13160433lfg.61.1490701612260; Tue, 28 Mar 2017 04:46:52 -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 m2sm632776lfg.35.2017.03.28.04.46.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 28 Mar 2017 04:46:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jonathan Morton In-Reply-To: Date: Tue, 28 Mar 2017 14:46:48 +0300 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: <4C00F349-7F88-413A-AB1B-5487779301F8@gmail.com> References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> To: Fred Baker X-Mailer: Apple Mail (2.3124) Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 11:46:59 -0000 > On 28 Mar, 2017, at 14:39, Fred Baker = wrote: >=20 > 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. In which case the explanation makes even less sense, as PIE doesn=E2=80=99= t include a shaper. - Jonathan Morton From nobody Tue Mar 28 04:49:03 2017 Return-Path: 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 D8F791294F6; Tue, 28 Mar 2017 04:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 7e7k7op9g9Qs; Tue, 28 Mar 2017 04:48:53 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 836C9129431; Tue, 28 Mar 2017 04:48:53 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1cspcB-0002zA-2K; Tue, 28 Mar 2017 13:48:43 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id F32ACB00453; Tue, 28 Mar 2017 13:48:42 +0200 (CEST) To: Fred Baker , Jonathan Morton References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> Cc: tsvwg IETF list , Bob Briscoe , "De Schepper, Koen (Koen)" , Greg White , Rong Pan , AQM IETF list , Preethi Natarajan From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: <48f5f485-5d34-a768-4180-c5df761de005@kit.edu> Date: Tue, 28 Mar 2017 13:48:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1490701723. Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 11:48:56 -0000 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 From nobody Tue Mar 28 06:15:59 2017 Return-Path: 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 C95CD129983 for ; Tue, 28 Mar 2017 06:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 JdFts2lrUWif for ; Tue, 28 Mar 2017 06:15:56 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38E841298B7 for ; Tue, 28 Mar 2017 06:15:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc: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=854/T1eW40Gjvuhat9fD7guLxL4lM2e9/iCTZfnAGac=; b=7kV/97FIuYdbVf1GR/gmUGz0RJ RJsw2OiX0csMv+eJcNpbimlAvDpAxVgsLMtFFHEuhZ5rbhnmD/zcn9SQYNExZPZrZmXJ+WXNFsGUB 4MN8VG0wrGJoBXh0mG+xBsUFSZ4r8Mbsv5JWh84cS2UGKOuclUWKgz+w/38+w78a0C942OpMwZCzX AZRyfNTx7RrKDLhMOBhETYdikOm3r1DnGUJUy7krNfH7AlKoAIVRpnsi4gnYNeEG4NIDACQT9wt2B 73bmTdt6onIFgIaNtLhK/PDYto9n6DFUKh4J/ulr1tJPA8cwdDyu3EbsYa0G20R59IhHxZc+c/4/7 CodHAZ5g==; Received: from [77.88.71.158] (port=35658 helo=[172.16.5.179]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1csqyX-0003sl-Fe for aqm@ietf.org; Tue, 28 Mar 2017 14:15:54 +0100 To: aqm@ietf.org References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> From: Bob Briscoe Message-ID: <372077b2-d194-6fbe-ca1e-fb4e3e5e3d3d@bobbriscoe.net> Date: Tue, 28 Mar 2017 11:41:12 +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=windows-1252; 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 - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 13:15:59 -0000 Rong, Some comments inline. And one remaining question at the end... On 28/03/17 02:04, Rong Pan (ropan) wrote: > Bob, > > Sorry for the late reply. I have been traveling. Please see inlineŠ > > Rong > > On 3/23/17, 5:01 PM, "aqm on behalf of Bob Briscoe" on behalf of ietf@bobbriscoe.net> wrote: > >> Rong, Preethi, Greg, Fred, and others involved in PIE, >> >> You may recall that when we wrote PI2 we didn't include any of PIE's >> heuristics. Mostly because PI2 solved the issues they addressed >> intrinsically. But we left some until we had checked their benefit, >> which is what I'm doing now... >> >> My first question is about this heuristic in PIE: >> >> //Safeguard PIE to be work conserving >> if ( (PIE->qdelay_old_ < QDELAY_REF/2 && PIE->drop_prob_ < 0.2) >> || (queue_.byte_length() <= 2 * MEAN_PKTSIZE) ) { >> return ENQUE; >> } >> >> If it tests true, this block doesn't stop the calculation of drop_prob_ >> evolving, but it disables it being able to lead to any random packet drop. >> >> I can understand why you want to disable packet drop when the queue is >> no more than 2 packets. >> My question is about the first half of the logical OR. The drop_prob_ < >> 20% test will be true under normal non-overloaded conditions. So I have >> just realized that the qdelay_old_ < QDELAY_REF/2 test will turn off >> random drop very often. I would expect this to radically impact the >> behaviour of PIE. It seems to be overriding the PI controller as if you >> are thinking "actually we don't really trust the PI controller to leave >> it to do its thing, so we've overridden it a lot of the time." For >> instance, whenever a single long-running TCP flow with RTT about the >> same as the target delay is saw-toothing, this test will disable random >> drop completely during the lower half of every saw-tooth in the queue. >> Maybe that's OK, but... >> >> Without this test, the PI controller should reduce drop probability as >> the queue sawtooths down anyway. If another flow causes the queue to >> rise rapidly while it is under half the target, the PI controller is >> designed to detect such an increase and translate it into drop. But this >> heuristic suppresses any drop until the queue has exceeded half the >> target. >> >> So my questions are: >> >> 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... [BB] There is only a work-conservation problem if drop_early() is applied at enqueue. That's because, at enqueue, you don't yet know whether another packet will arrive to take the place of the packet you are deciding to drop. We're shifting drop_early() to dequeue {Note 1}. So to be work-conserving we can rely solely on the test on the other side of the logical OR above that suppresses any drop if "backlog < 2 MTU". That's the only heuristic that we are keeping so far, although I'm undecided about the "< QDELAY_REF/2" test, which (as you say) might be beneficial for other reasons than work conservation. But we have no tests that show that yet. {Note 1}: Because we're using sojourn time to measure the queue, so if we were still dropping on enqueue, each congestion signal would be delayed twice by the queue. > > >> Q2. Why use qdelay_old_ in the test? This seems to drive suppression of >> drop using stale state. > qdelay_old_ is the latency state currently stored. This is for > implementation > Considerations as we donąt want to calculate qdelay_ on per packet basis. [BB] Understood. We're using sojourn time per packet for the shifted FIFO scheduler anyway, so no extra cost. > >> Q3. Having said that it looks like this heuristic will significantly >> alter PIE's behaviour, in tests under a very wide range of traffic >> conditions, link rates, mixed RTTs, traffic models etc, we have found >> that removing the heuristics makes no measurable difference to PIE's >> performance. So if you added this heuristic for a specific scenario, >> please describe it, so we can test for it. > Again, to be work conserving and avoid drops are our goal. I donąt > think it would be hurtful to add those safeguards. [BB]: So that begs just one remaining question: Q: Do you have tests showing any benefit, specifically comparing with and without this "< QDELAY_REF/2" heuristic? Given the point of a (non-ECN) AQM is to introduce the right level of random drops, it seems strange to suppress some of them with an additional arbitrary rule. Thanks for your replies so far tho. They have helped me realize more reasons why PIE needs these heuristics, but PI2 might not. Bob > > >> >> Cheers >> >> >> Bob >> >> >> >> >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ >> >> _______________________________________________ >> aqm mailing list >> aqm@ietf.org >> https://www.ietf.org/mailman/listinfo/aqm > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Tue Mar 28 07:25:05 2017 Return-Path: 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 A255B1299ED for ; Tue, 28 Mar 2017 07:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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_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, 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 5x2unczSoTOU for ; Tue, 28 Mar 2017 07:25:01 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C4061299EE for ; Tue, 28 Mar 2017 07:24:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8856; q=dns/txt; s=iport; t=1490711095; x=1491920695; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=18JX2rq2ccqAwdv+gvtKPFXBN7iVf93V/WU0Xz4Dk3s=; b=K/O7soTq439vZvxqQ6PZzOwDfmVO8RjLmfoe7uVOd8dGi+YWAzggBIKe 0EFsh8C2VB7wQHzo6zJ0qO14A3Lka9SY3o+XuV5e3y3WcT07bWkatLF6d 9XuwvL0Qzoilautu2spgoG7pjy/OtFbJSH02JrDYI5Hay6fzpf+EHRz58 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C1AQDhcNpY/4UNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQsHg1uKD5FRlUyCDh8LhXgCGoMHPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?WAQEBAwEBIQQNOhsCAQgOCgICJgICAiULFRACBAESigcOrFuBbDqKSwEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBASCBC4VDhG+EJy0Xgm+CXwWcYAGGe4tTgXxUhFaKDZNpAR8?= =?us-ascii?q?4gQRZFUGEWB2BY3WHMYEvgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,236,1486425600"; d="scan'208";a="401218903" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Mar 2017 14:24:54 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v2SEOsPi010534 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Mar 2017 14:24:54 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; Tue, 28 Mar 2017 09:24:53 -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; Tue, 28 Mar 2017 09:24:53 -0500 From: "Rong Pan (ropan)" To: Bob Briscoe , "aqm@ietf.org" Thread-Topic: [aqm] Questioning each PIE heuristic Thread-Index: AQHSpDHJy+lx1UjTYECfkxBsGJVX96GphvqAgADkFgD///twAA== Date: Tue, 28 Mar 2017 14:24:53 +0000 Message-ID: References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> <372077b2-d194-6fbe-ca1e-fb4e3e5e3d3d@bobbriscoe.net> In-Reply-To: <372077b2-d194-6fbe-ca1e-fb4e3e5e3d3d@bobbriscoe.net> 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.35.73] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 14:25:04 -0000 W0JCXTogU28gdGhhdCBiZWdzIGp1c3Qgb25lIHJlbWFpbmluZyBxdWVzdGlvbjoNClE6IERvIHlv dSBoYXZlIHRlc3RzIHNob3dpbmcgYW55IGJlbmVmaXQsIHNwZWNpZmljYWxseSBjb21wYXJpbmcg d2l0aA0KYW5kIHdpdGhvdXQgdGhpcyAgIjwgUURFTEFZX1JFRi8yIiBoZXVyaXN0aWM/DQoNCg0K SWYgd2Ugc2V0IHRoZSBRREVMQVlfUkVGIHRvbyBsb3csIHdlIGhhdmUgc2VlbiBsb3NpbmcgdGhy b3VnaHB1dC4gVGhpcyBpcw0KcmVsYXRlZA0KdG8geW91ciBxdWVzdGlvbiByZWdhcmRpbmcgcWRl bGF5X29sZF8uIFlvdSBhcmUgdXNpbmcgc29qb3VybiB0aW1lIHdoaWxlDQp3ZSBrZXB0IHRoZSBz dGF0ZSBpbiBxZGVsYXlfb2xkXyB3aGljaCBjYW4NCmJlY29tZSBzdGFsZSBpZiB1cGRhdGVfaW50 ZXJ2YWwgaXMgbG9uZy4NCg0KUm9uZyAgDQoNCk9uIDMvMjgvMTcsIDY6NDEgQU0sICJhcW0gb24g YmVoYWxmIG9mIEJvYiBCcmlzY29lIiA8YXFtLWJvdW5jZXNAaWV0Zi5vcmcNCm9uIGJlaGFsZiBv ZiBpbkBib2JicmlzY29lLm5ldD4gd3JvdGU6DQoNCj5Sb25nLA0KPg0KPlNvbWUgY29tbWVudHMg aW5saW5lLiBBbmQgb25lIHJlbWFpbmluZyBxdWVzdGlvbiBhdCB0aGUgZW5kLi4uDQo+DQo+T24g MjgvMDMvMTcgMDI6MDQsIFJvbmcgUGFuIChyb3Bhbikgd3JvdGU6DQo+PiBCb2IsDQo+Pg0KPj4g U29ycnkgZm9yIHRoZSBsYXRlIHJlcGx5LiBJIGhhdmUgYmVlbiB0cmF2ZWxpbmcuIFBsZWFzZSBz ZWUgaW5saW5lxaANCj4+DQo+PiBSb25nDQo+Pg0KPj4gT24gMy8yMy8xNywgNTowMSBQTSwgImFx bSBvbiBiZWhhbGYgb2YgQm9iIEJyaXNjb2UiDQo+PjxhcW0tYm91bmNlc0BpZXRmLm9yZw0KPj4g b24gYmVoYWxmIG9mIGlldGZAYm9iYnJpc2NvZS5uZXQ+IHdyb3RlOg0KPj4NCj4+PiBSb25nLCBQ cmVldGhpLCBHcmVnLCBGcmVkLCBhbmQgb3RoZXJzIGludm9sdmVkIGluIFBJRSwNCj4+Pg0KPj4+ IFlvdSBtYXkgcmVjYWxsIHRoYXQgd2hlbiB3ZSB3cm90ZSBQSTIgd2UgZGlkbid0IGluY2x1ZGUg YW55IG9mIFBJRSdzDQo+Pj4gaGV1cmlzdGljcy4gTW9zdGx5IGJlY2F1c2UgUEkyIHNvbHZlZCB0 aGUgaXNzdWVzIHRoZXkgYWRkcmVzc2VkDQo+Pj4gaW50cmluc2ljYWxseS4gQnV0IHdlIGxlZnQg c29tZSB1bnRpbCB3ZSBoYWQgY2hlY2tlZCB0aGVpciBiZW5lZml0LA0KPj4+IHdoaWNoIGlzIHdo YXQgSSdtIGRvaW5nIG5vdy4uLg0KPj4+DQo+Pj4gTXkgZmlyc3QgcXVlc3Rpb24gaXMgYWJvdXQg dGhpcyBoZXVyaXN0aWMgaW4gUElFOg0KPj4+DQo+Pj4gICAgICAgICAgIC8vU2FmZWd1YXJkIFBJ RSB0byBiZSB3b3JrIGNvbnNlcnZpbmcNCj4+PiAgICAgICAgICAgaWYgKCAoUElFLT5xZGVsYXlf b2xkXyA8IFFERUxBWV9SRUYvMiAmJiBQSUUtPmRyb3BfcHJvYl8gPA0KPj4+MC4yKQ0KPj4+ICAg ICAgICAgICAgICAgICB8fCAocXVldWVfLmJ5dGVfbGVuZ3RoKCkgPD0gMiAqIE1FQU5fUEtUU0la RSkgKSB7DQo+Pj4gICAgICAgICAgICAgICAgcmV0dXJuIEVOUVVFOw0KPj4+ICAgICAgICAgICB9 DQo+Pj4NCj4+PiBJZiBpdCB0ZXN0cyB0cnVlLCB0aGlzIGJsb2NrIGRvZXNuJ3Qgc3RvcCB0aGUg Y2FsY3VsYXRpb24gb2YgZHJvcF9wcm9iXw0KPj4+IGV2b2x2aW5nLCBidXQgaXQgZGlzYWJsZXMg aXQgYmVpbmcgYWJsZSB0byBsZWFkIHRvIGFueSByYW5kb20gcGFja2V0DQo+Pj5kcm9wLg0KPj4+ DQo+Pj4gSSBjYW4gdW5kZXJzdGFuZCB3aHkgeW91IHdhbnQgdG8gZGlzYWJsZSBwYWNrZXQgZHJv cCB3aGVuIHRoZSBxdWV1ZSBpcw0KPj4+IG5vIG1vcmUgdGhhbiAyIHBhY2tldHMuDQo+Pj4gTXkg cXVlc3Rpb24gaXMgYWJvdXQgdGhlIGZpcnN0IGhhbGYgb2YgdGhlIGxvZ2ljYWwgT1IuIFRoZSBk cm9wX3Byb2JfIDwNCj4+PiAyMCUgdGVzdCB3aWxsIGJlIHRydWUgdW5kZXIgbm9ybWFsIG5vbi1v dmVybG9hZGVkIGNvbmRpdGlvbnMuIFNvIEkgaGF2ZQ0KPj4+IGp1c3QgcmVhbGl6ZWQgdGhhdCB0 aGUgcWRlbGF5X29sZF8gPCBRREVMQVlfUkVGLzIgdGVzdCB3aWxsIHR1cm4gb2ZmDQo+Pj4gcmFu ZG9tIGRyb3AgdmVyeSBvZnRlbi4gSSB3b3VsZCBleHBlY3QgdGhpcyB0byByYWRpY2FsbHkgaW1w YWN0IHRoZQ0KPj4+IGJlaGF2aW91ciBvZiBQSUUuIEl0IHNlZW1zIHRvIGJlIG92ZXJyaWRpbmcg dGhlIFBJIGNvbnRyb2xsZXIgYXMgaWYgeW91DQo+Pj4gYXJlIHRoaW5raW5nICJhY3R1YWxseSB3 ZSBkb24ndCByZWFsbHkgdHJ1c3QgdGhlIFBJIGNvbnRyb2xsZXIgdG8gbGVhdmUNCj4+PiBpdCB0 byBkbyBpdHMgdGhpbmcsIHNvIHdlJ3ZlIG92ZXJyaWRkZW4gaXQgYSBsb3Qgb2YgdGhlIHRpbWUu IiBGb3INCj4+PiBpbnN0YW5jZSwgd2hlbmV2ZXIgYSBzaW5nbGUgbG9uZy1ydW5uaW5nIFRDUCBm bG93IHdpdGggUlRUIGFib3V0IHRoZQ0KPj4+IHNhbWUgYXMgdGhlIHRhcmdldCBkZWxheSBpcyBz YXctdG9vdGhpbmcsIHRoaXMgdGVzdCB3aWxsIGRpc2FibGUgcmFuZG9tDQo+Pj4gZHJvcCBjb21w bGV0ZWx5IGR1cmluZyB0aGUgbG93ZXIgaGFsZiBvZiBldmVyeSBzYXctdG9vdGggaW4gdGhlIHF1 ZXVlLg0KPj4+IE1heWJlIHRoYXQncyBPSywgYnV0Li4uDQo+Pj4NCj4+PiBXaXRob3V0IHRoaXMg dGVzdCwgdGhlIFBJIGNvbnRyb2xsZXIgc2hvdWxkIHJlZHVjZSBkcm9wIHByb2JhYmlsaXR5IGFz DQo+Pj4gdGhlIHF1ZXVlIHNhd3Rvb3RocyBkb3duIGFueXdheS4gSWYgYW5vdGhlciBmbG93IGNh dXNlcyB0aGUgcXVldWUgdG8NCj4+PiByaXNlIHJhcGlkbHkgd2hpbGUgaXQgaXMgdW5kZXIgaGFs ZiB0aGUgdGFyZ2V0LCB0aGUgUEkgY29udHJvbGxlciBpcw0KPj4+IGRlc2lnbmVkIHRvIGRldGVj dCBzdWNoIGFuIGluY3JlYXNlIGFuZCB0cmFuc2xhdGUgaXQgaW50byBkcm9wLiBCdXQNCj4+PnRo aXMNCj4+PiBoZXVyaXN0aWMgc3VwcHJlc3NlcyBhbnkgZHJvcCB1bnRpbCB0aGUgcXVldWUgaGFz IGV4Y2VlZGVkIGhhbGYgdGhlDQo+Pj4gdGFyZ2V0Lg0KPj4+DQo+Pj4gU28gbXkgcXVlc3Rpb25z IGFyZToNCj4+Pg0KPj4+IFExLiBXaGF0IHdlcmUgdGhlIHJlYXNvbnMgZm9yIGludHJvZHVjaW5n IHN1Y2ggYSBmcmVxdWVudCBzdXBwcmVzc2lvbg0KPj4+b2YNCj4+PiB0aGUgUEkgYWxnb3JpdGht ICh0aGUgUkZDIGp1c3Qgc2F5cyB3aGF0IHRoaXMgY29kZSBkb2VzLCBub3Qgd2h5KT8NCj4+DQo+ PiBUbyBiZSB3b3JrIGNvbnNlcnZpbmcgYW5kIGF2b2lkIGFueSB1bm5lY2Vzc2FyeSBkcm9wcyBh cmUgdGhlIG1haW4NCj4+cmVhc29ucw0KPj4gYmVoaW5kIGl0Lg0KPj4gQ2lzY28gaGFkIGEgbm90 IHNvIHN1Y2Nlc3NmdWwgYWxnb3JpdGhtIGJlZm9yZSB0aGF0IGlzIG5vdCB3b3JrDQo+PiBjb25z ZXJ2aW5nLiBTbyB3ZSBhcmUNCj4+IGV4dHJhIGNhdXRpb3VzIGFib3V0IGJlaW5nIHdvcmsgY29u c2VydmluZy4uLg0KPltCQl0gVGhlcmUgaXMgb25seSBhIHdvcmstY29uc2VydmF0aW9uIHByb2Js ZW0gaWYgZHJvcF9lYXJseSgpIGlzDQo+YXBwbGllZCBhdCBlbnF1ZXVlLiBUaGF0J3MgYmVjYXVz ZSwgYXQgZW5xdWV1ZSwgeW91IGRvbid0IHlldCBrbm93DQo+d2hldGhlciBhbm90aGVyIHBhY2tl dCB3aWxsIGFycml2ZSB0byB0YWtlIHRoZSBwbGFjZSBvZiB0aGUgcGFja2V0IHlvdQ0KPmFyZSBk ZWNpZGluZyB0byBkcm9wLg0KPg0KPldlJ3JlIHNoaWZ0aW5nIGRyb3BfZWFybHkoKSB0byBkZXF1 ZXVlIHtOb3RlIDF9LiBTbyB0byBiZQ0KPndvcmstY29uc2VydmluZyB3ZSBjYW4gcmVseSBzb2xl bHkgb24gdGhlIHRlc3Qgb24gdGhlIG90aGVyIHNpZGUgb2YgdGhlDQo+bG9naWNhbCBPUiBhYm92 ZSB0aGF0IHN1cHByZXNzZXMgYW55IGRyb3AgaWYgImJhY2tsb2cgPCAyIE1UVSIuICBUaGF0J3MN Cj50aGUgb25seSBoZXVyaXN0aWMgdGhhdCB3ZSBhcmUga2VlcGluZyBzbyBmYXIsIGFsdGhvdWdo IEknbSB1bmRlY2lkZWQNCj5hYm91dCB0aGUgICI8IFFERUxBWV9SRUYvMiIgdGVzdCwgd2hpY2gg KGFzIHlvdSBzYXkpIG1pZ2h0IGJlIGJlbmVmaWNpYWwNCj5mb3Igb3RoZXIgcmVhc29ucyB0aGFu IHdvcmsgY29uc2VydmF0aW9uLiBCdXQgd2UgaGF2ZSBubyB0ZXN0cyB0aGF0IHNob3cNCj50aGF0 IHlldC4NCj4NCj57Tm90ZSAxfTogQmVjYXVzZSB3ZSdyZSB1c2luZyBzb2pvdXJuIHRpbWUgdG8g bWVhc3VyZSB0aGUgcXVldWUsIHNvIGlmDQo+d2Ugd2VyZSBzdGlsbCBkcm9wcGluZyBvbiBlbnF1 ZXVlLCBlYWNoIGNvbmdlc3Rpb24gc2lnbmFsIHdvdWxkIGJlDQo+ZGVsYXllZCB0d2ljZSBieSB0 aGUgcXVldWUuDQo+DQo+Pg0KPj4NCj4+PiBRMi4gV2h5IHVzZSBxZGVsYXlfb2xkXyBpbiB0aGUg dGVzdD8gVGhpcyBzZWVtcyB0byBkcml2ZSBzdXBwcmVzc2lvbiBvZg0KPj4+IGRyb3AgdXNpbmcg c3RhbGUgc3RhdGUuDQo+PiBxZGVsYXlfb2xkXyBpcyB0aGUgbGF0ZW5jeSBzdGF0ZSBjdXJyZW50 bHkgc3RvcmVkLiBUaGlzIGlzIGZvcg0KPj4gaW1wbGVtZW50YXRpb24NCj4+IENvbnNpZGVyYXRp b25zIGFzIHdlIGRvbsK5dCB3YW50IHRvIGNhbGN1bGF0ZSBxZGVsYXlfIG9uIHBlciBwYWNrZXQN Cj4+YmFzaXMuDQo+W0JCXSBVbmRlcnN0b29kLg0KPldlJ3JlIHVzaW5nIHNvam91cm4gdGltZSBw ZXIgcGFja2V0IGZvciB0aGUgc2hpZnRlZCBGSUZPIHNjaGVkdWxlcg0KPmFueXdheSwgc28gbm8g ZXh0cmEgY29zdC4NCj4+DQo+Pj4gUTMuIEhhdmluZyBzYWlkIHRoYXQgaXQgbG9va3MgbGlrZSB0 aGlzIGhldXJpc3RpYyB3aWxsIHNpZ25pZmljYW50bHkNCj4+PiBhbHRlciBQSUUncyBiZWhhdmlv dXIsIGluIHRlc3RzIHVuZGVyIGEgdmVyeSB3aWRlIHJhbmdlIG9mIHRyYWZmaWMNCj4+PiBjb25k aXRpb25zLCBsaW5rIHJhdGVzLCBtaXhlZCBSVFRzLCB0cmFmZmljIG1vZGVscyBldGMsIHdlIGhh dmUgZm91bmQNCj4+PiB0aGF0IHJlbW92aW5nIHRoZSBoZXVyaXN0aWNzIG1ha2VzIG5vIG1lYXN1 cmFibGUgZGlmZmVyZW5jZSB0byBQSUUncw0KPj4+IHBlcmZvcm1hbmNlLiBTbyBpZiB5b3UgYWRk ZWQgdGhpcyBoZXVyaXN0aWMgZm9yIGEgc3BlY2lmaWMgc2NlbmFyaW8sDQo+Pj4gcGxlYXNlIGRl c2NyaWJlIGl0LCBzbyB3ZSBjYW4gdGVzdCBmb3IgaXQuDQo+PiBBZ2FpbiwgdG8gYmUgd29yayBj b25zZXJ2aW5nIGFuZCBhdm9pZCBkcm9wcyBhcmUgb3VyIGdvYWwuIEkgZG9uwrl0DQo+PiB0aGlu ayBpdCB3b3VsZCBiZSBodXJ0ZnVsIHRvIGFkZCB0aG9zZSBzYWZlZ3VhcmRzLg0KPg0KPltCQl06 IFNvIHRoYXQgYmVncyBqdXN0IG9uZSByZW1haW5pbmcgcXVlc3Rpb246DQo+UTogRG8geW91IGhh dmUgdGVzdHMgc2hvd2luZyBhbnkgYmVuZWZpdCwgc3BlY2lmaWNhbGx5IGNvbXBhcmluZyB3aXRo DQo+YW5kIHdpdGhvdXQgdGhpcyAgIjwgUURFTEFZX1JFRi8yIiBoZXVyaXN0aWM/DQo+DQo+R2l2 ZW4gdGhlIHBvaW50IG9mIGEgKG5vbi1FQ04pIEFRTSBpcyB0byBpbnRyb2R1Y2UgdGhlIHJpZ2h0 IGxldmVsIG9mDQo+cmFuZG9tIGRyb3BzLCBpdCBzZWVtcyBzdHJhbmdlIHRvIHN1cHByZXNzIHNv bWUgb2YgdGhlbSB3aXRoIGFuDQo+YWRkaXRpb25hbCBhcmJpdHJhcnkgcnVsZS4NCj4NCj4NCj5U aGFua3MgZm9yIHlvdXIgcmVwbGllcyBzbyBmYXIgdGhvLiBUaGV5IGhhdmUgaGVscGVkIG1lIHJl YWxpemUgbW9yZQ0KPnJlYXNvbnMgd2h5IFBJRSBuZWVkcyB0aGVzZSBoZXVyaXN0aWNzLCBidXQg UEkyIG1pZ2h0IG5vdC4NCj4NCj4NCj5Cb2INCj4NCj4+DQo+Pg0KPj4+DQo+Pj4gQ2hlZXJzDQo+ Pj4NCj4+Pg0KPj4+IEJvYg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gLS0gDQo+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+IEJvYiBCcmlzY29laHR0cDovL2JvYmJyaXNjb2UubmV0Lw0KPj4+DQo+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBhcW0gbWFpbGlu ZyBsaXN0DQo+Pj4gYXFtQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9hcW0NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+PiBhcW0gbWFpbGluZyBsaXN0DQo+PiBhcW1AaWV0Zi5vcmcNCj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXFtDQo+DQo+LS0gDQo+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PkJvYiBCcmlzY29lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9ib2Jicmlz Y29lLm5ldC8NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPmFxbSBtYWlsaW5nIGxpc3QNCj5hcW1AaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FxbQ0KDQo= From nobody Tue Mar 28 08:04:54 2017 Return-Path: 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 5DF13124281; Tue, 28 Mar 2017 05:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 4AzOy5EMki16; Tue, 28 Mar 2017 05:48:54 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 44CCF1200C1; Tue, 28 Mar 2017 05:48:54 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id i34so62724319qtc.0; Tue, 28 Mar 2017 05:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W6EfJgH7gvTRmrSe1FpFk4gWtvHbsbrIhEL5qltJ5EE=; b=JIG/kwOGnxmwNxgbsxGU2z+RwOJ1oQ0giRO4wNg33qNPRhjI4dnch8mdQSLGWOVWUI QMMrMEX6zksTTty9w+03EdPMjX//j3ehUkATBWq7YJnoIXG6WBFr2yKGP3oXytxIKn56 w+KC0AcKm6d431eKzt8cvBVgBDhwc5YRfiv8h7Vqf2ozA6la57DH63gAh8jJJLKTDteO WhxYm2tdeZtWygOedYf0jRY9VdJZgxK6xC0+6yHvhxbGqKdvKAhRrtgB6H5IG7Sf2DnI lSqJwzuGS/k71CBPixJqBaeDLX1yU+Sg44KtFF1Po/0a4IVDA0iu1dWrDcmCUsgZBPTR 60MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W6EfJgH7gvTRmrSe1FpFk4gWtvHbsbrIhEL5qltJ5EE=; b=NNKLsqcrhT5xj/FhxW3dRVeTbFLxSLwAos04sE4x198iwbUA3M14NWudwa5a6y+mrS LYlkhnVoZSUvEl3NNucH82lXdwZZ8xRLC369MPoRUgdYKifni6yMZeVzXYtt4BIejya8 DHDpthS91wqbcsCtm1NCWC7+6Y8q5reo/XICKKDZfqRiKiYkL5Kj4PwaIldJA9v/SiaU ajhjXlRC+MAMlDV6NMyDY1Haiu9tf/hu5y5rtMguVUGEyJZFpnqfNuAYR8Dhy85vk5+S ZHB+6eRk0mIrvMIj/yQ8u+qog4mJc6AnpTztlbCTYV4X/6fts8MDJl9F1XjWg1uqEVrU ovHA== X-Gm-Message-State: AFeK/H2EMmeyx8lYdhPONfZdq/MLwrNhHp0HDVd6A7rlMd4yxtJtuABarq/b1r9mEx0KzRI3D0J1bXqkI3du9g== X-Received: by 10.200.43.149 with SMTP id m21mr28537222qtm.102.1490705333238; Tue, 28 Mar 2017 05:48:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.161.162 with HTTP; Tue, 28 Mar 2017 05:48:52 -0700 (PDT) In-Reply-To: <48f5f485-5d34-a768-4180-c5df761de005@kit.edu> References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> <48f5f485-5d34-a768-4180-c5df761de005@kit.edu> From: Luca Muscariello Date: Tue, 28 Mar 2017 14:48:52 +0200 Message-ID: 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 Content-Type: multipart/alternative; boundary=001a113778c6da4624054bc9e194 Archived-At: X-Mailman-Approved-At: Tue, 28 Mar 2017 08:04:52 -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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 12:48:56 -0000 --001a113778c6da4624054bc9e194 Content-Type: text/plain; charset=UTF-8 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) 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 > https://www.ietf.org/mailman/listinfo/aqm > --001a113778c6da4624054bc9e194 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Work conserving is supposed to be referring to the schedul= er.
I'm not familiar with work-conservation when it refers to activ= e queue management.
I'm not sure it is actually defined.

I can understand that an AQM can produce under utiliza= tion of the link, but that is=C2=A0
different to work conservatio= n. Or is it maybe more subtle than that?
=C2=A0
Luca

On Tue, Mar 28, = 2017 at 1:48 PM, Bless, Roland (TM) <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 conse= rving"
> and "non work conserving" in this context. A "work cons= erving"
> scheduling algorithm keeps an interface transmitting as long as there<= br> > 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)<= br>
Regards,
=C2=A0Roland

_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

--001a113778c6da4624054bc9e194-- From nobody Tue Mar 28 08:04:59 2017 Return-Path: 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 2E20B129882; Tue, 28 Mar 2017 07:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, 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 PLeTdAL2y6fP; Tue, 28 Mar 2017 07:17:21 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D03E1296B5; Tue, 28 Mar 2017 07:17:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6961; q=dns/txt; s=iport; t=1490710641; x=1491920241; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YEfu8YVFN1Ldic9WJ1eNB5nWe+O5xRB5Vyl0Fi+ikFQ=; b=T5F/9XH6luWjfYxqA0hDkALZtzQ/9e+FkPOf685rHPD0qb0GqHR0CTwQ HU4/jWCcPg+U5gXx0/QENYeeH2LkUcXee1H4H0ZeLqlp8DeaWZetZKbYI 3q9Jyv3gXyd9PtTjV4ThjaO+dvoHSKC8H15BZXyA0Wve7YPRBcieYS+qF s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AACAb9pY/5JdJa1dDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJuZmGBCweNapFRiBeIBIUxgg4fAQqFeAKDIT8YAQIBAQEBAQE?= =?us-ascii?q?BayiFFQEBAQECAQEBbAsFCwIBCBEDAQIoByEGCxQJCAIEDgWJbwMNCA6ufoczD?= =?us-ascii?q?YMLAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWGToRvglGCI4VFBZAijAQ6AY4WhDi?= =?us-ascii?q?RM4pviHoBHzg+RlkVQYQfgXw9dYhggQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,236,1486425600"; d="scan'208,217";a="400274002" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Mar 2017 14:17:20 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v2SEHKf3029396 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Mar 2017 14:17:20 GMT Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 28 Mar 2017 09:17:19 -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; Tue, 28 Mar 2017 09:17:19 -0500 From: "Rong Pan (ropan)" To: Luca Muscariello , "Bless, Roland (TM)" CC: Fred Baker , Jonathan Morton , tsvwg IETF list , Bob Briscoe , "De Schepper, Koen (Koen)" , Greg White , "AQM IETF list" , Preethi Natarajan Thread-Topic: [aqm] Questioning each PIE heuristic Thread-Index: AQHSpDHJy+lx1UjTYECfkxBsGJVX96GphvqAgACcnACAAFemgIAAArAAgAAQ0AD//9WnAA== Date: Tue, 28 Mar 2017 14:17:19 +0000 Message-ID: References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> <48f5f485-5d34-a768-4180-c5df761de005@kit.edu> In-Reply-To: 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.35.73] Content-Type: multipart/alternative; boundary="_000_D4FFE7E32655Bropanciscocom_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 28 Mar 2017 08:04:52 -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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 14:17:24 -0000 --_000_D4FFE7E32655Bropanciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 > Date: Tuesday, March 28, 2017 at 8:48 AM To: "Bless, Roland (TM)" = > Cc: Fred Baker >,= Jonathan Morton >, tsv= wg 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 mana= gement. 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) > 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 https://www.ietf.org/mailman/listinfo/aqm --_000_D4FFE7E32655Bropanciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Sorry for causing the confusion in choosing the word “work-conse= rving". If we apply AQM and can not achieving 100% line rate, i.e. los= ing throughput, it is a big No No. Since we are dealing with TCP traffic, e= xcess drops can cause TCP to back off too much and under-utilize the link.

Rong

From: Luca Muscariello <luca.muscariello@gmail.com> Date: Tuesday, March 28, 2017 at 8:= 48 AM
To: "Bless, Roland (TM)" = <roland.bless@kit.edu> Cc: Fred Baker <fredbaker.ietf@gmail.com>, Jonathan Mort= on <chromatix99@gmail.com&g= t;, tsvwg IETF list <tsvwg@ietf.org>, Bob Briscoe <ietf@bobbriscoe.net= >, "De Schepper, Koen (Koen)" <koen.de_schepper@nokia.com>, Rong Pan <ropan@cisco.com>, Greg White <g.white@cablelabs.com>= , AQM IETF list <aqm@ietf.org>, P= reethi Natarajan <prenatar@cisco.c= om>
Subject: Re: [aqm] Questioning each= PIE heuristic

Work conserving is supposed to be referring to the schedul= er.
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?<= /div>
 
Luca

On Tue, Mar 28, 2017 at 1:48 PM, Bless, Roland (= TM) <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 conservin= g"
> and "non work conserving" in this context. A "work cons= erving"
> scheduling algorithm keeps an interface transmitting as long as there<= br> > 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
https://www.ietf.org/mailman/listinfo/aqm

--_000_D4FFE7E32655Bropanciscocom_-- From wolfram.lautenschlaeger@nokia-bell-labs.com Tue Mar 28 23:30:10 2017 Return-Path: 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 9DD3D129684; Tue, 28 Mar 2017 23:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 j2O_Q9rCRGLQ; Tue, 28 Mar 2017 23:30:06 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0125.outbound.protection.outlook.com [104.47.2.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 394AB127601; Tue, 28 Mar 2017 23:30:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; 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 DB6PR0701MB2949.eurprd07.prod.outlook.com (10.168.84.11) by DB6PR0701MB2117.eurprd07.prod.outlook.com (10.168.58.8) 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 DB6PR0701MB2949.eurprd07.prod.outlook.com ([10.168.84.11]) by DB6PR0701MB2949.eurprd07.prod.outlook.com ([10.168.84.11]) 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 Thread-Index: AQHSpDHCPmUgFXrIeUydGegAQAXKAKGpdjyAgABZiACAAFengIAAArAAgAAQzwCAABi2gIABDPPg Date: Wed, 29 Mar 2017 06:30:00 +0000 Message-ID: References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> <48f5f485-5d34-a768-4180-c5df761de005@kit.edu> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=nokia-bell-labs.com; x-originating-ip: [135.245.212.11] 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; H:DB6PR0701MB2949.eurprd07.prod.outlook.com; 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-OriginatorOrg: nokia-bell-labs.com 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-BeenThere: aqm@ietf.org 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 --_000_DB6PR0701MB294976A5C354DE281816E052E9350DB6PR0701MB2949_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To my understanding a proper operating AQM _is_ work-conserving. Packet dro= ps occur, if any, when a reasonable queue is present. And as long as packet= s are present in the queue, the link runs at 100%. I cannot see any (AQM) m= echanism 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=E4rz 2017 16:17 To: 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 ; Pr= eethi 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. Rong From: Luca Muscariello > Date: Tuesday, March 28, 2017 at 8:48 AM To: "Bless, Roland (TM)" = > Cc: Fred Baker >,= Jonathan Morton >, tsv= wg 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 mana= gement. 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) > 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 https://www.ietf.org/mailman/listinfo/aqm --_000_DB6PR0701MB294976A5C354DE281816E052E9350DB6PR0701MB2949_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

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

 

Wolfram

 

 

From: aqm [mailto:aqm-bounces@ietf.o= rg] On Behalf Of Rong Pan (ropan)
Sent: Dienstag, 28. M=E4rz 2017 16:17
To: Luca Muscariello <luca.muscariello@gmail.com>; Bless, Rola= nd (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>; Gre= g White <g.white@cablelabs.com>; Jonathan Morton <chromatix99@gmai= l.com>; AQM IETF list <aqm@ietf.org>; Preethi Natarajan <prenatar@cisco.c= om>
Subject: Re: [aqm] Questioning each PIE heuristic<= /p>

 

Sorry for causing the confusion in choo= sing the word “work-conserving". If we apply AQM and can not ach= ieving 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 t= o back off too much and under-utilize the link.

 

Rong

 

From: Luca Muscariello <luca.muscariello@gmail.com>
Date: Tuesday, March 28, 2017 at 8:48 AM
To: "Bless, Roland (TM)" <roland.bless@kit.edu>
Cc: Fred Baker <fredb= aker.ietf@gmail.com>, Jonathan Morton <chromatix99@gmail.com>, tsvwg IETF list <tsvwg@ietf.org>, Bob Briscoe <ietf@bobbriscoe.net>, &q= uot;De Schepper, Koen (Koen)" <koen.de_schepper@nokia.com>, Rong Pan <ropan@cisco.com>, Greg White <g.white@cablelabs.com>, AQM IETF list <aqm@ietf.org>, Pr= eethi Natarajan <prenatar@cisco.co= m>
Subject: Re: [aqm] Questioning each PIE heuristic<= /p>

 

Work conserving is supposed to be refer= ring 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 produc= e under utilization of the link, but that is 

different to work conservation. Or is i= t maybe more subtle than that?

 

Luca

 

On Tue, Mar 28, 2017 at 1:48 PM, Bless,= Roland (TM) <= 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 conservin= g"
> and "non work conserving" in this context. A "work cons= erving"
> scheduling algorithm keeps an interface transmitting as long as there<= br> > 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
htt= ps://www.ietf.org/mailman/listinfo/aqm

 

--_000_DB6PR0701MB294976A5C354DE281816E052E9350DB6PR0701MB2949_-- From nobody Wed Mar 29 12:47:28 2017 Return-Path: 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 690AE1297A5; Wed, 29 Mar 2017 12:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 I4rq95PLGI_w; Wed, 29 Mar 2017 12:47:17 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 019311297BE; Wed, 29 Mar 2017 12:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:Cc:References:To:Subject:From:Sender:Reply-To: Content-Transfer-Encoding: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=HyM0Hf9RcW7RnM1R1Pmx2bUJQfjpmoeNIMeDcZ5qLfM=; b=IsYQoWy+e8bEmnUR+/WYqchHP 1iYzaYjCqrNIVPS+mj8K25glatKoi/9v9DLa1hTC+eOjHRYnoCz6XaW1pFWPH7gTFuo+gssxH0tJG +4Qspqx7flEjc81bA/JilnoahCLU7I+8ydRX9QlLYJ46Zg1+DkIR0ngPcOK53SuTrhMQZVL2ybTYt db5BzLoMVqsCv7evLW5zzR7dIzlaqEtB5KTqqNyQDZusAy8+mORyHSM/OAWclr+lKJb8U7mqBnigu XEnbuE4+9E2FPrt5tpHvkSsan7URzTiuTpCa40SAvNzg11Cxy5QnMRDtHuoqEnwBfR312cu49Dm1j SD460BPKg==; Received: from [77.88.71.158] (port=54348 helo=[172.16.5.179]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from ) id 1ctJYn-0007Jh-Jw; Wed, 29 Mar 2017 20:47:14 +0100 From: Bob Briscoe To: "Lautenschlaeger, Wolfram (Nokia - DE/Stuttgart)" References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> <48f5f485-5d34-a768-4180-c5df761de005@kit.edu> Cc: "Rong Pan (ropan)" , tsvwg IETF list , AQM IETF list Message-ID: Date: Wed, 29 Mar 2017 20:47:11 +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: multipart/alternative; boundary="------------54382D5FEED02957C3633CD0" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 19:47:20 -0000 This is a multi-part message in MIME format. --------------54382D5FEED02957C3633CD0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Wolfram, Just to explain some context. The PIE algorithm determines a dropping probability at sample times (default 16ms), then continues to drop with that probability until the next sample. If the queue had been large then traffic ends, while the queue is draining towards zero it is still dropping at the last calculated probability. So the PIE code includes a heuristic that suppresses any drop if the queue is less than half the target. Nonetheless, the PIE algo continues to calculate what the drop probability /would/ be if a queue of more than half the target appeared again. This is so that the drop probability reflects a longer running measure of the load as well as the instantaneous queue. Bob On 29/03/17 18:58, Rong Pan (ropan) wrote: > 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)" > > > Date: Wednesday, March 29, 2017 at 2:30 AM > To: Rong Pan >, 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 > > > 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 >; 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 > > > *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 > > *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? > > Luca > > On Tue, Mar 28, 2017 at 1:48 PM, Bless, Roland (TM) > > 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 > https://www.ietf.org/mailman/listinfo/aqm > -- ________________________________________________________________ Bob Briscoehttp://bobbriscoe.net/ --------------54382D5FEED02957C3633CD0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Wolfram,

Just to explain some context. The PIE algorithm determines a dropping probability at sample times (default 16ms), then continues to drop with that probability until the next sample. If the queue had been large then traffic ends, while the queue is draining towards zero it is still dropping at the last calculated probability. So the PIE code includes a heuristic that suppresses any drop if the queue is less than half the target. Nonetheless, the PIE algo continues to calculate what the drop probability /would/ be if a queue of more than half the target appeared again.

This is so that the drop probability reflects a longer running measure of the load as well as the instantaneous queue.


Bob

On 29/03/17 18:58, Rong Pan (ropan) wrote:
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>
Date: Wednesday, March 29, 2017 at 2:30 AM
To: Rong Pan <ropan@cisco.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>
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>; 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>
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>
Date: Tuesday, March 28, 2017 at 8:48 AM
To: "Bless, Roland (TM)" <roland.bless@kit.edu>
Cc: Fred Baker <fredbaker.ietf@gmail.com>, Jonathan Morton <chromatix99@gmail.com>, tsvwg IETF list <tsvwg@ietf.org>, Bob Briscoe <ietf@bobbriscoe.net>, "De Schepper, Koen (Koen)" <koen.de_schepper@nokia.com>, Rong Pan <ropan@cisco.com>, Greg White <g.white@cablelabs.com>, AQM IETF list <aqm@ietf.org>, Preethi Natarajan <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> 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
https://www.ietf.org/mailman/listinfo/aqm

 

 

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------54382D5FEED02957C3633CD0-- From nobody Wed Mar 29 15:29:35 2017 Return-Path: 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: =?us-ascii?q?A0AbAQAO9NtY/4oNJK1dDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJuPCthgQsHjWyRUYgYiAWFMYIOHwEKhXgCg0M/GAECAQEBAQE?= =?us-ascii?q?BAWsohRUBAQEBAgEBAStBCwULAgEIEQMBAQEoByEGCxQJCAIEAQ0FiXIDDQgOs?= =?us-ascii?q?BiHJg2DHwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhk6Eb4JRgiMWhS8FkCKMBDo?= =?us-ascii?q?BiiaDcYQ4kTOKb4h6AR84PkZZFUGGGz11iCmBDQEBAQ?= 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)" To: "Lautenschlaeger, Wolfram (Nokia - DE/Stuttgart)" , 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 Thread-Index: AQHSpDHJy+lx1UjTYECfkxBsGJVX96GphvqAgACcnACAAFemgIAAArAAgAAQ0AD//9WnAIABUtMAgAB9L4A= Date: Wed, 29 Mar 2017 17:58:08 +0000 Message-ID: References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> <48f5f485-5d34-a768-4180-c5df761de005@kit.edu> In-Reply-To: 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: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 17:58:15 -0000 --_000_D5016D98265A4ropanciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We are not holding back queued packets when the link is idle. We stop dropp= ing packets when the queue is shallow in order to avoid unnecessary drops t= hat could cause TCP traffic to back off and stop sending traffic that will = cause link idle. Rong From: "Lautenschlaeger, Wolfram (Nokia - DE/Stuttgart)" > Date: Wednesday, March 29, 2017 at 2:30 AM To: Rong Pan >, Luca Muscariello >, "Bless, Rola= nd (TM)" > Cc: tsvwg IETF list >, Fred Baker >, Bob Briscoe >, "De Schepper, Koen (Nokia - B= E/Antwerp)" >, Greg White >, Jonathan Morton >, AQM IETF list >, Preethi Nataraj= an > Subject: RE: [aqm] Questioning each PIE heuristic To my understanding a proper operating AQM _is_ work-conserving. Packet dro= ps occur, if any, when a reasonable queue is present. And as long as packet= s are present in the queue, the link runs at 100%. I cannot see any (AQM) m= echanism 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=E4rz 2017 16:17 To: 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= > 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 > Date: Tuesday, March 28, 2017 at 8:48 AM To: "Bless, Roland (TM)" = > Cc: Fred Baker >,= Jonathan Morton >, tsv= wg 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 mana= gement. 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) > 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 https://www.ietf.org/mailman/listinfo/aqm --_000_D5016D98265A4ropanciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <1047AC109A1544499A1DA38A14D6A4F6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
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 dr= ops that could cause TCP traffic to back off and stop sending traffic that = will cause link idle.

Rong

From: "Lautenschlaeger, Wolfra= m (Nokia - DE/Stuttgart)" <wolfram.lautenschlaeger@nokia-bell-labs.com><= br> Date: Wednesday, March 29, 2017 at = 2:30 AM
To: Rong Pan <ropan@cisco.com>, Luca Muscariello <luca.muscariello@gmail.com>, "= ;Bless, Roland (TM)" <rolan= d.bless@kit.edu>
Cc: tsvwg IETF list <tsvwg@ietf.org>, Fred Baker <fredbaker.ietf@gmail.com>, Bob Brisco= e <ietf@bobbriscoe.net>, "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>, Greg White <g.white@cab= lelabs.com>, Jonathan Morton <chromatix99@gmail.com>, AQM IETF list <aqm@ietf.org>, Pr= eethi Natarajan <prenatar@cisco.co= m>
Subject: RE: [aqm] Questioning each= PIE heuristic

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

 

Wolfram

 

 

From: aqm [mai= lto:aqm-bounces@ietf.org] On Behalf Of Rong Pan (ropan)
Sent: Dienstag, 28. M=E4rz 2017 16:17
To: Luca Muscariello <luca.muscariello@gmail.com>; Bless, Roland (TM) <roland.bless@kit.edu>
Cc: tsvwg IETF list <tsvwg@ietf= .org>; Fred Baker <fr= edbaker.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 M= orton <chromatix99@gmail.com>; AQM IETF list <aqm@ietf.org>; Pr= eethi Natarajan <prenatar@cisco.co= m>
Subject: Re: [aqm] Questioning each PIE heuristic<= /p>

 

Sorry for causing the confusion in choosing = the word “work-conserving". If we apply AQM and can not achievin= g 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>
Date: Tuesday, March 28, 2017 at 8:48 AM
To: "Bless, Roland (TM)" <roland.bless@kit.edu>
Cc: Fred Baker <fredb= aker.ietf@gmail.com>, Jonathan Morton <chromatix99@gmail.com>, tsvwg IETF list <tsvwg@ietf.org>, Bob Briscoe <ietf@bobbriscoe.net>, &q= uot;De Schepper, Koen (Koen)" <koen.de_schepper@nokia.com>, Rong Pan <ropan@cisco.com>, Greg White <g.white@cablelabs.com>, AQM IETF list <aqm@ietf.org>, Pr= eethi Natarajan <prenatar@cisco.co= m>
Subject: Re: [aqm] Questioning each PIE heuristic<= /p>

 

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 und= er utilization of the link, but that is 

different to work conservation. Or is it may= be more subtle than that?

 

Luca

 

On Tue, Mar 28, 2017 at 1:48 PM, Bless, Rola= nd (TM) <rolan= d.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 conservin= g"
> and "non work conserving" in this context. A "work cons= erving"
> scheduling algorithm keeps an interface transmitting as long as there<= br> > 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
htt= ps://www.ietf.org/mailman/listinfo/aqm

 

 --_000_D5016D98265A4ropanciscocom_-- From nobody Thu Mar 30 00:46:52 2017 Return-Path: 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 5AB2D129542; Thu, 30 Mar 2017 00:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 WWmNVnq3VXoh; Thu, 30 Mar 2017 00:46:48 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (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; d=bobbriscoe.net; 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 [77.88.71.158] (port=62123 helo=[172.16.5.179]) by server.dnsblock1.com 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: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> Cc: Greg White , "FredBaker.IETF@gmail.com" , AQM IETF list , tsvwg IETF list From: Bob Briscoe Message-ID: <99a7b737-fc3c-efd0-b6c8-d71a089b7de8@bobbriscoe.net> 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: <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> 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 - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 07:46:50 -0000 Jonathan, 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). Bob 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 http://bobbriscoe.net/ From nobody Thu Mar 30 02:08:38 2017 Return-Path: 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 E9D6D128B4E; Thu, 30 Mar 2017 02:08:36 -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 gA5qd5fQIvyR; Thu, 30 Mar 2017 02:08:35 -0700 (PDT) Received: from mail-lf0-x241.google.com (mail-lf0-x241.google.com [IPv6:2a00:1450:4010:c07::241]) (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 349C51241FC; Thu, 30 Mar 2017 02:08:35 -0700 (PDT) Received: by mail-lf0-x241.google.com with SMTP id n78so3968467lfi.3; Thu, 30 Mar 2017 02:08:35 -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=jDkU2XksMyT27XP4ClXrfKmLPIDeMyE1aa9rZCXiBgk=; b=erFIRMenn3q044tt3Gxk3zGZOqiQCjPcyh/VBchL//oRO5HBMMjF3ZDDaNt4LJkO1/ JIoHcgnNvJxFdRY4h/Z8zXhKyH22vWB1X0vXPE6Sy/ZaHndUGeho31H5DrIzGP1mAgCo 7Z+7zgjVIlWoPDv709Iz8pCvBLctnpV6R4jCtePPYEE0ES1HlWSK03YvxnnUURb/3FSS auWbM2YL9mYrrLUUPyL1ryvU6YmPbFkJMYST/WyRcejwEvWEhzqCC8ny1KPp6v/MiQgV 2WDChiolkGmytg4B5uBPfiuQvqUyXZ7nadu5imGD3wnard08g8QfFez92XI9I2u2gC27 qkbg== 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=jDkU2XksMyT27XP4ClXrfKmLPIDeMyE1aa9rZCXiBgk=; b=BjLQQquSuR1UivCHwQrnNjalJyKQy5Qe+8xEx10p+S4Sh74JDEctdDJf478bZSDom6 WNoclJnvu/dNJfLGFgdBgJmhWmXUWKE9EqafWU/0NrKOXNZ34Z0ZwQyifpqCvM+cwtJq PT+/3Sv80ELiKk9OPIqJpoT6KVYEHsgfjeOBTCqldTe/2SjMHDCtq9QxQVUyzPeRuF/S LwxcMBE7Zr3mOLSTyLYyRnraUf4PWvzlHIHzqIsG78fa6NdgwM2bfGGS5HHu1uWkjQ8Y GbmzlbG5nQCtsPdekskKDDL07pZA/NpyTuJTD7qzapqolT4hFAmCDoBIxFPMt/TJclRe gjvg== X-Gm-Message-State: AFeK/H2GVOo/VqsDToeX2NB/EDu+wF0L0cTMRMM2PkDvsDT2dBW5olnWI64PCKH2bzrDsA== X-Received: by 10.25.204.9 with SMTP id c9mr1266515lfg.107.1490864913502; Thu, 30 Mar 2017 02:08:33 -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 t30sm250424ljd.39.2017.03.30.02.08.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 30 Mar 2017 02:08:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jonathan Morton In-Reply-To: <99a7b737-fc3c-efd0-b6c8-d71a089b7de8@bobbriscoe.net> Date: Thu, 30 Mar 2017 12:08:29 +0300 Cc: "Rong Pan (ropan)" , Greg White , "FredBaker.IETF@gmail.com" , AQM IETF list , tsvwg IETF list Content-Transfer-Encoding: quoted-printable Message-Id: References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> <99a7b737-fc3c-efd0-b6c8-d71a089b7de8@bobbriscoe.net> To: Bob Briscoe X-Mailer: Apple Mail (2.3124) Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 09:08:37 -0000 > On 30 Mar, 2017, at 10:46, Bob Briscoe wrote: >=20 > 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. That=E2=80=99s fair enough. It sounds like the fairly coarsely discrete time intervals in PIE are = the main justification for this particular heuristic, so it might be = sufficient to document that WRT PIE itself. Using finer time intervals = is clearly a better choice for the future. - Jonathan Morton From nobody Thu Mar 30 02:57:50 2017 Return-Path: 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 F1DFC12946B; Thu, 30 Mar 2017 02:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no 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 0km1WCzFG4Qb; Thu, 30 Mar 2017 02:57:40 -0700 (PDT) Received: from mx04.uni-tuebingen.de (mx04.uni-tuebingen.de [134.2.5.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 674EC129426; Thu, 30 Mar 2017 02:57:40 -0700 (PDT) Received: from [134.2.11.131] (chaos.informatik.uni-tuebingen.de [134.2.11.131]) by mx04.uni-tuebingen.de (Postfix) with ESMTPSA id 3CA1A12FA2; Thu, 30 Mar 2017 11:57:38 +0200 (CEST) To: Jonathan Morton , Bob Briscoe References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> <99a7b737-fc3c-efd0-b6c8-d71a089b7de8@bobbriscoe.net> Cc: "Rong Pan (ropan)" , tsvwg IETF list , AQM IETF list From: Michael Menth Message-ID: <471e91b1-c469-3d36-9af1-0411e5661286@uni-tuebingen.de> Date: Thu, 30 Mar 2017 11:57:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [aqm] Questioning each PIE heuristic - moving averages and rate measurement X-BeenThere: aqm@ietf.org 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 09:57:43 -0000 Hi all, Am 30.03.2017 um 11:08 schrieb Jonathan Morton: > >> On 30 Mar, 2017, at 10:46, Bob Briscoe wrote: >> >> 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. > > That’s fair enough. > > It sounds like the fairly coarsely discrete time intervals in PIE are the main justification for this particular heuristic, so it might be sufficient to document that WRT PIE itself. Using finer time intervals is clearly a better choice for the future. PIE uses time intervals for measurement purposes and several parameters contribute. We've recently done some basic work on measurement methodology that facilitates a comparison of different measurement approaches and better-informed parametrization by introduction of the "memory" concept. https://atlas.informatik.uni-tuebingen.de/~menth/papers/Menth17c.pdf PIE essentially implements TDRM-DTWMA-UEMA illustrated in Fig. 6d. The concept of "memory" can also be applied to moving averages which are also used in PIE for several purposes. Configuration via a "memory" can make some heuristics more intuitive. Best wishes, Michael > > - Jonathan Morton > -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://kn.inf.uni-tuebingen.de From nobody Thu Mar 30 05:06:54 2017 Return-Path: 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 69C671294E4; Thu, 30 Mar 2017 05:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 3LDKozEs43Nl; Thu, 30 Mar 2017 05:06:51 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63DA2129489; Thu, 30 Mar 2017 05:06:51 -0700 (PDT) Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0319.002; Thu, 30 Mar 2017 08:06:50 -0400 From: Dave Dolson To: Bob Briscoe , Jonathan Morton , "Rong Pan (ropan)" CC: Greg White , tsvwg IETF list , "AQM IETF list" , "FredBaker.IETF@gmail.com" Thread-Topic: [aqm] Questioning each PIE heuristic Thread-Index: AQHSpDHALX//dtLVFUCWt7nl7FFE5KGpuUqAgABZiACAAztmAIAAA2ew Date: Thu, 30 Mar 2017 12:06:48 +0000 Message-ID: References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> <99a7b737-fc3c-efd0-b6c8-d71a089b7de8@bobbriscoe.net> In-Reply-To: <99a7b737-fc3c-efd0-b6c8-d71a089b7de8@bobbriscoe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.196.10] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 12:06:53 -0000 V2hpbGUgcmV2aWV3aW5nIFBJRSwgaXQgbWlnaHQgYmUgd29ydGggcmV2aXNpdGluZyBteSBjb21t ZW50IGhlcmU6IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvYXFtL2lma0Jl NnV2TUU1TnFtLUo2dWxaV2xvb0J4bw0KVGhlIHNlY29uZCBwYXJ0IHdhcyBuZXZlciBhbnN3ZXJl ZCB0byBteSBzYXRpc2ZhY3Rpb24uDQoNCkkgYmVsaWV2ZWQgSSBoYWQgZm91bmQgYSBidWc6ICBJ IHNhaWQsICJJIHRoaW5rIHRoZXJlIGFyZSBhIHZhcmlldHkgb2YgdHJhZmZpYyBwYXR0ZXJucyB0 aGF0IGNhbiBhbGxvdyAncCcgdG8gbWVhbmRlciBhcm91bmQgaW4gbm9uLXplcm8gc3BhY2UgZXZl biB0aG91Z2ggdGhlIHF1ZXVlIGlzIG5lYXJseSBlbXB0eSINCg0KTWF5YmUgeW91J3ZlIGFkZHJl c3NlZCB0aGlzLCBiZWNhdXNlIEkgdGhpbmsgaXQgd2FzIGR1ZSB0byBhIGhldXJpc3RpYy4NCg0K SSdtIG11Y2ggaW4gZmF2b3Igb2YgcmVtb3ZpbmcgdGhlIGhldXJpc3RpY3Mgb24gY29udHJvbCBz eXN0ZW1zOyB0aGFua3MuDQoNCi1EYXZlDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogYXFtIFttYWlsdG86YXFtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBC b2IgQnJpc2NvZQ0KU2VudDogVGh1cnNkYXksIE1hcmNoIDMwLCAyMDE3IDI6NDcgQU0NClRvOiBK b25hdGhhbiBNb3J0b247IFJvbmcgUGFuIChyb3BhbikNCkNjOiBHcmVnIFdoaXRlOyB0c3Z3ZyBJ RVRGIGxpc3Q7IEFRTSBJRVRGIGxpc3Q7IEZyZWRCYWtlci5JRVRGQGdtYWlsLmNvbQ0KU3ViamVj dDogUmU6IFthcW1dIFF1ZXN0aW9uaW5nIGVhY2ggUElFIGhldXJpc3RpYw0KDQpKb25hdGhhbiwN Cg0KUGlja2luZyB1cCBvbiBhbiBlYXJsaWVyIHBvaW50IHlvdSBtYWRlIGFib3V0IGF2b2lkaW5n IGhldXJpc3RpY3MgYnkgZW5zdXJpbmcgdGhlIHVuZGVybHlpbmcgYWxnbyBpcyBzb3VuZCwuLi4g dGhhdCdzIHByZWNpc2VseSB3aHkgSSdtIGdvaW5nIHRocm91Z2ggYWxsIHRoZSAoOSkgUElFIGhl dXJpc3RpY3MuLi4NCg0KRm9yIFBJMiB3ZSByZW1vdmVkIGFsbCBidXQgMiBhbmQgaXQgd29ya2Vk IHRoZSBzYW1lIG9yIGJldHRlciB0aGFuIFBJRSBpbiBhbGwgb3VyIHRlc3RzLiBJIGhhdmUgYmVl biBhc3Nlc3NpbmcgZWFjaCBvZiB0aGUgb3RoZXIgNyBvbmUgYnkgb25lIGZvciByZWluc3RhdGVt ZW50LiBTbyBmYXIgSSd2ZSByZWplY3RlZCA2LiBJIHRoaW5rIEkgY2FuIHJlamVjdCB0aGlzIGxh c3Qgb25lIGJ5IG1ha2luZyB0aGUgc2FtcGxpbmcgdGltZSBvZiB0aGUgYmFzZSBQSSBhbGdvIGRl cGVuZGVudCBvbiB0aGUgbWF4IGxpbmsgcmF0ZS4gVGhlbiB3aGVuIHRoZSBxdWV1ZSBnb2VzIGlk bGUsIHRoZSBiYXNlIFBJIGFsZ28gd2lsbCBkZWNheSBkcm9wIGRvd24gdG8gemVybyBubyBzbG93 ZXIgdGhhbiB0aGUgcXVldWUgZHJhaW5zLCB3aXRob3V0IG5lZWRpbmcgdGhpcyBleHRyYSBoZXVy aXN0aWMuIEJ1dCBJIG5lZWQgdG8gY2hlY2sgdGhhdCdzIHJlYWxpc3RpYy4NCg0KV2Ugd2lsbCBi ZSB3cml0aW5nIGFsbCB0aGlzIHVwIChwcm9iYWJseSBpbiBhbiB1cGRhdGUgdG8gdGhlIFBJMiBw YXBlciAtIEkgZG9uJ3QgdGhpbmsgdGhlIElFVEYgUEkyIHNwZWMgaXMgdGhlIHJpZ2h0IHBsYWNl IGZvciBhIGNyaXRpcXVlIG9mIGhldXJpc3RpY3MgdGhhdCBpdCBkb2Vzbid0IHVzZSkuDQoNCk91 ciBhaW0gaXMgYSBjb21wbGV0ZWx5IHNvdW5kIEFRTSBpbiBhIGZldyBsaW5lcyBvZiBjb2RlIGFu ZCBhIGZldyBvcGVyYXRpb25zIHNvIGl0IGNhbiBiZSBpbXBsZW1lbnRlZCBldmVyeXdoZXJlIHdp dGggbWluaW1hbCByZXNpc3RhbmNlIGZyb20gZGV2ZWxvcGVycyBkdWUgdG8gcGVyZm9ybWFuY2Ug Y29uY2VybnMgKGUuZy4gY2hlYXAgZXRoZXJuZXQgc3dpdGNoZXMsIGNoZWFwIGhvbWUgZ2F0ZXdh eXMsIGNhcnJpZXItZ3JhZGUgZXF1aXBtZW50IGZvciB0aG91c2FuZHMgb2YgdXNlcnMsIGV0Yyku DQoNCg0KQm9iDQoNCk9uIDI4LzAzLzE3IDA3OjI1LCBKb25hdGhhbiBNb3J0b24gd3JvdGU6DQo+ DQo+IEJ5IGFsbCBtZWFucywgYXZvaWQgZHJvcHBpbmcgcGFja2V0cyB3aGVuIHRoZSBxdWV1ZSBp cyBhY3R1YWxseSBlbXB0eSAtIHRoYXQgaXMsIHdoZW4geW914oCZcmUgZGVsaXZlcmluZyB0aGUg bGFzdCBwYWNrZXQgaW4gdGhlIHF1ZXVlLiAgSW4gdGhhdCBjYXNlLCB0aGVyZSBpcyBubyBjb25n ZXN0aW9uIHRvIHNpZ25hbCBmb3IuICBCdXQgdGhlcmUgcmVhbGx5IGlzIG5vIG5lZWQgdG8gaGF2 ZSBhbnkgY29tcGxleCBzdGF0ZS1zd2l0Y2hpbmcgbG9naWMgZm9yIHRoYXQuICBJZiB5b3VyIHVu ZGVybHlpbmcgYWxnb3JpdGhtIGlzIHNvdW5kLCBpdCB3aWxsIG5hdHVyYWxseSBkZWNheSB0byB6 ZXJvIHBhY2tldCBkcm9wcyBpZiB0aGUgZW1wdHktcXVldWUgY29uZGl0aW9uIHBlcnNpc3RzLg0K Pg0KPiAgIC0gSm9uYXRoYW4gTW9ydG9uDQo+DQoNCg0KLS0NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkJvYiBCcmlzY29l ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9ib2JicmlzY29lLm5ldC8NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmFxbSBtYWls aW5nIGxpc3QNCmFxbUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9hcW0NCg==