From nobody Fri Apr 1 03:32:26 2016 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 0D45A12D52F for ; Fri, 1 Apr 2016 03:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 2yViGN3cdd2M for ; Fri, 1 Apr 2016 03:32:22 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 99AE212D0B4 for ; Fri, 1 Apr 2016 03:32:20 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 5915FF24DDA26; Fri, 1 Apr 2016 10:32:16 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u31AWIiU013528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Apr 2016 10:32:18 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u31AWF7H028533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Apr 2016 12:32:16 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.230]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 1 Apr 2016 12:32:15 +0200 From: "De Schepper, Koen (Nokia - BE)" To: EXT Wesley Eddy , "aqm@ietf.org" Thread-Topic: PI2 presentation in iccrg Thread-Index: AQHRjAHCBP/akILeskuVrHEvvbKUMw== Date: Fri, 1 Apr 2016 10:32:15 +0000 Message-ID: References: <56BB8F05.2030006@mti-systems.com> <56D0CBFA.5030106@mti-systems.com> In-Reply-To: <56D0CBFA.5030106@mti-systems.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [aqm] PI2 presentation in iccrg 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, 01 Apr 2016 10:32:25 -0000 Hi all, Just to inform you that I will do a presentation on PI2 in the iccrg sessio= n on Monday. The focus will be on support for scalable TCPs and throughput fairness betw= een classic (CUBIC) and scalable (DCTCP) congestion controls, but the basic= s of the PI2 AQM will be explained as well. It is build on PIE (actually a = simplification) which supports also scalable TCPs and needs less (internal)= parameters. As mentioned before this could be standardized as extensions o= n the PIE draft, or a new PI2 draft could be made for this. To be discussed= afterwards. Regards, Koen. > -----Original Message----- > From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of EXT Wesley Eddy > Sent: vrijdag 26 februari 2016 23:05 > To: De Schepper, Koen (Nokia - BE); aqm@ietf.org > Subject: Re: [aqm] AQM plans >=20 > Hi, I'm now sorry that we didn't schedule an AQM meeting slot in Buenos > Aires. We can certainly pre-load an agenda for Berlin with these topics > though. That is a long way in the future, however, so please use the > mailing list to discuss tests and metrics, share results, advertise > papers, etc, in the meantime on these topics! >=20 >=20 >=20 > On 2/26/2016 6:23 AM, De Schepper, Koen (Nokia - BE) wrote: > > Hi Wes, > > > > Just to let you know that we are still working on AQMs that support > scalable (L4S) TCPs. > > We could present some of our latest results (if there will be a > meeting in Buenos Aires, otherwise in Berlin?) > > > > * Performance of HTTP Adaptive Video Streaming (HAS) with different > TCP's and AQMs > > o HAS is currently ~30% of Internet traffic, but no AQM testing so > far has included it > > o the results are very poor with a particular popular AQM > > Presenter: Inton Tsang > > Duration: 10mins > > Draft: Comparative testing of draft-ietf-aqm-pie-01, draft-ietf-aqm- > fq-codel-04, draft-briscoe-aqm-dualq-coupled > > > > For experiment write-up, see Section 3 of > https://riteproject.files.wordpress.com/2015/12/rite-deliverable-3-3- > public1.pdf > > > > * PI^2: PI simplified with a square > > o PIE embeds some auto-tuning and heuristics, which can be removed > by simple transformation of a variable > > o Allows PIE to control also scalable congestion controls (DCTCP, > ...) > > Presenter: Koen De Schepper > > Duration: 15mins > > Draft: (probably impacted) draft-ietf-aqm-pie > > > > * DualQ update > > o extensive additional tests, including different RTTs and mixed > RTTs, better visualization > > o using other AQMs than Curvy-RED for 'Classic' traffic, e.g. PI^2 > > Presenter: Koen De Schepper > > Duration: 20min > > Draft: draft-briscoe-aqm-dualq-coupled-01 > > > > Regards, > > Koen. > > > > > >> -----Original Message----- > >> From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Wesley Eddy > >> Sent: woensdag 10 februari 2016 20:27 > >> To: aqm@ietf.org > >> Subject: [aqm] AQM plans > >> > >> Hello AQMers, this is just a quick note to be clear on working group > >> status and forward planning. > >> > >> Currently, all of the active drafts are either in WGLC, or in the > >> process of shepherd writeups to go the the AD. > >> > >> Once we get the current set of drafts out for publication, there are > a > >> few things the WG can do: > >> - close down > >> - remain open to continue coordinating and advance algorithms (e.g. > >> within the standards track) > >> - remain open as a venue for potential new work (e.g. the DualQ > Coupled > >> AQM) > >> > >> I think we should discuss this and plan to make a decision after the > >> IETF 96 meeting in Berlin (July 17-22). We can have a "closing or > >> re-chartering" meeting in Berlin if it will benefit from face-to-face > >> discussion. > >> > >> > >> _______________________________________________ > >> aqm mailing list > >> aqm@ietf.org > >> https://www.ietf.org/mailman/listinfo/aqm > > >=20 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm From nobody Fri Apr 1 07:16:16 2016 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 B089D12D5AA; Fri, 1 Apr 2016 07:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 6RFvP2xkuImn; Fri, 1 Apr 2016 07:16:10 -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 140B712D0F7; Fri, 1 Apr 2016 07:16:10 -0700 (PDT) Received: from 182.178.189.80.dyn.plus.net ([80.189.178.182]:52460 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1alzrr-0006Gl-7O; Fri, 01 Apr 2016 15:16:07 +0100 To: Aaron Falk References: <56C71869.9080503@bobbriscoe.net> <20160219182359.GA74531@verdi> <56CACCB1.2080502@bobbriscoe.net> From: Bob Briscoe Message-ID: <56FE82A5.1090304@bobbriscoe.net> Date: Fri, 1 Apr 2016 15:16:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050708010900050605010608" 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: Cc: tcpm IETF list , tsvwg IETF list , "De Schepper, Koen \(Koen\)" , TCP Prague List , "tsv-ads@ietf.org" , AQM IETF list Subject: Re: [aqm] [tcpm] [tcpPrague] [tsvwg] (Bar) BoF @IETF-95 'Ultra-Low Queuing Delay for All' (L4S, DualQ Coupled AQM, TCP Prague)? 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, 01 Apr 2016 14:16:12 -0000 This is a multi-part message in MIME format. --------------050708010900050605010608 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Aaron, Thanks for reminding me. I completely lost track of doing this back in Feb (typically a symptom of my machine crashing, 'cos my own memory got corrupted years ago). I have requested a room from the secretariat for a 1hr session on Thursday 8 Apr 2016, preferably 9-10am, otherwise 16:20-17:20pm. I'll confirm on these lists as soon as I know. If we get 1st choice, apologies to those who were hoping to enjoy the new relaxed 10am start to IETF meetings The 2nd choice was picked in an attempt to avoid any relevant WG sessions, but it does clash with the fun-packed IAOC Meeting Venue Selection Criteria & Procedures BoF. Cheers Bob On 30/03/16 21:13, Aaron Falk wrote: > Did this get scheduled? > > --aaron > > On Mon, Feb 22, 2016 at 12:21 PM, Spencer Dawkins at IETF > > > wrote: > > Just to try to be helpful ... > > On Mon, Feb 22, 2016 at 2:54 AM, Bob Briscoe > wrote: > > John, > > On 19/02/16 18:23, John Leslie wrote: > > Bob Briscoe > wrote: > > I'm cross-posting 'cos this impacts 3 IETF WGs and > interested implementers. > > We would like to propose a Bar BoF at the Buenos Aires > IETF, about L4S, > DualQ and solutions to the TCP Prague Requirements. > > This feels like it belongs as a non-WG-forming formal BoF. > > It describes work spanning at least three WGs; and > could benefit from > formal scheduling to avoid conflicts with those WGs and > others. > > OTOH, it really isn't to the point where a WG charter > can reasonably > be drafted. First we must decide whether the work _can_ be > split among > existing WGs. > > However this may turn out, I wish to participate remotely. > > OK, we'll see if the secretariat can help us with that. > > > I believe that happens at http://www.ietf.org/meeting/amreq.html. > If you put "TSV" in as "type of meeting", your happy TSV ADs would > see the request. > > Thanks, > > Spencer > > Unfortunately we ran out of time for the formal BoF deadline > on Friday. > > > Bob > > > -- > John Leslie > > > _______________________________________________ > tcpPrague mailing list > tcpPrague@ietf.org > https://www.ietf.org/mailman/listinfo/tcpprague > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------050708010900050605010608 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Aaron,

Thanks for reminding me.
I completely lost track of doing this back in Feb (typically a symptom of my machine crashing, 'cos my own memory got corrupted years ago).

I have requested a room from the secretariat for a 1hr session on Thursday 8 Apr 2016, preferably 9-10am, otherwise 16:20-17:20pm.
I'll confirm on these lists as soon as I know.

If we get 1st choice, apologies to those who were hoping to enjoy the new relaxed 10am start to IETF meetings
The 2nd choice was picked in an attempt to avoid any relevant WG sessions, but it does clash with the fun-packed IAOC Meeting Venue Selection Criteria & Procedures BoF.

Cheers



Bob

On 30/03/16 21:13, Aaron Falk wrote:
Did this get scheduled?

--aaron

On Mon, Feb 22, 2016 at 12:21 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
Just to try to be helpful ...

On Mon, Feb 22, 2016 at 2:54 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
John,

On 19/02/16 18:23, John Leslie wrote:
Bob Briscoe <ietf@bobbriscoe.net> wrote:
I'm cross-posting 'cos this impacts 3 IETF WGs and interested implementers.

We would like to propose a Bar BoF at the Buenos Aires IETF, about L4S,
DualQ and solutions to the TCP Prague Requirements.
    This feels like it belongs as a non-WG-forming formal BoF.

    It describes work spanning at least three WGs; and could benefit from
formal scheduling to avoid conflicts with those WGs and others.

    OTOH, it really isn't to the point where a WG charter can reasonably
be drafted. First we must decide whether the work _can_ be split among
existing WGs.

    However this may turn out, I wish to participate remotely.
 OK, we'll see if the secretariat can help us with that.
I believe that happens at http://www.ietf.org/meeting/amreq.html. If you put "TSV" in as "type of meeting", your happy TSV ADs would see the request.

Thanks,

Spencer
 
Unfortunately we ran out of time for the formal BoF deadline on Friday.


Bob


--
John Leslie <john@jlc.net>

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

--
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/



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




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


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------050708010900050605010608-- From nobody Sun Apr 3 07:05:20 2016 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 EEFF112D0F5; Sun, 3 Apr 2016 07:05:11 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.18.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160403140511.28266.40543.idtracker@ietfa.amsl.com> Date: Sun, 03 Apr 2016 07:05:11 -0700 Archived-At: Cc: draft-ietf-aqm-fq-codel@ietf.org, wes@mti-systems.com, aqm-chairs@ietf.org, mls.ietf@gmail.com, The IESG , aqm@ietf.org, rfc-editor@rfc-editor.org Subject: [aqm] Document Action: 'The FlowQueue-CoDel Packet Scheduler and Active Queue Management Algorithm' to Experimental RFC (draft-ietf-aqm-fq-codel-06.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: Sun, 03 Apr 2016 14:05:12 -0000 The IESG has approved the following document: - 'The FlowQueue-CoDel Packet Scheduler and Active Queue Management Algorithm' (draft-ietf-aqm-fq-codel-06.txt) as Experimental RFC This document is the product of the Active Queue Management and Packet Scheduling Working Group. The IESG contact persons are Spencer Dawkins and Martin Stiemerling. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-aqm-fq-codel/ Technical Summary This memo presents the FQ-CoDel hybrid packet scheduler/AQM algorithm, a powerful tool for fighting bufferbloat and reducing latency. FQ-CoDel mixes packets from multiple flows and reduces the impact of head of line blocking from bursty traffic. It provides isolation for low-rate traffic such as DNS, web, and videoconferencing traffic. It improves utilisation across the networking fabric, especially for bidirectional traffic, by keeping queue lengths short; and it can be implemented in a memory- and CPU-efficient fashion across a wide range of hardware. Working Group Summary An interesting aspect of this document is the combined use of CoDel with FQ for improving flow-isolation properties. The working group had early discussions about the differences between FQ and scheduling mechanisms versus more pure AQM algorithms (like CoDel). This resulted in draft- ietf-aqm-fq-implementation, which describes the terminology and construction of hybrid systems. Any early disagreement in the WG about this seems to have subsided after the subsequent discussions and work to resolve terminology and scope. Document Quality Yes, there are existing implementations and deployments, including in the Linux kernel. There have been other implementation efforts in addition to the editors, and questions have been shared on the AQM mailing list, with clarifications posted in draft updates. The Linux implementation is from the editors of the document, and an independent implementation in FreeBSD was done by Rasool As-Saadi at the Swinburne University. Personnel Wes Eddy (wes@mti-systems.com) is the Document Shepherd. Martin Stiemerling is the responsible AD. From nobody Mon Apr 4 12:12:55 2016 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 2AAAF12D7EA; Mon, 4 Apr 2016 12:12:51 -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.18.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160404191251.15662.87542.idtracker@ietfa.amsl.com> Date: Mon, 04 Apr 2016 12:12:51 -0700 Archived-At: Cc: aqm@ietf.org Subject: [aqm] I-D Action: draft-ietf-aqm-pie-06.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, 04 Apr 2016 19:12:51 -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 : PIE: A Lightweight Control Scheme To Address the Bufferbloat Problem Authors : Rong Pan Preethi Natarajan Fred Baker Filename : draft-ietf-aqm-pie-06.txt Pages : 26 Date : 2016-04-04 Abstract: Bufferbloat is a phenomenon where excess buffers in the network cause high latency and jitter. As more and more interactive applications (e.g. voice over IP, real time video streaming and financial transactions) run in the Internet, high latency and jitter degrade application performance. There is a pressing need to design intelligent queue management schemes that can control latency and jitter; and hence provide desirable quality of service to users. This document presents a lightweight active queue management design, called PIE (Proportional Integral controller Enhanced), that can effectively control the average queueing latency to a target value. Simulation results, theoretical analysis and Linux testbed results have shown that PIE can ensure low latency and achieve high link utilization under various congestion situations. The design does not require per-packet timestamp, so it incurs very small overhead and is simple enough to implement in both hardware and software. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-aqm-pie/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-aqm-pie-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-aqm-pie-06 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 Apr 4 12:13:50 2016 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 957C612D7EA for ; Mon, 4 Apr 2016 12:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 Wzh2McJPJf4K for ; Mon, 4 Apr 2016 12:13:45 -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 23EC012D80E for ; Mon, 4 Apr 2016 12:13:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9373; q=dns/txt; s=iport; t=1459797221; x=1461006821; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1DQc5edcLdN6Fv5onHbt1jkXswUBeN2YuQLEGvpXvFE=; b=NK2YZxTCPdVqo1o+bLaAzKenfoekfy3UUNF1wX3B7NmvLUdg3HJYDVuY dCgSqwZVVd6ajpHdi7zOVM6g/k2ZEEUIPE9aY2JmPNubJwLnEMd3bZU0Z AkJ12XFV08X/Rdp/nVFIQjVOiBSH9lqCZpokN3MI00qe8lfosxi56twQv s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQCWvAJX/49dJa1dDoMpU30GuyEBD?= =?us-ascii?q?YFyFwqCPIMwAoE6OBQBAQEBAQEBZSeEQQEBAQQBAQEkRwsMBAIBCBEEAQEoByc?= =?us-ascii?q?LFAkIAgQBDQUbBIgHAQ6+OwEBAQEBAQEBAQEBAQEBAQEBAQEBARWGIIRKhAU4h?= =?us-ascii?q?VgFjgWJfAGFcogVgWhOg3+IWo8ZAR4BAUKCARyBDztshnI2AX0BAQE?= X-IronPort-AV: E=Sophos;i="5.24,441,1454976000"; d="scan'208";a="90095435" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Apr 2016 19:13:36 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u34JDaaq002360 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Apr 2016 19:13:36 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.1104.5; Mon, 4 Apr 2016 14:13:35 -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.1104.009; Mon, 4 Apr 2016 14:13:35 -0500 From: "Rong Pan (ropan)" To: Rasool Al-Saadi , "aqm@ietf.org" Thread-Topic: [aqm] I-D Action: draft-ietf-aqm-pie-05.txt Thread-Index: AQHRc/cxYP/vIxkARkm//dWjIlRZzJ9lP4CAgBUDLoA= Date: Mon, 4 Apr 2016 19:13:35 +0000 Message-ID: References: <20160301201602.24979.59154.idtracker@ietfa.amsl.com> <6545444AE21C2749939E637E56594CEA3C1D01A0@gsp-ex02.ds.swin.edu.au> In-Reply-To: <6545444AE21C2749939E637E56594CEA3C1D01A0@gsp-ex02.ds.swin.edu.au> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [171.71.130.190] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Grenville Armitage Subject: Re: [aqm] I-D Action: draft-ietf-aqm-pie-05.txt 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: Mon, 04 Apr 2016 19:13:47 -0000 Rasool, Thanks for your detailed review. Please see the comments below and a new draft has been posted. Regards, Rong On 3/21/16, 8:20 PM, "aqm on behalf of Rasool Al-Saadi" wrote: >Dear all, > >Thank you for revising PIE Internet Draft as it has become much clearer >than previous versions. However, I have some comments regarding then new >draft: > >1) In page 12, section 5.2 (Departure Rate Estimation), > >> current_qdelay =3D queue_.byte_length() * >> PIE->avg_dq_time_/DQ_THRESHOLD; >> > >This code assumes that DQ_THRESHOLD of bytes are de-queued during >avg_dq_time , but this is not very accurate as we can de-queue >DQ_THRESHOLD + MSS during the measurement cycle (the condition is >PIE->dq_count_ > DQ_THRESHOLD). Are you trying to simplify the code or a >very accurate current_qdelay calculation is not required? >>>>>>>>>>>>>>>>RP: it is for simplification purpose and accurate latency >>>>>>>>>>>>>>>>calculation is not required. It is probability-based >>>>>>>>>>>>>>>>scheme, there are a lot of randomness built-in. >=20 > >2) In the same section mentioned above, > >> * Upon a packet deque: >> >> if PIE->in_measurement_ =3D=3D FALSE and queue.byte_length() > >> DQ_THRESHOLD: >> PIE->in_measurement_ =3D TRUE; >> PIE->measurement_start_ =3D now; >> PIE->dq_count_ =3D 0; >> >> if PIE->in_measurement_ =3D=3D TRUE: >> PIE->dq_count_ =3D PIE->dq_count_ + deque_pkt_size; >> if PIE->dq_count_ > DQ_THRESHOLD then >> weight =3D DQ_THRESHOLD/2^16 >> PIE->avg_dq_time_ =3D (now-PIE->measurement_start_)*weight >> + PIE->avg_dq_time_*(1-weight); >> PIE->dq_count_=3D0; >> PIE->measurement_start_ =3D now > >This code works correctly first time when in_measurement_=3D=3D FALSE then= , >it will stay in measurement state even when there are no DQ_THRESHOLD >worth of bytes in the queue. So, PIE->avg_dq_time_ will be wrong as it >includes the time of filling the queue with DQ_THRESHOLD worth of bytes >plus the time of de-queuing it. The simple solution for that is just by >changing the last two lines of the code: > >> PIE->dq_count_=3D0; >> PIE->measurement_start_ =3D now > >By=20 > PIE->in_measurement_ =3D FALSE; > >BTW, the code in the end of the daft is correct. >>>>>>>>>>>>>>>>>>RP: Pseudo code is correct, here is not the complete >>>>>>>>>>>>>>>>>>code, merely to explain the key part of the algorithm. I >>>>>>>>>>>>>>>>>>now add the else clause in to be clear. > > >3) In page 16, section 6 (Implementation Cost), the paragraph that >describes combing SFQ with PIE is not clear and confusing. > >"SFQ can also be combined with PIE to further improve latency for various >flows with different priorities. If the timestamp is used to obtain >queueing latency, PIE can be adopted directly to each individual queue. >If the latency is obtained via the deque rate calculation, we recommend >one PIE instance using the overall queue length divided by the overall >deque rate. Then the overall PIE->drop_prob_ is modified using each >individual queue divided by the maximum individual queue length: PIE- >>drop_prob_(i)=3Dqueue_.byte_length(i)/max(queue_.byte_length(i)). " > >I am not sure if I interpreted the paragraph correctly or not. It seems >that there are two cases when using PIE with SFQ scheduler : >1- When timestamp is used to calculate queue delay, each queue has a >separate drop probability calculation background process i.e. each queue >uses normal PIE instance. > >2- When deque rate calculation is used to calculate queue delay, here I >am completely confused about what does the text means and hope you >clearly it: =20 > >"we recommend one PIE instance using the overall queue length divided by >the overall deque rate. Then the overall PIE->drop_prob_ is modified >using each individual queue divided by the maximum individual queue >length: PIE- >>drop_prob_(i)=3Dqueue_.byte_length(i)/max(queue_.byte_length(i))." >=09 >For new drop_prob calculation, how can drop_prob_ be just a division of >queue lengths? > drop_prob_(i)=3Dqueue_.byte_length(i)/max(queue_.byte_length(i)) >>>>>>>>>>>>>>>>>>>>>>>>>RP: Let=B9s say there are two flows that are queue= d into two sfq queues. One flow is an elephant flow and one flow is mice flow. Tot= al latency is caused by the elephant flow. The above equation makes sure that = the mice flow (whose queue length is zero, or very small amount) won=B9t be dro= pped. Besides, since it is mice flow, it would be hard to measure its departure r= ate as the queue would never build up.qdelay > > >4) In page 20, the code of enque function: > >>//called on each packet arrival >> enque(Packet packet) { >> if (PIE->drop_prob_ =3D=3D 0 && current_qdelay < QDELAY_REF >> && PIE->qdelay_old_ < QDELAY_REF) { >> PIE->burst_allowance_ =3D MAX_BURST; >> } > >According to the description and the code in section 4.4 (Burst >Tolerance), the condition should be > if (PIE->drop_prob_ =3D=3D 0 && current_qdelay < QDELAY_REF/2 > && PIE->qdelay_old_ < QDELAY_REF/2) { >>>>>>>>>>>>>>>>>>>>>>>>>>Fixed... > >5) In pages 23 and 24, > >> //If the queue has been idle for a while, turn off PIE >> //reset counters when accessing the queue after some idle >> //period if PIE was active before >> if ( PIE->drop_prob_ =3D=3D 0 && PIE->qdelay_old_ =3D=3D 0 >> && queue_.byte_length() =3D=3D 0) { >> PIE->active_ =3D INACTIVE; > >According to section 5.3 (Turning PIE on and off), the condition of >deactivating PIE should be: > >if (PIE->drop_prob_ =3D=3D 0 and current_qdelay < QDELAY_REF/2 and > PIE->qdelay_old_ < QDELAY_REF/2) { >>>>>>>>>>>>>>>>>>>>>>>>>>RP: Fixed. > > >6) In page 26, >=20 >> if ( PIE->dq_count_ >=3D DQ_THRESHOLD) { >And >> if (queue_.byte_length() >=3D DQ_THRESHOLD && > >Just to make the conditions consistence with section 5.2 (Departure Rate >Estimation), use '>' instead of '>=3D' or change the condition in the cod= e >of section 5.2 to use '>=3D' instead of '>'. > >>>>>>>>>>>>>>>>>>>>>>>>>>RP: Fixed, changed in Section 5.2 > >Regards, >Rasool Al-Saadi > >> -----Original Message----- >> From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of internet- >> drafts@ietf.org >> Sent: Wednesday, 2 March 2016 7:16 AM >> To: i-d-announce@ietf.org >> Cc: aqm@ietf.org >> Subject: [aqm] I-D Action: draft-ietf-aqm-pie-05.txt >>=20 >>=20 >> 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. >>=20 >> Title : PIE: A Lightweight Control Scheme To Address >>the Bufferbloat >> Problem >> Authors : Rong Pan >> Preethi Natarajan >> Fred Baker >> Filename : draft-ietf-aqm-pie-05.txt >> Pages : 26 >> Date : 2016-03-01 >>=20 >> Abstract: >> Bufferbloat is a phenomenon where excess buffers in the network cause >> high latency and jitter. As more and more interactive applications >> (e.g. voice over IP, real time video streaming and financial >> transactions) run in the Internet, high latency and jitter degrade >> application performance. There is a pressing need to design >> intelligent queue management schemes that can control latency and >> jitter; and hence provide desirable quality of service to users. >>=20 >> This document presents a lightweight active queue management design, >> called PIE (Proportional Integral controller Enhanced), that can >> effectively control the average queueing latency to a target value. >> Simulation results, theoretical analysis and Linux testbed results >> have shown that PIE can ensure low latency and achieve high link >> utilization under various congestion situations. The design does not >> require per-packet timestamp, so it incurs very small overhead and is >> simple enough to implement in both hardware and software. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-aqm-pie/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-aqm-pie-05 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-aqm-pie-05 >>=20 >>=20 >> 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. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> 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 From nobody Tue Apr 5 04:38:46 2016 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 F2E2C12D8C1; Tue, 5 Apr 2016 04:38:41 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.18.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160405113841.745.54812.idtracker@ietfa.amsl.com> Date: Tue, 05 Apr 2016 04:38:41 -0700 Archived-At: Cc: Wesley Eddy , aqm-chairs@ietf.org, draft-ietf-aqm-docsis-pie@ietf.org, mls.ietf@gmail.com, The IESG , aqm@ietf.org, rfc-editor@rfc-editor.org Subject: [aqm] Document Action: 'A PIE-Based AQM for DOCSIS Cable Modems' to Informational RFC (draft-ietf-aqm-docsis-pie-02.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: Tue, 05 Apr 2016 11:38:42 -0000 The IESG has approved the following document: - 'A PIE-Based AQM for DOCSIS Cable Modems' (draft-ietf-aqm-docsis-pie-02.txt) as Informational RFC This document is the product of the Active Queue Management and Packet Scheduling Working Group. The IESG contact persons are Spencer Dawkins and Martin Stiemerling. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-aqm-docsis-pie/ Technical Summary Cable modems based on the DOCSIS(R) specification provide broadband Internet access to over one hundred million users worldwide. In some cases, the cable modem connection is the bottleneck (lowest speed) link between the customer and the Internet. As a result, the impact of buffering and bufferbloat in the cable modem can have a significant effect on user experience. The CableLabs DOCSIS 3.1 specification introduces requirements for cable modems to support an Active Queue Management (AQM) algorithm that is intended to alleviate the impact that buffering has on latency sensitive traffic, while preserving bulk throughput performance. In addition, the CableLabs DOCSIS 3.0 specifications have also been amended to contain similar requirements. This document describes the requirements on Active Queue Management that apply to DOCSIS equipment, including a description of the "DOCSIS-PIE" algorithm that is required on DOCSIS 3.1 cable modems. Working Group Summary There were no extraordinary events in the WG process on this document. Document Quality The document quality is high. Implementations would likely be done from the DOCSIS spec itself rather than this document, which is really just tying together the IETF AQM work with what has been completed earlier in the DOCSIS specifications. Personnel Wesley Eddy (wes@mti-systems.com) is the shepherd and Martin Stiemerling (mls.ietf@gmail.com) is the AD. From nobody Tue Apr 5 05:03:06 2016 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 03F4412D532; Tue, 5 Apr 2016 05:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 BRAsEX6mIOd8; Tue, 5 Apr 2016 05:02:58 -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 B5DC512D1E1; Tue, 5 Apr 2016 05:02:53 -0700 (PDT) Received: from dhcp-b315.meeting.ietf.org ([31.133.179.21]:48593) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1anPh2-0006vZ-Rc; Tue, 05 Apr 2016 13:02:50 +0100 To: Aaron Falk , Spencer Dawkins at IETF , Mirja Kuehlewind References: <56C71869.9080503@bobbriscoe.net> <20160219182359.GA74531@verdi> <56CACCB1.2080502@bobbriscoe.net> From: Bob Briscoe Message-ID: <5703A963.6090306@bobbriscoe.net> Date: Tue, 5 Apr 2016 13:02:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------060501040200060605040004" 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: Cc: tcpm IETF list , tsvwg IETF list , "tsv-ads@ietf.org" , TCP Prague List , "De Schepper, Koen \(Koen\)" , AQM IETF list Subject: Re: [aqm] [tcpm] [tcpPrague] [tsvwg] (Bar) BoF @IETF-95 'Ultra-Low Queuing Delay for All' (L4S, DualQ Coupled AQM, TCP Prague)? 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, 05 Apr 2016 12:03:02 -0000 This is a multi-part message in MIME format. --------------060501040200060605040004 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Folks, We have a time and room for this Bar BoF: Date/time: 09:00 - 10:00 ART (= 12-13:00 UTC) Thu 7 Apr 2016 Room: Quebracho B We have the regular IETF remote attendance facilities in that room. The room is not being used for the following session, so we don't have to vacate early. We're building the agenda - will send shortly. We want to allow most time for people to talk from the floor. The general structure will be: * Introduction/Background * Clarification Questions * Recent Activity: Design / Evaluation / Industry * Build a standardisation roadmap * Build a BoF for the Berlin timeframe, and should it be non-WG forming. * Discussion / Q&A Sorry for delay setting this up. My fault. I've bcc'd a few people who have been asking about this specifically. Bob On 30/03/16 21:13, Aaron Falk wrote: > Did this get scheduled? > > --aaron > > On Mon, Feb 22, 2016 at 12:21 PM, Spencer Dawkins at IETF > > > wrote: > > Just to try to be helpful ... > > On Mon, Feb 22, 2016 at 2:54 AM, Bob Briscoe > wrote: > > John, > > On 19/02/16 18:23, John Leslie wrote: > > Bob Briscoe > wrote: > > I'm cross-posting 'cos this impacts 3 IETF WGs and > interested implementers. > > We would like to propose a Bar BoF at the Buenos Aires > IETF, about L4S, > DualQ and solutions to the TCP Prague Requirements. > > This feels like it belongs as a non-WG-forming formal BoF. > > It describes work spanning at least three WGs; and > could benefit from > formal scheduling to avoid conflicts with those WGs and > others. > > OTOH, it really isn't to the point where a WG charter > can reasonably > be drafted. First we must decide whether the work _can_ be > split among > existing WGs. > > However this may turn out, I wish to participate remotely. > > OK, we'll see if the secretariat can help us with that. > > > I believe that happens at http://www.ietf.org/meeting/amreq.html. > If you put "TSV" in as "type of meeting", your happy TSV ADs would > see the request. > > Thanks, > > Spencer > > Unfortunately we ran out of time for the formal BoF deadline > on Friday. > > > Bob > > > -- > John Leslie > > > _______________________________________________ > tcpPrague mailing list > tcpPrague@ietf.org > https://www.ietf.org/mailman/listinfo/tcpprague > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------060501040200060605040004 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Folks,

We have a time and room for this Bar BoF:
Date/time: 09:00 - 10:00 ART (= 12-13:00 UTC) Thu 7 Apr 2016
Room: Quebracho B

We have the regular IETF remote attendance facilities in that room.
The room is not being used for the following session, so we don't have to vacate early.

We're building the agenda - will send shortly.
We want to allow most time for people to talk from the floor.

The general structure will be:
* Introduction/Background
* Clarification Questions
* Recent Activity: Design / Evaluation / Industry
* Build a standardisation roadmap
* Build a BoF for the Berlin timeframe, and should it be non-WG forming.
* Discussion / Q&A

Sorry for delay setting this up. My fault.
I've bcc'd a few people who have been asking about this specifically.


Bob

On 30/03/16 21:13, Aaron Falk wrote:
Did this get scheduled?

--aaron

On Mon, Feb 22, 2016 at 12:21 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
Just to try to be helpful ...

On Mon, Feb 22, 2016 at 2:54 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
John,

On 19/02/16 18:23, John Leslie wrote:
Bob Briscoe <ietf@bobbriscoe.net> wrote:
I'm cross-posting 'cos this impacts 3 IETF WGs and interested implementers.

We would like to propose a Bar BoF at the Buenos Aires IETF, about L4S,
DualQ and solutions to the TCP Prague Requirements.
    This feels like it belongs as a non-WG-forming formal BoF.

    It describes work spanning at least three WGs; and could benefit from
formal scheduling to avoid conflicts with those WGs and others.

    OTOH, it really isn't to the point where a WG charter can reasonably
be drafted. First we must decide whether the work _can_ be split among
existing WGs.

    However this may turn out, I wish to participate remotely.
 OK, we'll see if the secretariat can help us with that.
I believe that happens at http://www.ietf.org/meeting/amreq.html. If you put "TSV" in as "type of meeting", your happy TSV ADs would see the request.

Thanks,

Spencer
 
Unfortunately we ran out of time for the formal BoF deadline on Friday.


Bob


--
John Leslie <john@jlc.net>

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

--
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/



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




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


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------060501040200060605040004-- From nobody Wed Apr 6 12:35:34 2016 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 E0E8A12D128 for ; Wed, 6 Apr 2016 12:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable 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 lW7qjTw_i-Bq for ; Wed, 6 Apr 2016 12:35:29 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 89E1512D5EC for ; Wed, 6 Apr 2016 12:35:28 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 499A1822696EA; Wed, 6 Apr 2016 19:35:23 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u36JZQRL014346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Apr 2016 19:35:26 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u36JZPqf029206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Apr 2016 21:35:25 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.230]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 6 Apr 2016 21:35:25 +0200 From: "De Schepper, Koen (Nokia - BE)" To: "aqm@ietf.org" , "iccrg@irtf.org" Thread-Topic: PI2 presentation in iccrg Thread-Index: AQHRjAHCBP/akILeskuVrHEvvbKUM599PWGg Date: Wed, 6 Apr 2016 19:35:25 +0000 Message-ID: References: <56BB8F05.2030006@mti-systems.com> <56D0CBFA.5030106@mti-systems.com> In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [aqm] PI2 presentation in iccrg 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: Wed, 06 Apr 2016 19:35:32 -0000 As there was no time for questions, I wanted to share a question/remark on = the list that I got from multiple people: "Won't the think twice with 2 random numbers at the end step be difficult t= o implement in existing hardware?" This is true, but most likely the PIE algorithm is implemented in an off-li= ne SW process and in that case the squared probability can be simply implem= ented by multiplication to itself, before applying it to the hardware. The 2 random numbers are a very efficient way to implement in new hardware,= because you can use half the resolution for a classic probability comparis= on. For example when a probability up to p =3D [0.000001 .. 1] needs to be = supported, the p' range needs to be only [0.001 .. 1]. You do need 2 random= numbers, but only half their size, so the same amount of random bits. If there are other questions, let me know or post on the lists. Koen. The link to the slides: https://www.ietf.org/proceedings/95/slides/slides-9= 5-iccrg-3.pdf > -----Original Message----- > From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of EXT De Schepper, > Koen (Nokia - BE) > Sent: vrijdag 1 april 2016 12:32 > To: EXT Wesley Eddy; aqm@ietf.org > Subject: [aqm] PI2 presentation in iccrg >=20 > Hi all, >=20 > Just to inform you that I will do a presentation on PI2 in the iccrg > session on Monday. >=20 > The focus will be on support for scalable TCPs and throughput fairness > between classic (CUBIC) and scalable (DCTCP) congestion controls, but > the basics of the PI2 AQM will be explained as well. It is build on PIE > (actually a simplification) which supports also scalable TCPs and needs > less (internal) parameters. As mentioned before this could be > standardized as extensions on the PIE draft, or a new PI2 draft could be > made for this. To be discussed afterwards. >=20 > Regards, > Koen. >=20 >=20 >=20 > > -----Original Message----- > > From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of EXT Wesley Eddy > > Sent: vrijdag 26 februari 2016 23:05 > > To: De Schepper, Koen (Nokia - BE); aqm@ietf.org > > Subject: Re: [aqm] AQM plans > > > > Hi, I'm now sorry that we didn't schedule an AQM meeting slot in > Buenos > > Aires. We can certainly pre-load an agenda for Berlin with these > topics > > though. That is a long way in the future, however, so please use the > > mailing list to discuss tests and metrics, share results, advertise > > papers, etc, in the meantime on these topics! > > > > > > > > On 2/26/2016 6:23 AM, De Schepper, Koen (Nokia - BE) wrote: > > > Hi Wes, > > > > > > Just to let you know that we are still working on AQMs that support > > scalable (L4S) TCPs. > > > We could present some of our latest results (if there will be a > > meeting in Buenos Aires, otherwise in Berlin?) > > > > > > * Performance of HTTP Adaptive Video Streaming (HAS) with different > > TCP's and AQMs > > > o HAS is currently ~30% of Internet traffic, but no AQM testing > so > > far has included it > > > o the results are very poor with a particular popular AQM > > > Presenter: Inton Tsang > > > Duration: 10mins > > > Draft: Comparative testing of draft-ietf-aqm-pie-01, draft-ietf-aqm- > > fq-codel-04, draft-briscoe-aqm-dualq-coupled > > > > > > For experiment write-up, see Section 3 of > > https://riteproject.files.wordpress.com/2015/12/rite-deliverable-3-3- > > public1.pdf > > > > > > * PI^2: PI simplified with a square > > > o PIE embeds some auto-tuning and heuristics, which can be > removed > > by simple transformation of a variable > > > o Allows PIE to control also scalable congestion controls > (DCTCP, > > ...) > > > Presenter: Koen De Schepper > > > Duration: 15mins > > > Draft: (probably impacted) draft-ietf-aqm-pie > > > > > > * DualQ update > > > o extensive additional tests, including different RTTs and mixed > > RTTs, better visualization > > > o using other AQMs than Curvy-RED for 'Classic' traffic, e.g. > PI^2 > > > Presenter: Koen De Schepper > > > Duration: 20min > > > Draft: draft-briscoe-aqm-dualq-coupled-01 > > > > > > Regards, > > > Koen. > > > > > > > > >> -----Original Message----- > > >> From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Wesley Eddy > > >> Sent: woensdag 10 februari 2016 20:27 > > >> To: aqm@ietf.org > > >> Subject: [aqm] AQM plans > > >> > > >> Hello AQMers, this is just a quick note to be clear on working > group > > >> status and forward planning. > > >> > > >> Currently, all of the active drafts are either in WGLC, or in the > > >> process of shepherd writeups to go the the AD. > > >> > > >> Once we get the current set of drafts out for publication, there > are > > a > > >> few things the WG can do: > > >> - close down > > >> - remain open to continue coordinating and advance algorithms (e.g. > > >> within the standards track) > > >> - remain open as a venue for potential new work (e.g. the DualQ > > Coupled > > >> AQM) > > >> > > >> I think we should discuss this and plan to make a decision after > the > > >> IETF 96 meeting in Berlin (July 17-22). We can have a "closing or > > >> re-chartering" meeting in Berlin if it will benefit from face-to- > face > > >> discussion. > > >> > > >> > > >> _______________________________________________ > > >> 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 >=20 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm From nobody Wed Apr 6 16:44:24 2016 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 3F8A212D6BA; Wed, 6 Apr 2016 16:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 462U04aHfEdD; Wed, 6 Apr 2016 16:44:19 -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 4EA5512D612; Wed, 6 Apr 2016 16:44:18 -0700 (PDT) Received: from dhcp-b315.meeting.ietf.org ([31.133.179.21]:51398) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1anx7M-0006Ql-FL; Thu, 07 Apr 2016 00:44:14 +0100 References: <56C71869.9080503@bobbriscoe.net> <20160219182359.GA74531@verdi> <56CACCB1.2080502@bobbriscoe.net> <5703A963.6090306@bobbriscoe.net> From: Bob Briscoe To: tcpm IETF list , tsvwg IETF list , TCP Prague List , AQM IETF list Message-ID: <57059F43.1050406@bobbriscoe.net> Date: Thu, 7 Apr 2016 00:44:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <5703A963.6090306@bobbriscoe.net> Content-Type: multipart/alternative; boundary="------------010603060201010808070705" 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: Cc: "tsv-ads@ietf.org" , "De Schepper, Koen \(Koen\)" Subject: Re: [aqm] [tcpm] [tcpPrague] [tsvwg] (Bar) BoF @IETF-95 'Ultra-Low Queuing Delay for All' (L4S, DualQ Coupled AQM, TCP Prague)? 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: Wed, 06 Apr 2016 23:44:22 -0000 This is a multi-part message in MIME format. --------------010603060201010808070705 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Folks, Reminder, agenda & supporting materials below for the Bar BoF on L4S / DualQ Coupled AQM / TCP Prague *Event details** *Date/time: 09:00 - 10:00 local time (ART = 12-13:00 UTC) Thu 7 Apr 2016 Room: Quebracho B *Supporting materials / background:** *https://riteproject.eu/dctth/ To use the time effectively, it will be assumed that people have a working knowledge of what the technology is, and a rough idea of how it works. For those wanting an introduction, a useful 2-pager in the IETF Journal is linked from the above, plus videos of the demos etc.b Or chat with us afterwards *Proposed Agenda:** ***09:00 * Note Well, Agenda Bashing [Bob] * Introduction/Background (very brief) [Bob] * Clarification Questions 09:15 * Status updates [Koen to lead], e.g.: - what people are doing on parts of the problem: - planned work - evaluation work - interest in implementing - willingness to review 09:40 * Build a standardisation roadmap [Bob to lead] * Build a BoF for the Berlin time-frame - should it be non-WG forming? - volunteers to help with organisation / writing problem statement, etc. - which mailing list? - what name? * Discussion / Q&A 09:55 end Most time will be allowed for people to talk from the floor. Cheers Bob & Koen On 05/04/16 13:02, Bob Briscoe wrote: > Folks, > > We have a time and room for this Bar BoF: > Date/time: 09:00 - 10:00 ART (= 12-13:00 UTC) Thu 7 Apr 2016 > Room: Quebracho B > > We have the regular IETF remote attendance facilities in that room. > The room is not being used for the following session, so we don't have > to vacate early. > > Sorry for delay setting this up. My fault. > I've bcc'd a few people who have been asking about this specifically. > > > Bob > > On 30/03/16 21:13, Aaron Falk wrote: >> Did this get scheduled? >> >> --aaron >> >> On Mon, Feb 22, 2016 at 12:21 PM, Spencer Dawkins at IETF >> wrote: >> >> Just to try to be helpful ... >> >> On Mon, Feb 22, 2016 at 2:54 AM, Bob Briscoe >> wrote: >> >> John, >> >> On 19/02/16 18:23, John Leslie wrote: >> >> Bob Briscoe > > wrote: >> >> I'm cross-posting 'cos this impacts 3 IETF WGs and >> interested implementers. >> >> We would like to propose a Bar BoF at the Buenos >> Aires IETF, about L4S, >> DualQ and solutions to the TCP Prague Requirements. >> >> This feels like it belongs as a non-WG-forming formal >> BoF. >> >> It describes work spanning at least three WGs; and >> could benefit from >> formal scheduling to avoid conflicts with those WGs and >> others. >> >> OTOH, it really isn't to the point where a WG charter >> can reasonably >> be drafted. First we must decide whether the work _can_ >> be split among >> existing WGs. >> >> However this may turn out, I wish to participate >> remotely. >> >> OK, we'll see if the secretariat can help us with that. >> >> >> I believe that happens at http://www.ietf.org/meeting/amreq.html. >> If you put "TSV" in as "type of meeting", your happy TSV ADs >> would see the request. >> >> Thanks, >> >> Spencer >> >> Unfortunately we ran out of time for the formal BoF deadline >> on Friday. >> >> >> Bob >> >> >> -- >> John Leslie > >> >> _______________________________________________ >> tcpPrague mailing list >> tcpPrague@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpprague >> >> >> -- >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ >> >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> >> >> >> >> _______________________________________________ >> aqm mailing list >> aqm@ietf.org >> https://www.ietf.org/mailman/listinfo/aqm > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ --------------010603060201010808070705 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Folks,

Reminder, agenda & supporting materials below for the Bar BoF on L4S / DualQ Coupled AQM / TCP Prague

Event details
Date/time: 09:00 - 10:00 local time (ART = 12-13:00 UTC) Thu 7 Apr 2016
Room: Quebracho B

Supporting materials / background:
https://riteproject.eu/dctth/
To use the time effectively, it will be assumed that people have a working knowledge of what the technology is, and a rough idea of how it works.
For those wanting an introduction, a useful 2-pager in the IETF Journal is linked from the above, plus videos of the demos etc.b
Or chat with us afterwards

Proposed Agenda:
 09:00
* Note Well, Agenda Bashing [Bob]
* Introduction/Background (very brief) [Bob]
* Clarification Questions
09:15
* Status updates [Koen to lead], e.g.:
  - what people are doing on parts of the problem:
  - planned work
  - evaluation work
  - interest in implementing
  - willingness to review
09:40
* Build a standardisation roadmap [Bob to lead]
* Build a BoF for the Berlin time-frame
   - should it be non-WG forming?
   - volunteers to help with organisation / writing problem statement, etc.
   - which mailing list?
   - what name?
* Discussion / Q&A
09:55 end

Most time will be allowed for people to talk from the floor.

Cheers


Bob & Koen

On 05/04/16 13:02, Bob Briscoe wrote:
Folks,

We have a time and room for this Bar BoF:
Date/time: 09:00 - 10:00 ART (= 12-13:00 UTC) Thu 7 Apr 2016
Room: Quebracho B

We have the regular IETF remote attendance facilities in that room.
The room is not being used for the following session, so we don't have to vacate early.

Sorry for delay setting this up. My fault.
I've bcc'd a few people who have been asking about this specifically.


Bob

On 30/03/16 21:13, Aaron Falk wrote:
Did this get scheduled?

--aaron

On Mon, Feb 22, 2016 at 12:21 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
Just to try to be helpful ...

On Mon, Feb 22, 2016 at 2:54 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
John,

On 19/02/16 18:23, John Leslie wrote:
Bob Briscoe <ietf@bobbriscoe.net> wrote:
I'm cross-posting 'cos this impacts 3 IETF WGs and interested implementers.

We would like to propose a Bar BoF at the Buenos Aires IETF, about L4S,
DualQ and solutions to the TCP Prague Requirements.
    This feels like it belongs as a non-WG-forming formal BoF.

    It describes work spanning at least three WGs; and could benefit from
formal scheduling to avoid conflicts with those WGs and others.

    OTOH, it really isn't to the point where a WG charter can reasonably
be drafted. First we must decide whether the work _can_ be split among
existing WGs.

    However this may turn out, I wish to participate remotely.
 OK, we'll see if the secretariat can help us with that.
I believe that happens at http://www.ietf.org/meeting/amreq.html. If you put "TSV" in as "type of meeting", your happy TSV ADs would see the request.

Thanks,

Spencer
 
Unfortunately we ran out of time for the formal BoF deadline on Friday.


Bob


--
John Leslie <john@jlc.net>

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

--
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/



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




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


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------010603060201010808070705-- From nobody Thu Apr 7 03:45:02 2016 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 C682312D105; Thu, 7 Apr 2016 03:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 oCQBy0mWCunQ; Thu, 7 Apr 2016 03:44:57 -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 33B1B12D09C; Thu, 7 Apr 2016 03:44:57 -0700 (PDT) Received: from [201.250.51.33] (port=25661 helo=[192.168.1.54]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1ao7Qk-0002IU-Ci; Thu, 07 Apr 2016 11:44:55 +0100 To: tcpm IETF list , tsvwg IETF list , TCP Prague List , AQM IETF list References: <56C71869.9080503@bobbriscoe.net> <20160219182359.GA74531@verdi> <56CACCB1.2080502@bobbriscoe.net> <5703A963.6090306@bobbriscoe.net> <57059F43.1050406@bobbriscoe.net> From: Bob Briscoe Message-ID: <57063A22.2010709@bobbriscoe.net> Date: Thu, 7 Apr 2016 11:44:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <57059F43.1050406@bobbriscoe.net> Content-Type: multipart/alternative; boundary="------------040709030009070906000508" 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: Cc: "tsv-ads@ietf.org" , "De Schepper, Koen \(Koen\)" Subject: Re: [aqm] [tcpm] [tcpPrague] [tsvwg] (Bar) BoF @IETF-95 'Ultra-Low Queuing Delay for All' (L4S, DualQ Coupled AQM, TCP Prague)? 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: Thu, 07 Apr 2016 10:45:01 -0000 This is a multi-part message in MIME format. --------------040709030009070906000508 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Folks, Some slides to frame the discussion at 9am this morning are uploaded to: https://riteproject.eu/dctth/#ietf-bar-bof Nonetheless, we want most of the time to be for discussion. Phil Eardley has agreed to chair the meeting. He has suggested: *Aim of meeting:** ** To determine whether there is interest in working on this. * To work out how to get the IETF to work on these pieces (ie the meeting is not primarily a technical discussion) Aaron Falk has kindly agreed to take notes. We will need a volunteer for jabber scribe, as we have remote attendees. Cheers Bob On 07/04/16 00:44, Bob Briscoe wrote: > Folks, > > Reminder, agenda & supporting materials below for the Bar BoF on L4S / > DualQ Coupled AQM / TCP Prague > > *Event details** > *Date/time: 09:00 - 10:00 local time (ART = 12-13:00 UTC) Thu 7 Apr 2016 > Room: Quebracho B > > *Supporting materials / background:** > *https://riteproject.eu/dctth/ > To use the time effectively, it will be assumed that people have a > working knowledge of what the technology is, and a rough idea of how > it works. > For those wanting an introduction, a useful 2-pager in the IETF > Journal is linked from the above, plus videos of the demos etc.b > Or chat with us afterwards > > *Proposed Agenda:** > ***09:00 > * Note Well, Agenda Bashing [Bob] > * Introduction/Background (very brief) [Bob] > * Clarification Questions > 09:15 > * Status updates [Koen to lead], e.g.: > - what people are doing on parts of the problem: > - planned work > - evaluation work > - interest in implementing > - willingness to review > 09:40 > * Build a standardisation roadmap [Bob to lead] > * Build a BoF for the Berlin time-frame > - should it be non-WG forming? > - volunteers to help with organisation / writing problem statement, > etc. > - which mailing list? > - what name? > * Discussion / Q&A > 09:55 end > > Most time will be allowed for people to talk from the floor. > > Cheers > > > Bob & Koen > > On 05/04/16 13:02, Bob Briscoe wrote: >> Folks, >> >> We have a time and room for this Bar BoF: >> Date/time: 09:00 - 10:00 ART (= 12-13:00 UTC) Thu 7 Apr 2016 >> Room: Quebracho B >> >> We have the regular IETF remote attendance facilities in that room. >> The room is not being used for the following session, so we don't >> have to vacate early. >> >> Sorry for delay setting this up. My fault. >> I've bcc'd a few people who have been asking about this specifically. >> >> >> Bob >> >> On 30/03/16 21:13, Aaron Falk wrote: >>> Did this get scheduled? >>> >>> --aaron >>> >>> On Mon, Feb 22, 2016 at 12:21 PM, Spencer Dawkins at IETF >>> wrote: >>> >>> Just to try to be helpful ... >>> >>> On Mon, Feb 22, 2016 at 2:54 AM, Bob Briscoe >>> wrote: >>> >>> John, >>> >>> On 19/02/16 18:23, John Leslie wrote: >>> >>> Bob Briscoe >> > wrote: >>> >>> I'm cross-posting 'cos this impacts 3 IETF WGs and >>> interested implementers. >>> >>> We would like to propose a Bar BoF at the Buenos >>> Aires IETF, about L4S, >>> DualQ and solutions to the TCP Prague Requirements. >>> >>> This feels like it belongs as a non-WG-forming >>> formal BoF. >>> >>> It describes work spanning at least three WGs; and >>> could benefit from >>> formal scheduling to avoid conflicts with those WGs and >>> others. >>> >>> OTOH, it really isn't to the point where a WG >>> charter can reasonably >>> be drafted. First we must decide whether the work _can_ >>> be split among >>> existing WGs. >>> >>> However this may turn out, I wish to participate >>> remotely. >>> >>> OK, we'll see if the secretariat can help us with that. >>> >>> >>> I believe that happens at >>> http://www.ietf.org/meeting/amreq.html. If you put "TSV" in as >>> "type of meeting", your happy TSV ADs would see the request. >>> >>> Thanks, >>> >>> Spencer >>> >>> Unfortunately we ran out of time for the formal BoF deadline >>> on Friday. >>> >>> >>> Bob >>> >>> >>> -- >>> John Leslie >>> >>> _______________________________________________ >>> tcpPrague mailing list >>> tcpPrague@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpprague >>> >>> >>> -- >>> ________________________________________________________________ >>> Bob Briscoe http://bobbriscoe.net/ >>> >>> >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>> >>> >>> >>> >>> _______________________________________________ >>> aqm mailing list >>> aqm@ietf.org >>> https://www.ietf.org/mailman/listinfo/aqm >> >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ >> >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ --------------040709030009070906000508 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Folks,

Some slides to frame the discussion at 9am this morning are uploaded to:
https://riteproject.eu/dctth/#ietf-bar-bof
Nonetheless, we want most of the time to be for discussion.

Phil Eardley has agreed to chair the meeting. He has suggested:
Aim of meeting:
* To determine whether there is interest in working on this.
* To work out how to get the IETF to work on these pieces (ie the meeting is not primarily a technical discussion)

Aaron Falk has kindly agreed to take notes.
We will need a volunteer for jabber scribe, as we have remote attendees.

Cheers


Bob


On 07/04/16 00:44, Bob Briscoe wrote:
Folks,

Reminder, agenda & supporting materials below for the Bar BoF on L4S / DualQ Coupled AQM / TCP Prague

Event details
Date/time: 09:00 - 10:00 local time (ART = 12-13:00 UTC) Thu 7 Apr 2016
Room: Quebracho B

Supporting materials / background:
https://riteproject.eu/dctth/
To use the time effectively, it will be assumed that people have a working knowledge of what the technology is, and a rough idea of how it works.
For those wanting an introduction, a useful 2-pager in the IETF Journal is linked from the above, plus videos of the demos etc.b
Or chat with us afterwards

Proposed Agenda:
 09:00
* Note Well, Agenda Bashing [Bob]
* Introduction/Background (very brief) [Bob]
* Clarification Questions
09:15
* Status updates [Koen to lead], e.g.:
  - what people are doing on parts of the problem:
  - planned work
  - evaluation work
  - interest in implementing
  - willingness to review
09:40
* Build a standardisation roadmap [Bob to lead]
* Build a BoF for the Berlin time-frame
   - should it be non-WG forming?
   - volunteers to help with organisation / writing problem statement, etc.
   - which mailing list?
   - what name?
* Discussion / Q&A
09:55 end

Most time will be allowed for people to talk from the floor.

Cheers


Bob & Koen

On 05/04/16 13:02, Bob Briscoe wrote:
Folks,

We have a time and room for this Bar BoF:
Date/time: 09:00 - 10:00 ART (= 12-13:00 UTC) Thu 7 Apr 2016
Room: Quebracho B

We have the regular IETF remote attendance facilities in that room.
The room is not being used for the following session, so we don't have to vacate early.

Sorry for delay setting this up. My fault.
I've bcc'd a few people who have been asking about this specifically.


Bob

On 30/03/16 21:13, Aaron Falk wrote:
Did this get scheduled?

--aaron

On Mon, Feb 22, 2016 at 12:21 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
Just to try to be helpful ...

On Mon, Feb 22, 2016 at 2:54 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
John,

On 19/02/16 18:23, John Leslie wrote:
Bob Briscoe <ietf@bobbriscoe.net> wrote:
I'm cross-posting 'cos this impacts 3 IETF WGs and interested implementers.

We would like to propose a Bar BoF at the Buenos Aires IETF, about L4S,
DualQ and solutions to the TCP Prague Requirements.
    This feels like it belongs as a non-WG-forming formal BoF.

    It describes work spanning at least three WGs; and could benefit from
formal scheduling to avoid conflicts with those WGs and others.

    OTOH, it really isn't to the point where a WG charter can reasonably
be drafted. First we must decide whether the work _can_ be split among
existing WGs.

    However this may turn out, I wish to participate remotely.
 OK, we'll see if the secretariat can help us with that.
I believe that happens at http://www.ietf.org/meeting/amreq.html. If you put "TSV" in as "type of meeting", your happy TSV ADs would see the request.

Thanks,

Spencer
 
Unfortunately we ran out of time for the formal BoF deadline on Friday.


Bob


--
John Leslie <john@jlc.net>

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

--
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/



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




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


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------040709030009070906000508-- From nobody Thu Apr 7 04:14:01 2016 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 858A412D79B; Thu, 7 Apr 2016 04:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.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 Ur9r_HaWyzED; Thu, 7 Apr 2016 04:13:52 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0078.outbound.protection.outlook.com [207.46.100.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBA8412D788; Thu, 7 Apr 2016 04:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.onmicrosoft.com; s=selector1-isoc-org; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VR2ELoPi5R+OSBQ0O1DK+gz//GUkVHLyi/Ep6bfoAnI=; b=BVTjO87M7ggkInvJ41G9dz+2p7Dr+uNN8oaCGxxkcZD+s63pmZ9tAfKBci9gKsv/BkiIZmZSX741y7htNeDMEvFcsXqHzum3VB+V3eUxLvnVjcwbGHvuAzFYmddWkmwjj+LgWIqIuAJkcDxJXGALBkjCtOZr/PlACBJMaEn23Sg= Authentication-Results: bobbriscoe.net; dkim=none (message not signed) header.d=none;bobbriscoe.net; dmarc=none action=none header.from=isoc.org; Received: from [IPv6:2001:67c:370:144:2496:426e:70ba:5bcf] (2001:67c:370:144:2496:426e:70ba:5bcf) by BY2PR06MB2213.namprd06.prod.outlook.com (10.166.113.151) with Microsoft SMTP Server (TLS) id 15.1.453.26; Thu, 7 Apr 2016 11:13:48 +0000 MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset="windows-1252" From: Matthew Ford In-Reply-To: <57063A22.2010709@bobbriscoe.net> Date: Thu, 7 Apr 2016 08:13:41 -0300 Content-Transfer-Encoding: quoted-printable Message-ID: <72E3332E-9B19-4C69-9E74-48205E7D2F43@isoc.org> References: <56C71869.9080503@bobbriscoe.net> <20160219182359.GA74531@verdi> <56CACCB1.2080502@bobbriscoe.net> <5703A963.6090306@bobbriscoe.net> <57059F43.1050406@bobbriscoe.net> <57063A22.2010709@bobbriscoe.net> To: Bob Briscoe X-Mailer: Apple Mail (2.3124) X-Originating-IP: [2001:67c:370:144:2496:426e:70ba:5bcf] X-ClientProxiedBy: BY2PR1001CA0053.namprd10.prod.outlook.com (10.164.163.21) To BY2PR06MB2213.namprd06.prod.outlook.com (10.166.113.151) X-MS-Office365-Filtering-Correlation-Id: 4323bb5c-54d6-4731-f9a2-08d35ed5b2bb X-Microsoft-Exchange-Diagnostics: 1; BY2PR06MB2213; 2:fSSzgsY42iRzI47uWAjHVWrnVw9lYAJQ4FNey7fvjsxSzFCtdO9Aa+bE4Lzh07OWXkjr6kQ4UGdhAMmcN+tYZs9DMZacuuPuOYazmCDTQpne/kAdGLoKhInGU6r9JOJn5U2kA9NuJyamyjPyvwONhVTp5XqZah//053VJy/W3KEjp8DTI/Z8Lx1UzH6J7QH3; 3:shP6o2jQw3epkXsG+2js+hzpKBFafvhUJ7kmessGKoF1d9DRw7VwJTZqA6h/1huZ4S33aALFODZYE6BGv8Jtev5kHNstPv8lQLTdPRaaaPaX0M1vT/y6FryWRJsUYWdN X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR06MB2213; X-Microsoft-Exchange-Diagnostics: 1; BY2PR06MB2213; 25:kc3yRtRW5z55xPLMA0j3LYhRmwUsvj+hncafzKSaQyO0X6tl5kaYv9QFGhjLX2wx/WCSXKF7nRBBmia3zTxyxBNqgXBOM3PATxL3upZqbPFtB7LjAjFLxiuS/LsYZh4zUcSNsZ5ZO/MMcZGhN7zkRXKVbgjexzA9FoCIqAtDVu+lXu8OvdTH05zgTB6MQF8scZnRdC9E0zIb0+HSHqwgzYhCKKRdDJXeTVEs3is7/ed6ltYEmzowBqMwWgP6cki/EQzAiSKLYIZu5pahm4c5Y6aalR5uEzhscEXjRMYfAkWQlX4hg7mPSfe+J2ho1QdnBeVlx1Pac9szKcXCDk7HVyd00vMVDmYwGAMAqktIg+OuKjFhocjNBgevnc7qFtZrWK9t9tXMimcOY5DY3H604qREAAatxP4/DLZ/WPd3nnDiRQKcLEUXMOmX0b3EC9VWrddfLGYQSP6xkNfv82uGNJomH0vC6g0VEKS87LtBQAz2pjaUmRl+vq4mV53EbXLolDhrS9OE5+rhIWZL9Np7yRdpnOtvtPPGFXFCCbGmsmq4Z2X1RNk/1phb1uZq0/kM+7URba9Y6F/XaefOkud/FUE9nD8KheA3a61cjAlt4X1bAOxthsGdSB7fy4EhdEFCS6b2/WOQK0LCy3P9oAPHfHKCKWa6d4OphQN+9jCLXeI= X-Microsoft-Exchange-Diagnostics: 1; BY2PR06MB2213; 20:BuEOyUyE91ytPtvlBFh/Aqyq7iJnvzIEPC/xbNg6YgyKeb/iXm6v6DMt3daltSUSflIp/ac+D5SJ3vq+HDLd5GWimh+vFjrMnHIOwsyhmr//L/6JbJ6Sf21DsGNwVb1/Qm1Kk4jM8Y7pF5ljOsZSc6GVx0OMcBWg3cc7FwFS46IyVgUETI9PK7P2DwV16AoAeDRYn7LmMRloTjAoUoZjOSOuNTncXm7zIcZcYPOrTUs405J1RUoSyAy+2uFtuhJzFDJcoer+3RKkOiTnB2rMQFvLsM+FIMxEU2Dpj16mj5wZar3NoV9HmOgwIilu8GvvU6dnp2lgydAYY83LzvfeQcqXWOAjUePKNDsD1PJ++fJqXX9pXtZfnsTQnBfGK5UHP6tlfHp0seHB767owJSUVGGayJnhAu4GAiMB4ZOyOgTDIQUqRdSafwKuzZhKdy0B7kNtoFisv4aNB3xyMRX8n047aiMHphBZsBeirvtXou0VtiUUOiD9FIzi2j5YsK8k; 4:NLIfRNtUSRV5jVQt05s5nkFAoOkbEtow/Adhv+vnJbb9kVKYnrldjrfIVz17NPsrM9KhE049mON9b3ab18UcbVbbP9QyT7o9M4V2zl3LreokP8xDeVk6SeY1Z3iB0W2ufYULB5Xxir4wlXuizda/fa+RzVSCqbna+BBUuJgF8MFG2IbLJ4wPFEE0uLsgy/lnb41P2C9HxMMX9AnVE9Go4CxNiFs+rMgsrZXpg3vHvCVWwSTKoIDw9jCyyHZHeSEu+h6TwRfy4LKmD1e2pUkFVs5VnVlaX277ZgXNEycGas8co4EJ1KwfpkgPI/bODVTXXDbdom/BdaHelRM2ndaNYXr/fX+z1v4RhHBHJ8GUKGHCaQxASquXJfltfYcH39k4 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BY2PR06MB2213; BCL:0; PCL:0; RULEID:; SRVR:BY2PR06MB2213; X-Forefront-PRVS: 0905A6B2C7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(52604005)(78114003)(497574002)(377454003)(24454002)(33656002)(47776003)(93886004)(4326007)(164054004)(92566002)(189998001)(50226001)(110136002)(86362001)(15395725005)(5008740100001)(2906002)(1096002)(586003)(42186005)(19580395003)(83716003)(19580405001)(6116002)(82746002)(36756003)(81166005)(2950100001)(15975445007)(77096005)(76176999)(57306001)(50986999)(50466002)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR06MB2213; H:[IPv6:2001:67c:370:144:2496:426e:70ba:5bcf]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BY2PR06MB2213; 23:XawH+f1LKZRDXqS/nO8+lhGu00+Uqc7PQ3wOy?= =?Windows-1252?Q?L3X4fEub7g0PFQSyJCw7IMtMokGm0tb6wwbka+VlBpXg3NqE2FsVb+qa?= =?Windows-1252?Q?C81CLC7v53IK/ZIsFxc6tniZMlnfVFYyw+fdHgRD0HCDCQi9S7l9Qsmj?= =?Windows-1252?Q?UUDnEthQBB/nPVTQt0zJA0dJ9YS4G+Ab1zsTM2x3QB4rYJzop760HTyC?= =?Windows-1252?Q?bKGiGaYJATiR2iTqplZqmBcdg+XILwgpLfIS9PFvwEbPM8M7q7W230Wq?= =?Windows-1252?Q?v0wpHoteTkkceYb8xeLcwrziHIoIZvHMQEHujZaoff6o2woNlv1N1raN?= =?Windows-1252?Q?gABeIXr9QarMyM6x+theFVaAiFyPAs2IviaBG8kRZyxmGqbOusOkAAO3?= =?Windows-1252?Q?IJlD3pV8CUuaObASUQApS+REGzRKX39rCD0tA0wOS3JpAS4hI6LEH9/M?= =?Windows-1252?Q?AVGb4Or5kd7op84Wlmof+XbWQcSivEk8csmJmOfXHDEoe4mPtcutflku?= =?Windows-1252?Q?rjqT2bwV8XC0l4Q7kNW//zV/R3A70unjr83SvN2Awb2rlToteX6qqtmp?= =?Windows-1252?Q?121V/ah4nBfWJk7j1cXTSst61Olg9DvI5ibXjJQf7vyVKQPWQXPZant+?= =?Windows-1252?Q?WLqL/TTMvgdIk7A8n156yJlXugCoMHF0HI/18paJqpkG06qiO6uaAXQa?= =?Windows-1252?Q?XMJDKBKCOWuGHwy3C/2f0cEYvR5erWXGmy8nX3XsvuOCsdvqBuQF2uye?= =?Windows-1252?Q?C+prOey8TUaNbOuFfLzovJmm9NkOMLtfkGisDPLwRz9JbJN7vlzIWEk2?= =?Windows-1252?Q?it/OnGbsC6EShuyxyvBd2WXGn/B0lxGkWjnJrcqv7JyqmHKWf+//dJHh?= =?Windows-1252?Q?dCvLz5lNQOolk7emDAY6+e1wbafzVarGEKuHt1VLSEYIt94wSrHCCnIA?= =?Windows-1252?Q?f5u/LiYVfci2mi/6uh9UWKObX4g6aJFnZhWRtrn1xUWYva+Zbih+VenQ?= =?Windows-1252?Q?yJXz4md9aCLliCW+lUid6VyOkD2LlbPTU8UsBzMdIgB5HNJB0p8vkOkV?= =?Windows-1252?Q?B3+E5PvVhX1HFUxUos1BD00jrhTrtmcEcrY?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR06MB2213; 5:i+jD8rNryH/bM6vcuyk/hBLhIR+yuPCxtVQqsAzMw45aI/1bpQVFWAR31hoE6eG+bfozz9Mn1rOxB9t+CG3XtMPXadQHVmeAoHCRE51h3jb3CmqKkx0It+4ec0KfCT9euok4ZuJYpWd+CI93czngbA==; 24:0HOPScpDhqSFE3m4KLztPls6ExH9FpE/wEcOpQ2R7uZjS83F/ST7lpyKO59qSyZ9n/wUxo1xLQHrim7FHAq9evoek0AWUhAZd3Iisw3m3dY= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Apr 2016 11:13:48.8923 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR06MB2213 Archived-At: Cc: tcpm IETF list , tsvwg IETF list , "tsv-ads@ietf.org" , TCP Prague List , "De Schepper, Koen \(Koen\)" , AQM IETF list Subject: Re: [aqm] [tcpm] [tcpPrague] [tsvwg] (Bar) BoF @IETF-95 'Ultra-Low Queuing Delay for All' (L4S, DualQ Coupled AQM, TCP Prague)? 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: Thu, 07 Apr 2016 11:13:56 -0000 Thanks for sharing these in advance Bob. Slide 10 of the first deck is = priceless! > On 7 Apr 2016, at 07:44, Bob Briscoe wrote: >=20 > Folks, >=20 > Some slides to frame the discussion at 9am this morning are uploaded = to: > https://riteproject.eu/dctth/#ietf-bar-bof > Nonetheless, we want most of the time to be for discussion. >=20 > Phil Eardley has agreed to chair the meeting. He has suggested: > Aim of meeting: > * To determine whether there is interest in working on this. > * To work out how to get the IETF to work on these pieces (ie the = meeting is not primarily a technical discussion) >=20 > Aaron Falk has kindly agreed to take notes. > We will need a volunteer for jabber scribe, as we have remote = attendees. >=20 > Cheers >=20 >=20 > Bob >=20 >=20 > On 07/04/16 00:44, Bob Briscoe wrote: >> Folks, >>=20 >> Reminder, agenda & supporting materials below for the Bar BoF on L4S = / DualQ Coupled AQM / TCP Prague >>=20 >> Event details >> Date/time: 09:00 - 10:00 local time (ART =3D 12-13:00 UTC) Thu 7 Apr = 2016 >> Room: Quebracho B >>=20 >> Supporting materials / background: >> https://riteproject.eu/dctth/ >> To use the time effectively, it will be assumed that people have a = working knowledge of what the technology is, and a rough idea of how it = works. >> For those wanting an introduction, a useful 2-pager in the IETF = Journal is linked from the above, plus videos of the demos etc.b=20 >> Or chat with us afterwards >>=20 >> Proposed Agenda: >> 09:00 >> * Note Well, Agenda Bashing [Bob] >> * Introduction/Background (very brief) [Bob] >> * Clarification Questions >> 09:15=20 >> * Status updates [Koen to lead], e.g.: >> - what people are doing on parts of the problem: >> - planned work >> - evaluation work >> - interest in implementing >> - willingness to review >> 09:40 >> * Build a standardisation roadmap [Bob to lead] >> * Build a BoF for the Berlin time-frame >> - should it be non-WG forming? >> - volunteers to help with organisation / writing problem = statement, etc. >> - which mailing list? >> - what name? >> * Discussion / Q&A >> 09:55 end >>=20 >> Most time will be allowed for people to talk from the floor. >>=20 >> Cheers >>=20 >>=20 >> Bob & Koen >>=20 >> On 05/04/16 13:02, Bob Briscoe wrote: >>> Folks, >>>=20 >>> We have a time and room for this Bar BoF: >>> Date/time: 09:00 - 10:00 ART (=3D 12-13:00 UTC) Thu 7 Apr 2016 >>> Room: Quebracho B >>>=20 >>> We have the regular IETF remote attendance facilities in that room. >>> The room is not being used for the following session, so we don't = have to vacate early. >>>=20 >>> Sorry for delay setting this up. My fault. >>> I've bcc'd a few people who have been asking about this = specifically. >>>=20 >>>=20 >>> Bob >>>=20 >>> On 30/03/16 21:13, Aaron Falk wrote: >>>> Did this get scheduled? >>>>=20 >>>> --aaron >>>>=20 >>>> On Mon, Feb 22, 2016 at 12:21 PM, Spencer Dawkins at IETF = wrote: >>>> Just to try to be helpful ... >>>>=20 >>>> On Mon, Feb 22, 2016 at 2:54 AM, Bob Briscoe = wrote: >>>> John, >>>>=20 >>>> On 19/02/16 18:23, John Leslie wrote: >>>> Bob Briscoe wrote: >>>> I'm cross-posting 'cos this impacts 3 IETF WGs and interested = implementers. >>>>=20 >>>> We would like to propose a Bar BoF at the Buenos Aires IETF, about = L4S, >>>> DualQ and solutions to the TCP Prague Requirements. >>>> This feels like it belongs as a non-WG-forming formal BoF. >>>>=20 >>>> It describes work spanning at least three WGs; and could = benefit from >>>> formal scheduling to avoid conflicts with those WGs and others. >>>>=20 >>>> OTOH, it really isn't to the point where a WG charter can = reasonably >>>> be drafted. First we must decide whether the work _can_ be split = among >>>> existing WGs. >>>>=20 >>>> However this may turn out, I wish to participate remotely. >>>> OK, we'll see if the secretariat can help us with that. >>>>=20 >>>> I believe that happens at http://www.ietf.org/meeting/amreq.html. = If you put "TSV" in as "type of meeting", your happy TSV ADs would see = the request. >>>>=20 >>>> Thanks, >>>>=20 >>>> Spencer >>>> =20 >>>> Unfortunately we ran out of time for the formal BoF deadline on = Friday. >>>>=20 >>>>=20 >>>> Bob >>>>=20 >>>>=20 >>>> -- >>>> John Leslie >>>>=20 >>>> _______________________________________________ >>>> tcpPrague mailing list >>>> tcpPrague@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpprague >>>>=20 >>>> --=20 >>>> ________________________________________________________________ >>>> Bob Briscoe http://bobbriscoe.net/ >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> aqm mailing list >>>>=20 >>>> aqm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/aqm >>>=20 >>> --=20 >>> ________________________________________________________________ >>> Bob Briscoe =20 >>> http://bobbriscoe.net/ >>>=20 >>> --=20 >>> ________________________________________________________________ >>> Bob Briscoe =20 >>> http://bobbriscoe.net/ >>>=20 >>> --=20 >>> ________________________________________________________________ >>> Bob Briscoe =20 >>> http://bobbriscoe.net/ >>>=20 >>> --=20 >>> ________________________________________________________________ >>> Bob Briscoe =20 >>> http://bobbriscoe.net/ >>>=20 >>> --=20 >>> ________________________________________________________________ >>> Bob Briscoe =20 >>> http://bobbriscoe.net/ >>>=20 >>> --=20 >>> ________________________________________________________________ >>> Bob Briscoe =20 >>> http://bobbriscoe.net/ >>=20 >> --=20 >> ________________________________________________________________ >> Bob Briscoe =20 >> http://bobbriscoe.net/ > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm From nobody Thu Apr 7 05:03:34 2016 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 2AE8112D81C; Thu, 7 Apr 2016 05:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, WEIRD_PORT=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 Hf0jGygGSnYX; Thu, 7 Apr 2016 05:03:31 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 75FA212D80A; Thu, 7 Apr 2016 05:03:30 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id t10so93443738ywa.0; Thu, 07 Apr 2016 05:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=/o47WtiqAn9oDvlejLzpHUw7mbRf+8UXh53heJjsDPI=; b=Ki3l1JJgZbzB/mjpxJoL0Xk4/T8TMPxodAFp8iESifL2v81hHjM6CWFTyrEkrigu7+ Rz7HDBxn7rIt6BVC50h0KJyM4uhQmI+DJBrujCTS5wQts/toMBFKcLvCv1TCyRuE2QCi MqNdfc2Q5j2UCK4ZhXzhLBUdOKsTXNSLfgEvE00IUllUE0vlZcZy7l1Ww6X7n6Qd5vTr P4EERIPum6WtXYGOHLXHHdxQ9puSCdxW7XXEPepj8YoWXyT+p0Qp7mTI8H/YyH4Avbz0 FvqiCXlTg6xNUt0XMkmDmskVg3EGQwezZE4QKd6ooPFGnvvkeT/z6kcyn7JfBG3R9hZu 8eQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=/o47WtiqAn9oDvlejLzpHUw7mbRf+8UXh53heJjsDPI=; b=atcuoF4iaS2gBmR3NAh0cKvhfpJsAI5UF70BZ1Xv45oKZCW+iDdWgqDXEc/nmqHGUD DzxmxyD5piIrQimmGa5Mez2wQ/A8TB0Dx+rY7tJacyfj+Q9wlonIdWIm3TjEoAPiJtGt JqUWJotLNP77wS+MnDpmZ8YVUJFwnzklru44OCSG4BLsE0b94Xd1CY/v/MtXM5gNWcJA 4ODe8xRiuhCxWFrjy5zEIJIMM+9ZfPTXPSezkXExwCz63npI1kjvmADvrVA4N2nneyVV kgh5mrzNM5fjUnU23T4fJ0L4rltc7FQIlFG3+nVvgPSMqlgLUK2bLJRHoQQhwEU6eX/E glNA== X-Gm-Message-State: AD7BkJJ3EIIieoPO27GiwWhfppJBCCq8J3AHckbzyw2c7UQ94ZVcTDS3rv+ZBy/B3vW1c3488Q1zuJyIjY/77w== MIME-Version: 1.0 X-Received: by 10.13.225.148 with SMTP id k142mr1484448ywe.91.1460030609677; Thu, 07 Apr 2016 05:03:29 -0700 (PDT) Received: by 10.37.70.198 with HTTP; Thu, 7 Apr 2016 05:03:29 -0700 (PDT) In-Reply-To: <72E3332E-9B19-4C69-9E74-48205E7D2F43@isoc.org> References: <56C71869.9080503@bobbriscoe.net> <20160219182359.GA74531@verdi> <56CACCB1.2080502@bobbriscoe.net> <5703A963.6090306@bobbriscoe.net> <57059F43.1050406@bobbriscoe.net> <57063A22.2010709@bobbriscoe.net> <72E3332E-9B19-4C69-9E74-48205E7D2F43@isoc.org> Date: Thu, 7 Apr 2016 09:03:29 -0300 Message-ID: From: Aaron Falk To: Matthew Ford Content-Type: multipart/alternative; boundary=94eb2c077550d9fce1052fe3dde8 Archived-At: Cc: tcpm IETF list , tsvwg IETF list , Bob Briscoe , TCP Prague List , "tsv-ads@ietf.org" , AQM IETF list Subject: Re: [aqm] [tsvwg] [tcpm] [tcpPrague] (Bar) BoF @IETF-95 'Ultra-Low Queuing Delay for All' (L4S, DualQ Coupled AQM, TCP Prague)? 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: Thu, 07 Apr 2016 12:03:34 -0000 --94eb2c077550d9fce1052fe3dde8 Content-Type: text/plain; charset=UTF-8 Note taking is happening here: http://etherpad.tools.ietf.org:9000/p/notes-ietf-95-l4s-barbof On Thu, Apr 7, 2016 at 8:13 AM, Matthew Ford wrote: > Thanks for sharing these in advance Bob. Slide 10 of the first deck is > priceless! > > > On 7 Apr 2016, at 07:44, Bob Briscoe wrote: > > > > Folks, > > > > Some slides to frame the discussion at 9am this morning are uploaded to: > > https://riteproject.eu/dctth/#ietf-bar-bof > > Nonetheless, we want most of the time to be for discussion. > > > > Phil Eardley has agreed to chair the meeting. He has suggested: > > Aim of meeting: > > * To determine whether there is interest in working on this. > > * To work out how to get the IETF to work on these pieces (ie the > meeting is not primarily a technical discussion) > > > > Aaron Falk has kindly agreed to take notes. > > We will need a volunteer for jabber scribe, as we have remote attendees. > > > > Cheers > > > > > > Bob > > > > > > On 07/04/16 00:44, Bob Briscoe wrote: > >> Folks, > >> > >> Reminder, agenda & supporting materials below for the Bar BoF on L4S / > DualQ Coupled AQM / TCP Prague > >> > >> Event details > >> Date/time: 09:00 - 10:00 local time (ART = 12-13:00 UTC) Thu 7 Apr 2016 > >> Room: Quebracho B > >> > >> Supporting materials / background: > >> https://riteproject.eu/dctth/ > >> To use the time effectively, it will be assumed that people have a > working knowledge of what the technology is, and a rough idea of how it > works. > >> For those wanting an introduction, a useful 2-pager in the IETF Journal > is linked from the above, plus videos of the demos etc.b > >> Or chat with us afterwards > >> > >> Proposed Agenda: > >> 09:00 > >> * Note Well, Agenda Bashing [Bob] > >> * Introduction/Background (very brief) [Bob] > >> * Clarification Questions > >> 09:15 > >> * Status updates [Koen to lead], e.g.: > >> - what people are doing on parts of the problem: > >> - planned work > >> - evaluation work > >> - interest in implementing > >> - willingness to review > >> 09:40 > >> * Build a standardisation roadmap [Bob to lead] > >> * Build a BoF for the Berlin time-frame > >> - should it be non-WG forming? > >> - volunteers to help with organisation / writing problem statement, > etc. > >> - which mailing list? > >> - what name? > >> * Discussion / Q&A > >> 09:55 end > >> > >> Most time will be allowed for people to talk from the floor. > >> > >> Cheers > >> > >> > >> Bob & Koen > >> > >> On 05/04/16 13:02, Bob Briscoe wrote: > >>> Folks, > >>> > >>> We have a time and room for this Bar BoF: > >>> Date/time: 09:00 - 10:00 ART (= 12-13:00 UTC) Thu 7 Apr 2016 > >>> Room: Quebracho B > >>> > >>> We have the regular IETF remote attendance facilities in that room. > >>> The room is not being used for the following session, so we don't have > to vacate early. > >>> > >>> Sorry for delay setting this up. My fault. > >>> I've bcc'd a few people who have been asking about this specifically. > >>> > >>> > >>> Bob > >>> > >>> On 30/03/16 21:13, Aaron Falk wrote: > >>>> Did this get scheduled? > >>>> > >>>> --aaron > >>>> > >>>> On Mon, Feb 22, 2016 at 12:21 PM, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > >>>> Just to try to be helpful ... > >>>> > >>>> On Mon, Feb 22, 2016 at 2:54 AM, Bob Briscoe > wrote: > >>>> John, > >>>> > >>>> On 19/02/16 18:23, John Leslie wrote: > >>>> Bob Briscoe wrote: > >>>> I'm cross-posting 'cos this impacts 3 IETF WGs and interested > implementers. > >>>> > >>>> We would like to propose a Bar BoF at the Buenos Aires IETF, about > L4S, > >>>> DualQ and solutions to the TCP Prague Requirements. > >>>> This feels like it belongs as a non-WG-forming formal BoF. > >>>> > >>>> It describes work spanning at least three WGs; and could benefit > from > >>>> formal scheduling to avoid conflicts with those WGs and others. > >>>> > >>>> OTOH, it really isn't to the point where a WG charter can > reasonably > >>>> be drafted. First we must decide whether the work _can_ be split among > >>>> existing WGs. > >>>> > >>>> However this may turn out, I wish to participate remotely. > >>>> OK, we'll see if the secretariat can help us with that. > >>>> > >>>> I believe that happens at http://www.ietf.org/meeting/amreq.html. If > you put "TSV" in as "type of meeting", your happy TSV ADs would see the > request. > >>>> > >>>> Thanks, > >>>> > >>>> Spencer > >>>> > >>>> Unfortunately we ran out of time for the formal BoF deadline on > Friday. > >>>> > >>>> > >>>> Bob > >>>> > >>>> > >>>> -- > >>>> John Leslie > >>>> > >>>> _______________________________________________ > >>>> tcpPrague mailing list > >>>> tcpPrague@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/tcpprague > >>>> > >>>> -- > >>>> ________________________________________________________________ > >>>> Bob Briscoe http://bobbriscoe.net/ > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> tcpm mailing list > >>>> tcpm@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/tcpm > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> aqm mailing list > >>>> > >>>> aqm@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/aqm > >>> > >>> -- > >>> ________________________________________________________________ > >>> Bob Briscoe > >>> http://bobbriscoe.net/ > >>> > >>> -- > >>> ________________________________________________________________ > >>> Bob Briscoe > >>> http://bobbriscoe.net/ > >>> > >>> -- > >>> ________________________________________________________________ > >>> Bob Briscoe > >>> http://bobbriscoe.net/ > >>> > >>> -- > >>> ________________________________________________________________ > >>> Bob Briscoe > >>> http://bobbriscoe.net/ > >>> > >>> -- > >>> ________________________________________________________________ > >>> Bob Briscoe > >>> http://bobbriscoe.net/ > >>> > >>> -- > >>> ________________________________________________________________ > >>> Bob Briscoe > >>> http://bobbriscoe.net/ > >> > >> -- > >> ________________________________________________________________ > >> Bob Briscoe > >> http://bobbriscoe.net/ > > _______________________________________________ > > aqm mailing list > > aqm@ietf.org > > https://www.ietf.org/mailman/listinfo/aqm > > --94eb2c077550d9fce1052fe3dde8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Apr 7, 2016 at 8:13 AM, M= atthew Ford <ford@isoc.org> wrote:
Thanks for sharing these in advance Bob. Slide 10 of the first deck = is priceless!

> On 7 Apr 2016, at 07:44, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>
> Folks,
>
> Some slides to frame the discussion at 9am this morning are uploaded t= o:
> https://riteproject.eu/dctth/#ietf-bar-bof
> Nonetheless, we want most of the time to be for discussion.
>
> Phil Eardley has agreed to chair the meeting. He has suggested:
> Aim of meeting:
> * To determine whether there is interest in working on this.
> * To work out how to get the IETF to work on these pieces (ie the meet= ing is not primarily a technical discussion)
>
> Aaron Falk has kindly agreed to take notes.
> We will need a volunteer for jabber scribe, as we have remote attendee= s.
>
> Cheers
>
>
> Bob
>
>
> On 07/04/16 00:44, Bob Briscoe wrote:
>> Folks,
>>
>> Reminder, agenda & supporting materials below for the Bar BoF = on L4S / DualQ Coupled AQM / TCP Prague
>>
>> Event details
>> Date/time: 09:00 - 10:00 local time (ART =3D 12-13:00 UTC) Thu 7 A= pr 2016
>> Room: Quebracho B
>>
>> Supporting materials / background:
>> https://riteproject.eu/dctth/
>> To use the time effectively, it will be assumed that people have a= working knowledge of what the technology is, and a rough idea of how it wo= rks.
>> For those wanting an introduction, a useful 2-pager in the IETF Jo= urnal is linked from the above, plus videos of the demos etc.b
>> Or chat with us afterwards
>>
>> Proposed Agenda:
>> 09:00
>> * Note Well, Agenda Bashing [Bob]
>> * Introduction/Background (very brief) [Bob]
>> * Clarification Questions
>> 09:15
>> * Status updates [Koen to lead], e.g.:
>>=C2=A0 =C2=A0- what people are doing on parts of the problem:
>>=C2=A0 =C2=A0- planned work
>>=C2=A0 =C2=A0- evaluation work
>>=C2=A0 =C2=A0- interest in implementing
>>=C2=A0 =C2=A0- willingness to review
>> 09:40
>> * Build a standardisation roadmap [Bob to lead]
>> * Build a BoF for the Berlin time-frame
>>=C2=A0 =C2=A0 - should it be non-WG forming?
>>=C2=A0 =C2=A0 - volunteers to help with organisation / writing prob= lem statement, etc.
>>=C2=A0 =C2=A0 - which mailing list?
>>=C2=A0 =C2=A0 - what name?
>> * Discussion / Q&A
>> 09:55 end
>>
>> Most time will be allowed for people to talk from the floor.
>>
>> Cheers
>>
>>
>> Bob & Koen
>>
>> On 05/04/16 13:02, Bob Briscoe wrote:
>>> Folks,
>>>
>>> We have a time and room for this Bar BoF:
>>> Date/time: 09:00 - 10:00 ART (=3D 12-13:00 UTC) Thu 7 Apr 2016=
>>> Room: Quebracho B
>>>
>>> We have the regular IETF remote attendance facilities in that = room.
>>> The room is not being used for the following session, so we do= n't have to vacate early.
>>>
>>> Sorry for delay setting this up. My fault.
>>> I've bcc'd a few people who have been asking about thi= s specifically.
>>>
>>>
>>> Bob
>>>
>>> On 30/03/16 21:13, Aaron Falk wrote:
>>>> Did this get scheduled?
>>>>
>>>> --aaron
>>>>
>>>> On Mon, Feb 22, 2016 at 12:21 PM, Spencer Dawkins at IETF = <spencerdawkins.ietf@gm= ail.com> wrote:
>>>> Just to try to be helpful ...
>>>>
>>>> On Mon, Feb 22, 2016 at 2:54 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>>>> John,
>>>>
>>>> On 19/02/16 18:23, John Leslie wrote:
>>>> Bob Briscoe <iet= f@bobbriscoe.net> wrote:
>>>> I'm cross-posting 'cos this impacts 3 IETF WGs and= interested implementers.
>>>>
>>>> We would like to propose a Bar BoF at the Buenos Aires IET= F, about L4S,
>>>> DualQ and solutions to the TCP Prague Requirements.
>>>>=C2=A0 =C2=A0 =C2=A0This feels like it belongs as a non-WG-= forming formal BoF.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0It describes work spanning at least thr= ee WGs; and could benefit from
>>>> formal scheduling to avoid conflicts with those WGs and ot= hers.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0OTOH, it really isn't to the point = where a WG charter can reasonably
>>>> be drafted. First we must decide whether the work _can_ be= split among
>>>> existing WGs.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0However this may turn out, I wish to pa= rticipate remotely.
>>>> OK, we'll see if the secretariat can help us with that= .
>>>>
>>>> I believe that happens at http://www.ietf.org= /meeting/amreq.html. If you put "TSV" in as "type of mee= ting", your happy TSV ADs would see the request.
>>>>
>>>> Thanks,
>>>>
>>>> Spencer
>>>>
>>>> Unfortunately we ran out of time for the formal BoF deadli= ne on Friday.
>>>>
>>>>
>>>> Bob
>>>>
>>>>
>>>> --
>>>> John Leslie <john@jlc.n= et>
>>>>
>>>> _______________________________________________
>>>> tcpPrague mailing list
>>>> tcpPrague@ietf.org
>>>> https://www.ietf.org/mailman/listinf= o/tcpprague
>>>>
>>>> --
>>>> __________________________________________________________= ______
>>>> Bob Briscoe=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://bob= briscoe.net/
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> tcpm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tcp= m
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> aqm mailing list
>>>>
>>>> aqm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/aqm=
>>>
>>> --
>>> ______________________________________________________________= __
>>> Bob Briscoe
>>> http://bobbriscoe.net/
>>>
>>> --
>>> ______________________________________________________________= __
>>> Bob Briscoe
>>> http://bobbriscoe.net/
>>>
>>> --
>>> ______________________________________________________________= __
>>> Bob Briscoe
>>> http://bobbriscoe.net/
>>>
>>> --
>>> ______________________________________________________________= __
>>> Bob Briscoe
>>> http://bobbriscoe.net/
>>>
>>> --
>>> ______________________________________________________________= __
>>> Bob Briscoe
>>> http://bobbriscoe.net/
>>>
>>> --
>>> ______________________________________________________________= __
>>> Bob Briscoe
>>> http://bobbriscoe.net/
>>
>> --
>> ________________________________________________________________ >> Bob Briscoe
>> http://bobbriscoe.net/
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm


--94eb2c077550d9fce1052fe3dde8-- From nobody Wed Apr 13 05:17:42 2016 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 6459212DBED for ; Wed, 13 Apr 2016 05:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] 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 lBcwFw4HpksB for ; Wed, 13 Apr 2016 05:17:39 -0700 (PDT) Received: from iport1.cc.swin.edu.au (iport1.cc.swin.edu.au [136.186.0.49]) by ietfa.amsl.com (Postfix) with ESMTP id 04F4212DCAF for ; Wed, 13 Apr 2016 05:17:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,479,1454936400"; d="scan'208";a="19095132" Received: from gsp-ex01.ds.swin.edu.au (HELO outlook.swin.edu.au) ([136.186.126.17]) by iport1.cc.swin.edu.au with ESMTP; 13 Apr 2016 22:17:34 +1000 Received: from GSP-EX02.ds.swin.edu.au ([169.254.2.170]) by gsp-ex01.ds.swin.edu.au ([169.254.1.160]) with mapi id 14.03.0294.000; Wed, 13 Apr 2016 22:17:34 +1000 From: Rasool Al-Saadi To: "Rong Pan (ropan)" , "aqm@ietf.org" Thread-Topic: [aqm] I-D Action: draft-ietf-aqm-pie-05.txt Thread-Index: AQHRc/c85Ma2ukqlGEaDxxqLRko+gZ9k511ggBTVPICADlYA4A== Date: Wed, 13 Apr 2016 12:17:34 +0000 Message-ID: <6545444AE21C2749939E637E56594CEA3C1FB2F6@gsp-ex02.ds.swin.edu.au> References: <20160301201602.24979.59154.idtracker@ietfa.amsl.com> <6545444AE21C2749939E637E56594CEA3C1D01A0@gsp-ex02.ds.swin.edu.au> In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [136.186.112.108] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Grenville Armitage Subject: Re: [aqm] I-D Action: draft-ietf-aqm-pie-05.txt 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: Wed, 13 Apr 2016 12:17:41 -0000 On Tuesday, 5 April 2016, Rong Pan (ropan) wrote: >=20 > Rasool, >=20 > Thanks for your detailed review. Please see the comments below and a new > draft has been posted. >=20 > Regards, >=20 > Rong >=20 > >For new drop_prob calculation, how can drop_prob_ be just a division of > >queue lengths? > > drop_prob_(i)=3Dqueue_.byte_length(i)/max(queue_.byte_length(i)) >=20 >=20 > >>>>>>>>>>>>>>>>>>>>>>>>>RP: Let=B9s say there are two flows that are > >>>>>>>>>>>>>>>>>>>>>>>>>queued into > two sfq queues. One flow is an elephant flow and one flow is mice flow. T= otal > latency is caused by the elephant flow. The above equation makes sure tha= t > the mice flow (whose queue length is zero, or very small amount) won=B9t = be > dropped. > Besides, since it is mice flow, it would be hard to measure its departure= rate > as the queue would never build up.qdelay >=20 Thank you for the explanation. I found section 4.6 SFQ-PIE in [*] is cleare= r than in the draft. I hope SFQ paragraph of PIE draft becomes a little cle= arer. [*] http://www.cablelabs.com/wp-content/uploads/2014/06/DOCSIS-AQM_May2014.= pdf > > > >5) In pages 23 and 24, > > > >> //If the queue has been idle for a while, turn off PIE > >> //reset counters when accessing the queue after some idle > >> //period if PIE was active before > >> if ( PIE->drop_prob_ =3D=3D 0 && PIE->qdelay_old_ =3D=3D 0 > >> && queue_.byte_length() =3D=3D 0) { > >> PIE->active_ =3D INACTIVE; > > > >According to section 5.3 (Turning PIE on and off), the condition of > >deactivating PIE should be: > > > >if (PIE->drop_prob_ =3D=3D 0 and current_qdelay < QDELAY_REF/2 and > > PIE->qdelay_old_ < QDELAY_REF/2) { >=20 >=20 > >>>>>>>>>>>>>>>>>>>>>>>>>>RP: Fixed. >=20 I am unsure whether section 5.3 is correct or the old code (in draft-ietf-a= qm-pie-05.txt) with queue_.byte_length() =3D=3D 0 was correct. In my PIE im= plementation, I found that without using queue_.byte_length() =3D=3D 0, PI= E turns off after a very short period and causes queue delay to become unco= ntrolled until queue length exceeds 1/3 drop-tail size. I put queue_.byte_l= ength() =3D=3D 0 condition and I got better results. Regards, Rasool From nobody Wed Apr 13 17:49:27 2016 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 1A7B612DB6E; Wed, 13 Apr 2016 17:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.918 X-Spam-Level: X-Spam-Status: No, score=-107.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 44CbUidwsXxd; Wed, 13 Apr 2016 17:49:24 -0700 (PDT) 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 0457612DB91; Wed, 13 Apr 2016 17:49:23 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 51D6518046C; Wed, 13 Apr 2016 17:49:09 -0700 (PDT) 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: <20160414004909.51D6518046C@rfc-editor.org> Date: Wed, 13 Apr 2016 17:49:09 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, aqm@ietf.org, rfc-editor@rfc-editor.org Subject: [aqm] RFC 7806 on On Queuing, Marking, and Dropping 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: Thu, 14 Apr 2016 00:49:26 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7806 Title: On Queuing, Marking, and Dropping Author: F. Baker, R. Pan Status: Informational Stream: IETF Date: April 2016 Mailbox: fred@cisco.com, ropan@cisco.com Pages: 16 Characters: 37818 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-aqm-fq-implementation-05.txt URL: https://www.rfc-editor.org/info/rfc7806 DOI: http://dx.doi.org/10.17487/RFC7806 This note discusses queuing and marking/dropping algorithms. While these algorithms may be implemented in a coupled manner, this note argues that specifications, measurements, and comparisons should decouple the different algorithms and their contributions to system behavior. 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 Thu Apr 14 19:38:17 2016 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 AF7E012E687 for ; Thu, 14 Apr 2016 19:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_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 2cww_qfcQwxg for ; Thu, 14 Apr 2016 19:38:14 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::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 E3BEC12E682 for ; Thu, 14 Apr 2016 19:38:13 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id w85so112370353oiw.0 for ; Thu, 14 Apr 2016 19:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to :content-transfer-encoding; bh=fe16c3qYCZXFcutibSrOVJPaKGHIxT465Ie8q+wnFmE=; b=EpCTEfFAUPflu8Z6/zZyiftZx5XPziYkNp1+Dbn7+b9nxcRN7DKU7D66ILXaaErC/A jeF2oq2/6OzGYAF/QsEN9TY3SbTwReHq3BWCeScHs0Xj3odLBsolMbt3H2PAHEF2ZV1o hHrqsTGNflry43NOJHefUq6P9YzwemqOx355/y/unngZRbIp4+4b/CkdoyJR6uJV+J6t pVuqfCobnyTky9/5wk1D/1k2uxhPawrk0koIDAADWYQKUBgMK1PV4ohnikscpqBXNqoH htusN9ZhLcQnuWmRVu1EIQSxVWoVJUG+mHAT2v/Glkx9kQv1qLt+tbK5WGrbC7raErkH Vjbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-transfer-encoding; bh=fe16c3qYCZXFcutibSrOVJPaKGHIxT465Ie8q+wnFmE=; b=JJGuibEy8wCBiPo6iUjFc9RAEDiNoDRJ1uv1X+eKiDc1ew7drh8p+9AM7Nefe6BASg BqollJN2Nuq7Yc8Xu66p+GfrBs2eYUFFlHgdllE6YyloMzu3sMhArZr5bMqEatn/yHwz mkWyANR2zUY8GGDwKuzhA5ETwV/z9NUr5HQkh3iCe/LJP4BguHiqpq9w5EOtu2lr4ZlY O6F+SeiE0oq1hFlreFM9wtQP36sPtDKSp9L5xCyjTnOZvNASLLM4Gfyy8IajMVDgSncE XAA3wbxYZ0Z3Y8rP2q11DQrfZl7pFgsEnPkHDpFbLuNeT1XAgxtJ7f72HGGsP1Prcjpf J61Q== X-Gm-Message-State: AOPr4FVCa6as1G6nBwVR58cOuH8683nC01oBg7SMyEr7F6gXnSRdmM5a/DHi49E63n2yCuvozxF24GDGpUjoHA== MIME-Version: 1.0 X-Received: by 10.157.57.132 with SMTP id y4mr8739515otb.169.1460687893128; Thu, 14 Apr 2016 19:38:13 -0700 (PDT) Received: by 10.202.79.194 with HTTP; Thu, 14 Apr 2016 19:38:13 -0700 (PDT) Date: Thu, 14 Apr 2016 19:38:13 -0700 Message-ID: From: Dave Taht To: "aqm@ietf.org" , bloat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [aqm] A bit of history on RFC970 and RFC896 from john nagle 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, 15 Apr 2016 02:38:15 -0000 ---------- Forwarded message ---------- From: John Nagle Date: Thu, Apr 14, 2016 at 7:14 PM Subject: Re: Bufferbloat and FQ and you To: Dave Taht Cc: ropan@cisco.com On 04/14/2016 03:33 PM, Dave Taht wrote: > > https://www.rfc-editor.org/rfc/rfc7806.txt was published today. "There is extensive history in the set of algorithms collectively referred to as "fair queuing". The model was initially discussed in [RFC970], which proposed it hypothetically as a solution to the TCP Silly Window Syndrome issue in BSD 4.1." That's somewhat wrong. First, tinygram prevention (the "Nagle algorithm") is not about "silly window syndrome". Silly window syndrome occurs when the window is full, and the reader does a small read, resulting in the sender being allowed a small write, resulting in very short messages. The solution is clearly to not offer more window until there's at least one full size datagram worth of window available. Tinygram prevention is a problem when the window is empty, not full, and the writer is doing small writes. The question is how to consolidate those writes. It's not obvious how to do this without impacting interactive response. The classic solution, from X.25, was an accumulation timer with a human response time sized delay. That's a bad idea, but unfortunately the people who put in delayed ACKs didn't know that. They were trying to fix TELNET responsiveness at Berkeley, which was using a large number of dumb terminals connected to terminal servers at the time. Delayed ACKs with a fixed timer are useful in that situation, and in few others. Actually, this didn't involve 4.1BSD's netowrking; we at Ford Aerospace were running a heavily modified version of 3COM's UNET TCP/IP stack on various UNIX systems. That TCP/IP stack lost out because it cost about $4000 per node for the software. The tinygram stuff was in my RFC 896, and isn't really relevant to fair queuing or congestion management in routers and other middle boxes. The important part of RFC970 is at the section headed "Game Theoretic Aspects of Network Congestion". This discusses the relationship between endpoints and middle boxes, and the need to create an ecosystem which does not reward bad endpoint behavior. The [NOFAIR]] reference is interesting. Yes, fairness is gameable. But FIFO is so much worse, as the bufferbloat people point out. It's worth thinking about when a packet becomes useless and should be dropped. If the packet times out (this was originally what TTL was for; it was a seconds count), it can be dropped as obsolete. A router which looks above the IP level could also detect that the packet has been superseded by a later packet in the same flow, that is, there's a retransmitted copy also queued. If enough resources are available, that's the only packet dropping you have to do. As an optimization, you can also drop packets that are so far back in queues that they'll time out before they're sent. It's worth viewing that as a goal - don't drop any packets that would be useful if they were delivered. Just reorder based on notions of fairness and quality of service. This is the opposite of Random Early Drop, but that's sort of a meat-axe approach. Bufferbloat is only bad if the queuing is FIFO-dumb. It's fine to have lots of queue space if you manage it well. (I'm retired from all this. It's up to you guys now.) John Nagle --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org From nobody Mon Apr 18 04:30:01 2016 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 7DA2112D707 for ; Mon, 18 Apr 2016 04:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996] 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 OAC2vou_Myfz for ; Mon, 18 Apr 2016 04:29:58 -0700 (PDT) Received: from iport2.cc.swin.edu.au (iport2.cc.swin.edu.au [136.186.0.52]) by ietfa.amsl.com (Postfix) with ESMTP id 241DF12D5BC for ; Mon, 18 Apr 2016 04:29:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,502,1454936400"; d="scan'208";a="19047243" Received: from gsp-ex01.ds.swin.edu.au (HELO outlook.swin.edu.au) ([136.186.126.17]) by iport2.cc.swin.edu.au with ESMTP; 18 Apr 2016 21:29:57 +1000 Received: from GSP-EX02.ds.swin.edu.au ([169.254.2.170]) by gsp-ex01.ds.swin.edu.au ([169.254.1.160]) with mapi id 14.03.0294.000; Mon, 18 Apr 2016 21:29:56 +1000 From: Rasool Al-Saadi To: "aqm@ietf.org" , "freebsd-net@freebsd.org" , "freebsd-ipfw@freebsd.org" Thread-Topic: Dummynet AQM v0.2- CoDel, FQ-CoDel, PIE and FQ-PIE for FreeBSD's ipfw/dummynet Thread-Index: AdGZZMR7qylo1SZqRpSWlM5D+/m1Cw== Date: Mon, 18 Apr 2016 11:29:55 +0000 Message-ID: <6545444AE21C2749939E637E56594CEA3C206A7B@gsp-ex02.ds.swin.edu.au> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [136.186.126.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Grenville Armitage Subject: [aqm] Dummynet AQM v0.2- CoDel, FQ-CoDel, PIE and FQ-PIE for FreeBSD's ipfw/dummynet 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: Mon, 18 Apr 2016 11:30:00 -0000 Dear all, I would like to announce that we (myself and Grenville Armitage) released D= ummynet AQM v0.2, which is an independent implementation of CoDel, FQ-CoDel= PIE and FQ-PIE* for FreeBSD's ipfw/dummynet framework, based on the IETF = CoDel [1], FQ-CoDel [2] and PIE [3] Internet-Drafts. * "FlowQueue-PIE" (FQ-PIE) implementation combines FQ-CoDel's FlowQueuing w= ith PIE's individual queue management. In addition to PIE and FQ-PIE, this version includes bugs fixing and improv= ements to CoDel and FQ-CoDel code. We prepared patches for FreeBSD11-CURRENT-r297692 and FreeBSD 10.x-RELEASE= (10.0, 10.1, 10.2, 10.3), and a technical report of our implementation. Patches and documentation can be found in: http://caia.swin.edu.au/freebsd/aqm Technical report: http://caia.swin.edu.au/reports/160418A/CAIA-TR-160418A.pdf [1] "Controlled Delay Active Queue Management", https://tools.ietf.org/htm= l/draft-ietf-aqm-codel-03 [2] "FlowQueue-Codel" , https://tools.ietf.org/html/draft-ietf-aqm-fq-codel= -06 [3] "PIE: A Lightweight Control Scheme To Address the Bufferbloat Problem",= https://tools.ietf.org/html/draft-ietf-aqm-pie-06 Regards, Rasool Al-Saadi From nobody Mon Apr 18 23:48:07 2016 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 E3A3D12DC03 for ; Mon, 18 Apr 2016 23:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 jtiIjZivhh4s for ; Mon, 18 Apr 2016 23:48:04 -0700 (PDT) Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 478A512DB86 for ; Mon, 18 Apr 2016 23:47:59 -0700 (PDT) Received: from dair-1972.gw.taht.net (c-73-252-201-217.hsd1.ca.comcast.net [73.252.201.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 4EE0E21322 for ; Tue, 19 Apr 2016 06:47:56 +0000 (UTC) To: aqm@ietf.org References: <6545444AE21C2749939E637E56594CEA3C206A7B@gsp-ex02.ds.swin.edu.au> From: =?UTF-8?Q?Dave_T=c3=a4ht?= Message-ID: <5715D5DF.7010408@taht.net> Date: Mon, 18 Apr 2016 23:53:19 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <6545444AE21C2749939E637E56594CEA3C206A7B@gsp-ex02.ds.swin.edu.au> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [aqm] Dummynet AQM v0.2- CoDel, FQ-CoDel, PIE and FQ-PIE for FreeBSD's ipfw/dummynet 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, 19 Apr 2016 06:48:06 -0000 On 4/18/16 4:29 AM, Rasool Al-Saadi wrote: > Dear all, > > I would like to announce that we (myself and Grenville Armitage) released Dummynet AQM v0.2, which is an independent implementation of CoDel, FQ-CoDel PIE and FQ-PIE* for FreeBSD's ipfw/dummynet framework, based on the IETF CoDel [1], FQ-CoDel [2] and PIE [3] Internet-Drafts. > > * "FlowQueue-PIE" (FQ-PIE) implementation combines FQ-CoDel's FlowQueuing with PIE's individual queue management. > > In addition to PIE and FQ-PIE, this version includes bugs fixing and improvements to CoDel and FQ-CoDel code. thx for addressing nearly all my comments on v0.1! > We prepared patches for FreeBSD11-CURRENT-r297692 and FreeBSD 10.x-RELEASE (10.0, 10.1, 10.2, 10.3), and a technical report of our implementation. Rasool: Can you suggest to this guy that he try a "quantum 300" for his 600kbit uplink? I totally agree with his use of a smaller IW, also. https://www.mail-archive.com/freebsd-net%40freebsd.org/msg51463.html As for his headaches with pppoe and other sorts of odd (e.g. DSL/ATM) framing, it's a real headache with soft shaping. HTB has infrastructure (in linux) to handle it properly, as does cake, but it's a PITA. Can this code be configured to run at physical line rates (10Mbit, 100, 1GigE), without a shaper? What is the effect? (BQL was needed for linux here) > Patches and documentation can be found in: > http://caia.swin.edu.au/freebsd/aqm > > Technical report: > http://caia.swin.edu.au/reports/160418A/CAIA-TR-160418A.pdf > > > [1] "Controlled Delay Active Queue Management", https://tools.ietf.org/html/draft-ietf-aqm-codel-03 > [2] "FlowQueue-Codel" , https://tools.ietf.org/html/draft-ietf-aqm-fq-codel-06 > [3] "PIE: A Lightweight Control Scheme To Address the Bufferbloat Problem", https://tools.ietf.org/html/draft-ietf-aqm-pie-06 > > Regards, > Rasool Al-Saadi > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > From nobody Tue Apr 19 10:03:44 2016 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 4B35412D88B for ; Tue, 19 Apr 2016 10:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 Wsm4KF_cXnv9 for ; Tue, 19 Apr 2016 10:03:42 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 0AA5F12D551 for ; Tue, 19 Apr 2016 10:03:41 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id u3JH3d5D015720; Tue, 19 Apr 2016 19:03:39 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id C18776210E; Tue, 19 Apr 2016 19:03:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id kAiruK00axG5; Tue, 19 Apr 2016 19:03:38 +0200 (CEST) Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 1F59062115; Tue, 19 Apr 2016 19:03:38 +0200 (CEST) Date: Tue, 19 Apr 2016 19:03:38 +0200 Message-ID: <878u098r9x.wl-jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Dave Taht In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 19 Apr 2016 19:03:40 +0200 (CEST) X-Miltered: at korolev with ID 571664EB.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 571664EB.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 571664EB.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Cc: "aqm@ietf.org" , bloat Subject: Re: [aqm] [Bloat] A bit of history on RFC970 and RFC896 from john nagle 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, 19 Apr 2016 17:03:43 -0000 > The classic solution, from X.25, was an accumulation timer with a human > response time sized delay. That's a bad idea, but unfortunately the > people who put in delayed ACKs didn't know that. They were trying to > fix TELNET responsiveness at Berkeley, which was using a large number of > dumb terminals connected to terminal servers at the time. Delayed ACKs > with a fixed timer are useful in that situation, and in few others. Nagle has made this point repeatedly, and it's a convincing one. Is anyone working on improving the delack algorithm? > Bufferbloat is only bad if the queuing is FIFO-dumb. It's fine to have > lots of queue space if you manage it well. Noted. -- Juliusz From nobody Tue Apr 19 11:42:31 2016 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 E68FA12E317; Tue, 19 Apr 2016 11:42:28 -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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160419184228.31573.7988.idtracker@ietfa.amsl.com> Date: Tue, 19 Apr 2016 11:42:28 -0700 Archived-At: Cc: aqm@ietf.org Subject: [aqm] I-D Action: draft-ietf-aqm-pie-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: Tue, 19 Apr 2016 18:42:29 -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 : PIE: A Lightweight Control Scheme To Address the Bufferbloat Problem Authors : Rong Pan Preethi Natarajan Fred Baker Filename : draft-ietf-aqm-pie-07.txt Pages : 26 Date : 2016-04-19 Abstract: Bufferbloat is a phenomenon where excess buffers in the network cause high latency and jitter. As more and more interactive applications (e.g. voice over IP, real time video streaming and financial transactions) run in the Internet, high latency and jitter degrade application performance. There is a pressing need to design intelligent queue management schemes that can control latency and jitter; and hence provide desirable quality of service to users. This document presents a lightweight active queue management design, called PIE (Proportional Integral controller Enhanced), that can effectively control the average queueing latency to a target value. Simulation results, theoretical analysis and Linux testbed results have shown that PIE can ensure low latency and achieve high link utilization under various congestion situations. The design does not require per-packet timestamp, so it incurs very small overhead and is simple enough to implement in both hardware and software. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-aqm-pie/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-aqm-pie-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-aqm-pie-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 Tue Apr 19 11:44:11 2016 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 7FFC412DC4D for ; Tue, 19 Apr 2016 11:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 bpuHREtX6G2H for ; Tue, 19 Apr 2016 11:44:01 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9689C12D54A for ; Tue, 19 Apr 2016 11:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3576; q=dns/txt; s=iport; t=1461091441; x=1462301041; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=UjTcvfUhlaIb0jrdgZuhs7YfhPxqRHvs5tqz7u1Po14=; b=joUI00ct7vcg+ILHg0qOKdADcbD5dBW2XaBwgLL+6gFm31VNjuKKOm7V PsWF0bTQR+rKpW4wQs/aYYuwBbE/bdQlBaBzpyOssHaWf8ZWhmPVM5Tgs IPMTSuoRHC8ygiS5L4dzMa87HPbTNZRIIUJ2ru4x2MQjnT7/3Gg1N7HUp 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BHAgDmexZX/4QNJK1eDoMqU30GuXABD?= =?us-ascii?q?YFxFw2Fah6BLDgUAQEBAQEBAWUnhEMBAgIBAQEkDToLEgEgBCgEJQsnBAENBR+?= =?us-ascii?q?ICQEOjnOdDwaRdQEBAQEBAQEBAQEBAQEBAQEBAQEXdoUrhnqBVoM0glwFmA4Bj?= =?us-ascii?q?hGBZoROiFyPKgEeAQFCgy07bAGHXjYBfQEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,506,1454976000"; d="scan'208";a="262595835" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Apr 2016 18:44:00 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u3JIi0qH010771 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Apr 2016 18:44:00 GMT Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 19 Apr 2016 13:43:59 -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.1104.009; Tue, 19 Apr 2016 13:44:00 -0500 From: "Rong Pan (ropan)" To: Rasool Al-Saadi , "aqm@ietf.org" Thread-Topic: [aqm] I-D Action: draft-ietf-aqm-pie-07.txt Thread-Index: AQHRmmtv9Z65c3ymc0+z9gB8ORdofQ== Date: Tue, 19 Apr 2016 18:43:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [171.71.130.209] Content-Type: text/plain; charset="euc-kr" Content-ID: <73D0A29491203F40AE030C26DB5F7EE6@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Grenville Armitage Subject: [aqm] I-D Action: draft-ietf-aqm-pie-07.txt 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, 19 Apr 2016 18:44:03 -0000 QSBuZXcgZHJhZnQgaGFzIGJlZW4gcG9zdGVkIHRvIGFkZHJlc3MgdGhpcyBpc3N1ZS4NCg0KVGhh bmtzLA0KDQpSb25nDQoNCk9uIDQvMTMvMTYsIDU6MTcgQU0sICJhcW0gb24gYmVoYWxmIG9mIFJh c29vbCBBbC1TYWFkaSINCjxhcW0tYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgcmFsc2Fh ZGlAc3dpbi5lZHUuYXU+IHdyb3RlOg0KDQo+DQo+T24gVHVlc2RheSwgNSBBcHJpbCAyMDE2LCBS b25nIFBhbiAocm9wYW4pIHdyb3RlOg0KPj4gDQo+PiBSYXNvb2wsDQo+PiANCj4+IFRoYW5rcyBm b3IgeW91ciBkZXRhaWxlZCByZXZpZXcuIFBsZWFzZSBzZWUgdGhlIGNvbW1lbnRzIGJlbG93IGFu ZCBhIG5ldw0KPj4gZHJhZnQgaGFzIGJlZW4gcG9zdGVkLg0KPj4gDQo+PiBSZWdhcmRzLA0KPj4g DQo+PiBSb25nDQo+PiANCj4+ID5Gb3IgbmV3IGRyb3BfcHJvYiBjYWxjdWxhdGlvbiwgaG93IGNh biBkcm9wX3Byb2JfIGJlIGp1c3QgYSBkaXZpc2lvbiBvZg0KPj4gPnF1ZXVlIGxlbmd0aHM/DQo+ PiA+CWRyb3BfcHJvYl8oaSk9cXVldWVfLmJ5dGVfbGVuZ3RoKGkpL21heChxdWV1ZV8uYnl0ZV9s ZW5ndGgoaSkpDQo+PiANCj4+IA0KPj4gPj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4+PlJQOiBMZXSp 9nMgc2F5IHRoZXJlIGFyZSB0d28gZmxvd3MgdGhhdCBhcmUNCj4+ID4+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj5xdWV1ZWQgaW50bw0KPj4gdHdvIHNmcSBxdWV1ZXMuIE9uZSBmbG93IGlzIGFuIGVs ZXBoYW50IGZsb3cgYW5kIG9uZSBmbG93IGlzIG1pY2UgZmxvdy4NCj4+VG90YWwNCj4+IGxhdGVu Y3kgaXMgY2F1c2VkIGJ5IHRoZSBlbGVwaGFudCBmbG93LiBUaGUgYWJvdmUgZXF1YXRpb24gbWFr ZXMgc3VyZQ0KPj50aGF0DQo+PiB0aGUgbWljZSBmbG93ICh3aG9zZSBxdWV1ZSBsZW5ndGggaXMg emVybywgb3IgdmVyeSBzbWFsbCBhbW91bnQpIHdvbqn2dA0KPj5iZQ0KPj4gZHJvcHBlZC4NCj4+ IEJlc2lkZXMsIHNpbmNlIGl0IGlzIG1pY2UgZmxvdywgaXQgd291bGQgYmUgaGFyZCB0byBtZWFz dXJlIGl0cw0KPj5kZXBhcnR1cmUgcmF0ZQ0KPj4gYXMgdGhlIHF1ZXVlIHdvdWxkIG5ldmVyIGJ1 aWxkIHVwLnFkZWxheQ0KPj4gDQo+DQo+VGhhbmsgeW91IGZvciB0aGUgZXhwbGFuYXRpb24uIEkg Zm91bmQgc2VjdGlvbiA0LjYgU0ZRLVBJRSBpbiBbKl0gaXMNCj5jbGVhcmVyIHRoYW4gaW4gdGhl IGRyYWZ0LiBJIGhvcGUgU0ZRIHBhcmFncmFwaCBvZiBQSUUgZHJhZnQgYmVjb21lcyBhDQo+bGl0 dGxlIGNsZWFyZXIuDQo+WypdIA0KPmh0dHA6Ly93d3cuY2FibGVsYWJzLmNvbS93cC1jb250ZW50 L3VwbG9hZHMvMjAxNC8wNi9ET0NTSVMtQVFNX01heTIwMTQucGRmDQo+DQo+PiA+DQo+PiA+NSkg SW4gcGFnZXMgMjMgYW5kIDI0LA0KPj4gPg0KPj4gPj4gICAgICAgLy9JZiB0aGUgcXVldWUgaGFz IGJlZW4gaWRsZSBmb3IgYSB3aGlsZSwgdHVybiBvZmYgUElFDQo+PiA+PiAgICAgICAvL3Jlc2V0 IGNvdW50ZXJzIHdoZW4gYWNjZXNzaW5nIHRoZSBxdWV1ZSBhZnRlciBzb21lIGlkbGUNCj4+ID4+ ICAgICAgIC8vcGVyaW9kIGlmIFBJRSB3YXMgYWN0aXZlIGJlZm9yZQ0KPj4gPj4gICAgICAgaWYg KCBQSUUtPmRyb3BfcHJvYl8gPT0gMCAmJiBQSUUtPnFkZWxheV9vbGRfID09IDANCj4+ID4+ICAg ICAgICAgICAgJiYgcXVldWVfLmJ5dGVfbGVuZ3RoKCkgPT0gMCkgew0KPj4gPj4gICAgICAgICAg ICBQSUUtPmFjdGl2ZV8gPSBJTkFDVElWRTsNCj4+ID4NCj4+ID5BY2NvcmRpbmcgdG8gc2VjdGlv biA1LjMgKFR1cm5pbmcgUElFIG9uIGFuZCBvZmYpLCB0aGUgY29uZGl0aW9uIG9mDQo+PiA+ZGVh Y3RpdmF0aW5nIFBJRSBzaG91bGQgYmU6DQo+PiA+DQo+PiA+aWYgKFBJRS0+ZHJvcF9wcm9iXyA9 PSAwIGFuZCBjdXJyZW50X3FkZWxheSA8IFFERUxBWV9SRUYvMiBhbmQNCj4+ID4gICAgICBQSUUt PnFkZWxheV9vbGRfIDwgUURFTEFZX1JFRi8yKSB7DQo+PiANCj4+IA0KPj4gPj4+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj5SUDogRml4ZWQuDQo+PiANCj4NCj5JIGFtIHVuc3VyZSB3aGV0aGVyIHNl Y3Rpb24gNS4zIGlzIGNvcnJlY3Qgb3IgdGhlIG9sZCBjb2RlIChpbg0KPmRyYWZ0LWlldGYtYXFt LXBpZS0wNS50eHQpIHdpdGggcXVldWVfLmJ5dGVfbGVuZ3RoKCkgPT0gMCB3YXMgY29ycmVjdC4g SW4NCj5teSBQSUUgaW1wbGVtZW50YXRpb24sIEkgZm91bmQgdGhhdCB3aXRob3V0IHVzaW5nIHF1 ZXVlXy5ieXRlX2xlbmd0aCgpID09DQo+MCwgIFBJRSB0dXJucyBvZmYgYWZ0ZXIgYSB2ZXJ5IHNo b3J0IHBlcmlvZCBhbmQgY2F1c2VzIHF1ZXVlIGRlbGF5IHRvDQo+YmVjb21lIHVuY29udHJvbGxl ZCB1bnRpbCBxdWV1ZSBsZW5ndGggZXhjZWVkcyAxLzMgZHJvcC10YWlsIHNpemUuIEkgcHV0DQo+ cXVldWVfLmJ5dGVfbGVuZ3RoKCkgPT0gMCBjb25kaXRpb24gYW5kIEkgZ290IGJldHRlciByZXN1 bHRzLg0KPg0KPlJlZ2FyZHMsDQo+UmFzb29sDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj5hcW0gbWFpbGluZyBsaXN0DQo+YXFtQGlldGYub3Jn DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcW0NCg0K From nobody Wed Apr 20 05:47:13 2016 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 4B36412EEC3; Wed, 20 Apr 2016 05:47:13 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160420124713.32376.24588.idtracker@ietfa.amsl.com> Date: Wed, 20 Apr 2016 05:47:13 -0700 Archived-At: Cc: wes@mti-systems.com, ietf@kuehlewind.net, aqm-chairs@ietf.org, draft-ietf-aqm-eval-guidelines@ietf.org, aqm@ietf.org Subject: [aqm] Last Call: (AQM Characterization Guidelines) to Informational 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: Wed, 20 Apr 2016 12:47:13 -0000 The IESG has received a request from the Active Queue Management and Packet Scheduling WG (aqm) to consider the following document: - 'AQM Characterization Guidelines' as Informational 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 2016-05-04. 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 Unmanaged large buffers in today's networks have given rise to a slew of performance issues. These performance issues can be addressed by some form of Active Queue Management (AQM) mechanism, optionally in combination with a packet scheduling scheme such as fair queuing. This document describes various criteria for performing precautionary characterizations of AQM schemes. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-aqm-eval-guidelines/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-aqm-eval-guidelines/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Apr 20 05:48:30 2016 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 CC76B12D52B; Wed, 20 Apr 2016 05:48:27 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160420124827.32404.34008.idtracker@ietfa.amsl.com> Date: Wed, 20 Apr 2016 05:48:27 -0700 Archived-At: Cc: Wesley Eddy , draft-ietf-aqm-pie@ietf.org, ietf@kuehlewind.net, aqm-chairs@ietf.org, aqm@ietf.org Subject: [aqm] Last Call: (PIE: A Lightweight Control Scheme To Address the Bufferbloat Problem) 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: Wed, 20 Apr 2016 12:48:28 -0000 The IESG has received a request from the Active Queue Management and Packet Scheduling WG (aqm) to consider the following document: - 'PIE: A Lightweight Control Scheme To Address the Bufferbloat Problem' 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 2016-05-04. 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 Bufferbloat is a phenomenon where excess buffers in the network cause high latency and jitter. As more and more interactive applications (e.g. voice over IP, real time video streaming and financial transactions) run in the Internet, high latency and jitter degrade application performance. There is a pressing need to design intelligent queue management schemes that can control latency and jitter; and hence provide desirable quality of service to users. This document presents a lightweight active queue management design, called PIE (Proportional Integral controller Enhanced), that can effectively control the average queueing latency to a target value. Simulation results, theoretical analysis and Linux testbed results have shown that PIE can ensure low latency and achieve high link utilization under various congestion situations. The design does not require per-packet timestamp, so it incurs very small overhead and is simple enough to implement in both hardware and software. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-aqm-pie/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-aqm-pie/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2540/ https://datatracker.ietf.org/ipr/2123/ https://datatracker.ietf.org/ipr/2187/ From nobody Wed Apr 27 13:06:24 2016 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 6F66312DC1E for ; Wed, 27 Apr 2016 13:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_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 ud8SDkQCNn3c for ; Wed, 27 Apr 2016 13:06:22 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 162E712DC0D for ; Wed, 27 Apr 2016 13:06:22 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id v145so28244902oie.0 for ; Wed, 27 Apr 2016 13:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to :content-transfer-encoding; bh=X9ecrtp4zRexehtoy9WIPlr9/iQf6mpQeCWQLBGswy8=; b=f7bG6oLswDNKDeNOq6YrTeluXn2BAaXRTwwyPk/K8dORVBawX6XcYntHet/ciuCun3 QYVfg20V2NNcjr7ulJWvvbu0QPXfXuGOxn8E2VxuvNkNsvumIBzc6oefwaWPKusl8lsW vrlm6ntXl4rBj3nTG8iHtkcTkE+KLogp0pTph9IYbDug2LXF/vtBpx/m0V9KxUQ0FMSw nKtw4syyCZBWlvIisLKvODEgdHs8LxvKiOnGNpEKsTC+sDXtq6kd3/iwvGjh2LWRzXF2 odokUOqUdnGssoKRa1SsidIeiPPdfvmCH8s7qhjwJJGTfZ6QG+9wA8fLe6mRl8qWU8pt B4Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-transfer-encoding; bh=X9ecrtp4zRexehtoy9WIPlr9/iQf6mpQeCWQLBGswy8=; b=eB/4zIgY+iinDA9kZVRo5AGDs4JuKx6w/TCIgXP8m+Yl/wNB4xbgAtFHnShLok8l8v A8z65IdnawoKzurBO+Ozrtdp46rCxPgxc4fI22U9LXpPCw5BWE7wDrArokGXT5jKkDbG vDvsjv4iZquEgReXptFVhnxJMuctkocxbhZKsT88HMZwqF6UbkEL2ktPbHMomw48Sm5S uKZ9Z4qsGLrdsjn4ueGvB6Josdr6aQgjfqP2KeCKXHlnLH0KAjZsTbN3Q6mcbrnd0q6e VMPuGgZcCor28pgnJQxlyun8JMUiTKazUVqqNZ6VjxXjgczD8vKJSNesvc1XL1OqBKaM BavA== X-Gm-Message-State: AOPr4FVMOcqMaU+nsc2p3EYx8uIB9AJ9cqVzdQb9lJWGpfxe8IeXPMBzk7FW5pn+QVc1FgDWrkQAShBjCAlp6w== MIME-Version: 1.0 X-Received: by 10.202.217.67 with SMTP id q64mr4398079oig.151.1461787581305; Wed, 27 Apr 2016 13:06:21 -0700 (PDT) Received: by 10.202.78.23 with HTTP; Wed, 27 Apr 2016 13:06:21 -0700 (PDT) Date: Wed, 27 Apr 2016 13:06:21 -0700 Message-ID: From: Dave Taht To: bloat , "codel@lists.bufferbloat.net" , "aqm@ietf.org" , flent-devel@flent.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [aqm] some fq_codel on bsd results using flent 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: Wed, 27 Apr 2016 20:06:23 -0000 https://github.com/opnsense/core/issues/505 --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org From nobody Thu Apr 28 07:13:24 2016 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 E758412D7AA; Thu, 28 Apr 2016 07:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] 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 t3Y3dNh_nF79; Thu, 28 Apr 2016 07:13:20 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1289912D5B8; Thu, 28 Apr 2016 07:13:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 9A8ACD9307; Thu, 28 Apr 2016 16:13:14 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Ndhk8aAQ+dI3; Thu, 28 Apr 2016 16:13:14 +0200 (MEST) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 46117D9305; Thu, 28 Apr 2016 16:13:14 +0200 (MEST) To: The IESG , IETF-Announce , rfc-editor@rfc-editor.org References: <20160403140511.28266.40543.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <57221A7A.7020005@tik.ee.ethz.ch> Date: Thu, 28 Apr 2016 16:13:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160403140511.28266.40543.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-aqm-fq-codel@ietf.org, wes@mti-systems.com, aqm-chairs@ietf.org, mls.ietf@gmail.com, The IESG , aqm@ietf.org Subject: Re: [aqm] Document Action: 'The FlowQueue-CoDel Packet Scheduler and Active Queue Management Algorithm' to Experimental RFC (draft-ietf-aqm-fq-codel-06.txt) 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: Thu, 28 Apr 2016 14:13:23 -0000 Dear RFC Editor, based on discussion in the last call of this doc, there are two editorial changes that need to be applied with the AUTH48 for this document and that were missed in the announcement. Please apply the following changes: CURRENT: "It is a powerful tool for solving bufferbloat [BLOAT], and we believe it to be safe to turn on by default, as has already happened in a number of Linux distributions.“ NEW: "It is a powerful tool for solving bufferbloat [BLOAT], and has already been turned on by default in a number of Linux distributions.“ and CURRENT: "We believe it to be a safe default and encourage people running Linux to turn it on: It is a massive improvement over the previous default FIFO queue.“ NEW: "In addition, a BSD implementation is available. All data resulting from these trials has shown FQ-CoDel to be a massive improvement over the previous default FIFO queue, and people are encouraged to turn it on." Thanks, Mirja On 03.04.2016 16:05, The IESG wrote: > The IESG has approved the following document: > - 'The FlowQueue-CoDel Packet Scheduler and Active Queue Management > Algorithm' > (draft-ietf-aqm-fq-codel-06.txt) as Experimental RFC > > This document is the product of the Active Queue Management and Packet > Scheduling Working Group. > > The IESG contact persons are Spencer Dawkins and Martin Stiemerling. > > A URL of this Internet Draft is: > https://datatracker.ietf.org/doc/draft-ietf-aqm-fq-codel/ > > > > > > Technical Summary > > This memo presents the FQ-CoDel hybrid packet scheduler/AQM > algorithm, a powerful tool for fighting bufferbloat and reducing > latency. > > FQ-CoDel mixes packets from multiple flows and reduces the impact of > head of line blocking from bursty traffic. It provides isolation for > low-rate traffic such as DNS, web, and videoconferencing traffic. It > improves utilisation across the networking fabric, especially for > bidirectional traffic, by keeping queue lengths short; and it can be > implemented in a memory- and CPU-efficient fashion across a wide > range of hardware. > > Working Group Summary > > An interesting aspect of this document is the combined use of CoDel with > FQ for improving flow-isolation properties. The working group had early > discussions about the differences between FQ and scheduling mechanisms > versus more pure AQM algorithms (like CoDel). This resulted in draft- > ietf-aqm-fq-implementation, which describes the terminology and > construction of hybrid systems. Any early disagreement in the WG about > this seems to have subsided after the subsequent discussions and work to > resolve terminology and scope. > > Document Quality > > Yes, there are existing implementations and deployments, including in > the Linux kernel. There have been other implementation efforts in > addition to the editors, and questions have been shared on the AQM > mailing list, with clarifications posted in draft updates. The Linux > implementation is from the editors of the document, and an independent > implementation in FreeBSD was done by Rasool As-Saadi at the Swinburne > University. > > > Personnel > > Wes Eddy (wes@mti-systems.com) is the Document Shepherd. Martin > Stiemerling is the responsible AD. > > > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > From nobody Thu Apr 28 08:13:26 2016 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 616EF12D7F5 for ; Thu, 28 Apr 2016 08:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_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 eg8XN-DQcdcD for ; Thu, 28 Apr 2016 08:13:02 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 CE56A12D833 for ; Thu, 28 Apr 2016 08:13:01 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id x19so86757610oix.2 for ; Thu, 28 Apr 2016 08:13:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to :content-transfer-encoding; bh=mhNT/5p7aQ/UkpkHherlmShly8WbuDP0L/LMq5CPCco=; b=jmJBskWq8eSq9bv/bTeFbiWfxBEOHzDy5FVSR5NhRtzZVCzt+M0wBvjHHASRhDaq2S DD5/V3YUabAIy8aaUCYoQ3oqC8S0HwHKvuthvSZM/A6Lsy88zWEhQjNd/rTY3FvYshdK dSrFq7Q85qd0qW/rf11fUF4wR/bNO2JGaF6qSAM8htbK4Gn81Q7bTo6Hl16zzLlNVxA1 sRmZPWD/oy7XJovTTc7bdY050209mXX1oqUBSabEVsY4G32CzPM+ajsLIdnXPEBIpocD Z5AD3WrAt98l3HXkw3tVWJcBlrq40nZ9GNBZDSIdVYyn4k7ZJC0CJ2WNgs3Qh24OhxO6 00Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-transfer-encoding; bh=mhNT/5p7aQ/UkpkHherlmShly8WbuDP0L/LMq5CPCco=; b=adu/IgI1FFmPOBUekSraQ1NiFDlxYylhOFJm9RKAkYaVCrybRJg2tKCOLlyjvaENv9 nlRYGYte0+bi5WFk7kjmoUOdCAwt/qMEYze7s5PtgADnt6UmDRn+aFE8733+U05yk1KT MJDsOlRZjMtolANzepqD7ArrrPdZzHlssgGbDdDDaEq5ZfmZqLMAwwydCL9m3JwNa+OB 17RuZ3JRDKwoQIZ6nAZ8riz9v/sMxcvXsDkrGQ3+ejrWgUTz84TtTSh557eWdPhBBuLP xs8iRSIxVa9qpUqU/ABv6bi/6nCg1blmgg+47jP382NoLE5EiExA+7sv2V/GqfrUB7Ls jW/g== X-Gm-Message-State: AOPr4FU7De3u+2mpfBat86BkG5ZmzoUNXdH8fTnY/Yt1p6l+YCfCfKMQJdgPAIEVUrcnjLvoWhETkx/vTgJ1ag== MIME-Version: 1.0 X-Received: by 10.202.217.67 with SMTP id q64mr6761384oig.151.1461856381146; Thu, 28 Apr 2016 08:13:01 -0700 (PDT) Received: by 10.202.78.23 with HTTP; Thu, 28 Apr 2016 08:13:01 -0700 (PDT) Date: Thu, 28 Apr 2016 08:13:01 -0700 Message-ID: From: Dave Taht To: "codel@lists.bufferbloat.net" , "aqm@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [aqm] ns3: FQ-CoDel queue disc (issue 293290043 by p.imputato@gmail.com) 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: Thu, 28 Apr 2016 15:13:13 -0000 If anyone would like to take the ns3 models for a spin again... do some code review... Also in the ns3 queue for review is pie. ---------- Forwarded message ---------- From: Date: Thu, Apr 28, 2016 at 12:57 AM Subject: Re: FQ-CoDel queue disc (issue 293290043 by p.imputato@gmail.com) On 2016/04/27 23:23:51, dave.taht wrote: > > I am happy to see this re-re-landing again. Yeah, I am confident this time it will land for real :-) > If there is a tree I can pull from > more directly, that would be great. Sure, you can git clone from here: https://github.com/pasquimp/ns-3-dev-git.git and then git checkout -b fq-codel-new --track origin/fq-codel-new or have a look at the commits via the web interface: https://github.com/pasquimp/ns-3-dev-git/commits/fq-codel-new Looking forward to feedbacks and comments. https://codereview.appspot.com/293290043/ --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org From nobody Fri Apr 29 10:02:30 2016 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 9503012D5D4; Fri, 29 Apr 2016 10:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 xPZd7GrVzAkd; Fri, 29 Apr 2016 10:02:22 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0126.outbound.protection.outlook.com [23.103.201.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAB7212D1DB; Fri, 29 Apr 2016 10:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ubYBtPu+RyDvqR8xa2cD9NL9LoEFeSLTLkQ52kwa4A8=; b=Cob4qCgsd+bhTW6JnslOkbdCMrLkc5pMzVoq6ZvWXncuUnQuTKvxbSuaoB+W2yh+tGPwt0Dr9366Umv7KAcR94jM/5lQTsdzUBTy1zmv2gWBX4QfaSwKlbyBCnDyCEXhKyygbARtJBriVnTTXZbpQtxZ5cLeAf5UCUEe+SONrfk= Received: from BL2PR09MB1123.namprd09.prod.outlook.com (10.167.102.151) by BL2PR09MB1122.namprd09.prod.outlook.com (10.167.102.150) with Microsoft SMTP Server (TLS) id 15.1.477.8; Fri, 29 Apr 2016 17:02:20 +0000 Received: from BL2PR09MB1123.namprd09.prod.outlook.com ([10.167.102.151]) by BL2PR09MB1123.namprd09.prod.outlook.com ([10.167.102.151]) with mapi id 15.01.0477.014; Fri, 29 Apr 2016 17:02:20 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Pete Resnick , General Area Review Team , "aqm@ietf.org" , "draft-ietf-grow-route-leak-problem-definition.all@ietf.org" Thread-Topic: Gen-ART LC review of draft-ietf-grow-route-leak-problem-definition-04 Thread-Index: AQHRg46sqs2z5cVocUuanFE+kRzqCp+hZ9kw Date: Fri, 29 Apr 2016 17:02:19 +0000 Message-ID: References: <41136C0E-1BA9-4855-B084-618DED1B9257@qti.qualcomm.com> In-Reply-To: <41136C0E-1BA9-4855-B084-618DED1B9257@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: qti.qualcomm.com; dkim=none (message not signed) header.d=none;qti.qualcomm.com; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.108.229] x-ms-office365-filtering-correlation-id: 06fe7820-ae46-4403-6cfd-08d3705006ae x-microsoft-exchange-diagnostics: 1; BL2PR09MB1122; 5:RCa7yns1WFQ4lKKZkv4tLwwGIc85rHqNMDoB9RgYcIcM6FZ/ICf0p3mZPmOGn0wVHNyO5niVs+dBB99gf2FqOM6MP5Xv5mPUTLAFcx1IjZKSeojs7L0dePZAnoEsb8rS0ZCtOrHqr8WlcSxNWXG5mg==; 24:kHb0GN8fGDo8wyGSaNUyV5AY2lu+LF0LxCze8iggfcNoyRmr9ZQlt4P52irxxdDfrb34MYh9ZHrSDEO36NV+JtlJbAnV1uc+Fnl4PHntxM0=; 7:Yd7GLui1+swP89PvyZtDGcIqrhXuPl/iDbcvjxK9AS5fIaIasdAUjggiyi9zy6PgP2bpwb10p0Q4s0Mmqox01QKOpshVjceoKNjBPAAao63JvUbAGFKGvkZm0KcGNHttXGh+ICyPCi87rvIwNT4zxheIsWkKRodaqLzv7o1Kn4h+SkqUN8wQ73bafOeP1HmV x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR09MB1122; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521072)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:BL2PR09MB1122; BCL:0; PCL:0; RULEID:; SRVR:BL2PR09MB1122; x-forefront-prvs: 0927AA37C7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377424004)(45984002)(377454003)(19617315012)(5002640100001)(189998001)(5001770100001)(107886002)(5003600100002)(76176999)(54356999)(5008740100001)(50986999)(10400500002)(790700001)(16236675004)(102836003)(6116002)(2906002)(74316001)(1096002)(1220700001)(3846002)(81166005)(3660700001)(2201001)(230783001)(19609705001)(3280700002)(76576001)(92566002)(19580405001)(19300405004)(5004730100002)(19580395003)(586003)(106116001)(33656002)(2501003)(66066001)(11100500001)(15975445007)(2900100001)(77096005)(87936001)(2950100001)(9686002)(19625215002)(86362001)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR09MB1122; H:BL2PR09MB1123.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL2PR09MB11235603102909B6FD6ECBE084660BL2PR09MB1123namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2016 17:02:19.7723 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR09MB1122 Archived-At: Subject: Re: [aqm] Gen-ART LC review of draft-ietf-grow-route-leak-problem-definition-04 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, 29 Apr 2016 17:02:26 -0000 --_000_BL2PR09MB11235603102909B6FD6ECBE084660BL2PR09MB1123namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pete, Thank you very much for your careful reading and the detailed comments/sugg= estions. I found them all very helpful, and the new version (-05) that I just upload= ed incorporates the changes you've recommended. Please take a look and let me know if I mis= sed anything important. https://tools.ietf.org/html/draft-ietf-grow-route-leak-problem-definition-0= 5 (new version) https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-grow-route-leak-problem-defi= nition-05 (diff) Sriram From: Pete Resnick [mailto:presnick@qti.qualcomm.com] Sent: Monday, March 21, 2016 12:28 PM To: General Area Review Team ; aqm@ietf.org; draft-ietf-g= row-route-leak-problem-definition.all@ietf.org; IETF discussion list Subject: Gen-ART LC review of draft-ietf-grow-route-leak-problem-definition= -04 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 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Document: draft-ietf-grow-route-leak-problem-definition-04 Reviewer: Pete Resnick Review Date: 2016-03-21 IETF LC End Date: 2016-03-28 Summary: This draft is on the right track but has open issues, described in= this review. Major issues: None. Minor issues: * Figure 1, along with the discussion of it in section 3, was confusi= ng to me. First of all, am I correct that the example displays two leaks? T= hat is, there's the leak from AS3 to ISP2, and then there are the propagate= d leaks from ISP2 to the rest of the world. Also, "(P)" seems to be used as= both a leaked prefix (from ISP1 through AS3 to ISP2 and then propagated fr= om there) as well as what looks to be a normal prefix update between ISP1 a= nd ISP2. Are all of the occurrences of "(P)" in Figure 1 identical? Or is t= he prefix update between ISP1 and ISP2 also a leak? What leaks is Figure 1 = intended to show? * In 3.1: "The leak often succeeds because...". Do you really means "= succeeds" and not "occurs"? If so, what does "succeeds" mean in this contex= t? * The description in section 3.5, starting from "However", really nee= ds a complete rewrite. It's ungrammatical to the point that I'm not really = sure I understand what it is trying to say. Nits/editorial comments: * I've mentioned before that I find the "academic research paper" sty= le a bit jarring in IETF documents. I particularly don't like the use of "w= e" and "us", since it's not clear whether "we" is the authors (which is how= it's used in academic papers, but is inappropriate for an IETF document), = the WG, the IETF, etc. Instead, I would replace all instances of "we" with = "this document", or simply re-word into the passive, since a subject is rar= ely needed for these sentences. For example, the abstract could be rewritte= n as such: A systemic vulnerability of the Border Gateway Protocol routing system, known as 'route leaks', has received significant attention in recent years. Frequent incidents that result in significant disruptions to Internet routing are labeled "route leaks", but to date a common definition of the term has been lacking. This document provides a working definition of route leaks, keeping in mind the real occurrences that have received significant attention. Further, this document attempts to enumerate (though not exhaustively) different types of route leaks based on observed events on the Internet. The aim is to provide a taxonomy that covers several forms of route leaks that have been observed and are of concern to Internet user community as well as the network operator community. Please do similar edits throughout. Similarly, the referencing of authors by name seems like bad form for an IE= TF document. OLD This document builds on and extends earlier work in the IETF by Dickson [draft-dickson-sidr-route-leak-def][draft-dickson-sidr-route- leak-reqts]. NEW This document builds on and extends earlier work in the IETF [draft-dickson-sidr-route-leak-def][draft-dickson-sidr-route-leak- reqts]. END OLD Mauch [Mauch] observes that these are anomalies and potentially route leaks because very large ISPs such as ATT, Sprint, Verizon, and Globalcrossing do not in general buy transit services from each other. However, he also notes that there are exceptions when one very large ISP does indeed buy transit from another very large ISP, and accordingly exceptions are made in his detection algorithm for known cases. NEW [Mauch] observes that these are anomalies and potentially route leaks because very large ISPs such as ATT, Sprint, Verizon, and Globalcrossing do not in general buy transit services from each other. However, it also notes that there are exceptions when one very large ISP does indeed buy transit from another very large ISP, and accordingly exceptions are made in its detection algorithm for known cases. END * Last paragraph in section 2: I'm left wondering what sorts of thing= s that other folks might consider leaks aren't covered by the definition. P= erhaps you want to mention that? * In 3.6, when you say "more specifics", are you using that as a noun= to mean "more specific prefixes"? It's very hard to read in its current fo= rm. * Section 5 is superfluous. I'd delete it. * On a side note, I must say that the writing style of the "Example i= ncidents" caused me quite a bit of giggling. "Examples include symmetrical = book stacking, just like the Philadelphia mass turbulence of 1947, and the = biggest interdimensional crossrip since the Tunguska blast of 1909 [GhostBu= sters1984]." Reading them aloud helps. :-) (No need for a change; they're f= ine as is. They just sound funny to a person not in the field.) pr -- Pete Resnick http://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478 --_000_BL2PR09MB11235603102909B6FD6ECBE084660BL2PR09MB1123namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Pete,

 

Thank you very much for your careful = reading and the detailed comments/suggestions.

I found them all very helpful, and th= e new version (-05) that I just uploaded incorporates

the changes you’ve recommended.= Please take a look and let me know if I missed anything important.

 

https://tools.ietf.org/= html/draft-ietf-grow-route-leak-problem-definition-05   (new version)

https://www.iet= f.org/rfcdiff?url2=3Ddraft-ietf-grow-route-leak-problem-definition-05   (diff)

 

Sriram

 

 

From: Pete Resnick [mailto:presnick@= qti.qualcomm.com]
Sent: Monday, March 21, 2016 12:28 PM
To: General Area Review Team <gen-art@ietf.org>; aqm@ietf.org;= draft-ietf-grow-route-leak-problem-definition.all@ietf.org; IETF discussio= n list <ietf@ietf.org>
Subject: Gen-ART LC review of draft-ietf-grow-route-leak-problem-def= inition-04

 

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

http= ://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Document: draft-ietf-grow-route-leak-problem-definition-04
Reviewer: Pete Resnick
Review Date: 2016-03-21
IETF LC End Date: 2016-03-28

Summary: This draft is on the right track but has open issues, described= in this review.

Major issues:

None.

Minor issues:

·       Figure 1, along with the discussion of it in= section 3, was confusing to me. First of all, am I correct that the exampl= e displays two leaks? That is, there's the leak from AS3 to ISP2, and then th= ere are the propagated leaks from ISP2 to the rest of the world. Also, &quo= t;(P)" seems to be used as both a leaked prefix (from ISP1 through AS3= to ISP2 and then propagated from there) as well as what looks to be a normal prefix update between ISP1 and ISP2. Are= all of the occurrences of "(P)" in Figure 1 identical? Or is the= prefix update between ISP1 and ISP2 also a leak? What leaks is Figure 1 in= tended to show?

·       In 3.1: "The leak often succeeds becaus= e...". Do you really means "succeeds" and not "occurs&q= uot;? If so, what does "succeeds" mean in this context?

·       The description in section 3.5, starting fro= m "However", really needs a complete rewrite. It's ungrammatical = to the point that I'm not really sure I understand what it is trying to say= .

Nits/editorial comments:

·       I've mentioned before that I find the "= academic research paper" style a bit jarring in IETF documents. I part= icularly don't like the use of "we" and "us", since it'= s not clear whether "we" is the authors (which is how it's used in academic papers, but is inappropriate for an IETF document), the WG, th= e IETF, etc. Instead, I would replace all instances of "we" with = "this document", or simply re-word into the passive, since a subj= ect is rarely needed for these sentences. For example, the abstract could be rewritten as such:

A systemic vulnerability of the Border Gatewa= y Protocol routing
system, known as 'route leaks', has received significant attention in
recent years. Frequent incidents that result in significant
disruptions to Internet routing are labeled "route leaks", but to=
date a common definition of the term has been lacking. This document
provides a working definition of route leaks, keeping in mind the
real occurrences that have received significant attention. Further,
this document attempts to enumerate (though not exhaustively)
different types of route leaks based on observed events on the
Internet. The aim is to provide a taxonomy that covers several forms
of route leaks that have been observed and are of concern to Internet
user community as well as the network operator community.

Please do similar edits throughout.

Similarly, the referencing of authors by name seems like bad form for an= IETF document.

OLD
This document builds on and extends earlier work in the IETF by
Dickson [draft-dickson-sidr-route-leak-def][draft-dickson-sidr-route-
leak-reqts].
NEW
This document builds on and extends earlier work in the IETF
[draft-dickson-sidr-route-leak-def][draft-dickson-sidr-route-leak-
reqts].
END

OLD
Mauch [Mauch] observes that these are
anomalies and potentially route leaks because very large ISPs such
as ATT, Sprint, Verizon, and Globalcrossing do not in general buy
transit services from each other. However, he also notes that
there are exceptions when one very large ISP does indeed buy
transit from another very large ISP, and accordingly exceptions
are made in his detection algorithm for known cases.
NEW
[Mauch] observes that these are anomalies
and potentially route leaks because very large ISPs such as ATT,
Sprint, Verizon, and Globalcrossing do not in general buy transit
services from each other. However, it also notes that there are
exceptions when one very large ISP does indeed buy transit from
another very large ISP, and accordingly exceptions are made in its
detection algorithm for known cases.
END

·       Last paragraph in section 2: I'm left wonder= ing what sorts of things that other folks might consider leaks aren't covered by the definition. Perhaps you want to mention that= ?

·       In 3.6, when you say "more specifics&qu= ot;, are you using that as a noun to mean "more specific prefixes"= ;? It's very hard to read in its current form.

·       Section 5 is superfluous. I'd delete it.

·       On a side note, I must say that the writing = style of the "Example incidents" caused me quite a bit of gigglin= g. "Examples include symmetrical book stacking, just like the Philadel= phia mass turbulence of 1947, and the biggest interdimensional crossrip since the Tunguska blast of 1909 [GhostBusters1984]." Readin= g them aloud helps. :-) (No need for a change; they're fine as is. They jus= t sound funny to a person not in the field.)

pr
--
Pete Resnick http://www.qu= alcomm.com/~presnick/
Qualcomm Technologies, Inc. - +1 (858)651-4478

--_000_BL2PR09MB11235603102909B6FD6ECBE084660BL2PR09MB1123namp_--