From nobody Fri Feb 19 05:28:26 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECD51B2EC2; Fri, 19 Feb 2016 05:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 W3tu7sovRIWN; Fri, 19 Feb 2016 05:28:15 -0800 (PST) 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 5ACBD1B2B1C; Fri, 19 Feb 2016 05:28:12 -0800 (PST) Received: from 154.236.199.146.dyn.plus.net ([146.199.236.154]:56076 helo=[192.168.0.3]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1aWl6Q-00075F-14; Fri, 19 Feb 2016 13:28:10 +0000 To: tcpm IETF list , tsvwg IETF list , AQM IETF list , TCP Prague List From: Bob Briscoe Message-ID: <56C71869.9080503@bobbriscoe.net> Date: Fri, 19 Feb 2016 13:28:09 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------090006030305010904050805" 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: "De Schepper, Koen \(Koen\)" Subject: [tcpPrague] (Bar) BoF @IETF-95 'Ultra-Low Queuing Delay for All' (L4S, DualQ Coupled AQM, TCP Prague)? X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 13:28:18 -0000 This is a multi-part message in MIME format. --------------090006030305010904050805 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Folks, 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. If you don't know what all these buzzwords mean, pls read 'Background' at the end first. If you don't know what a Bar BoF is, see https://www.ietf.org/tao.html At least two purposes: i) Updates so everyone can see progress on design, implementation, evaluation, specification of the different parts, who is working on what etc. Note: You might be working on, say, an improvement to DCTCP without being motivated by all this L4S stuff, but it might be relevant. ii) To discuss how best to standardise all the different parts iii) Anything else? Perhaps interop testing, but it's probably too early for that Shout now, if you think this should be a real BoF, not just a Bar BoF, cos the deadline for BoF proposals is about 11 hrs from now: UTC 23:59 2016-02-19 (Friday). Also shout - either on or off list - if you have something relevant you would like to present at item (i) Regarding item (ii) on how best to standardise all this, we've been talking with the Transport ADs and relevant WG chairs, and there are two possible routes forward: * Proposal #1: Standardise the pieces in their relevant existing WGs. Ie: - the IP packet identifier for the L4S service in tsvwg, e.g. > - the AQM mechanism in the aqm wg, e.g. > - The essential TCP Prague requirements in the tcpm wg (the essential requirements happen to all be applicable to regular TCP congestion avoidance as well) - The 'optional' TCP Prague requirements (performance improvements) in perhaps the IRTF iccrg or tcpm, whichever is most appropriate. * Proposal #2: A new WG to do all the above. Discuss! *Background** *Back in July'15, at the IETF AQM wg in Prague, we presented the DualQ Coupled AQM. > And we demonstrated it later that week at IETF bits-n-bites exhibition. The message is, once you partition off the queuing delay of 'Classic' TCP congestion control (Reno, Cubic, etc), it's really easy to get ultra-low queueing delay with the family of TCPs that includes Data Center TCP (DCTCP). The DCTCP family is more aggressive, so normally they would starve a Classic TCP flow. This coexistence problem is why it hasn't so far been possible to release DCTCP on the public Internet. The DualQ solves this coexistence problem. it is like a semi-permeable membrane: it partitions delay, but flows share bandwidth across the divide as if they are all the same type of TCP. So, as a fortunate side-effect, DualQ also solves the problem of scaling TCP throughput long term. {Note 1} We are proposing that senders will identify packets for this new L4S queue with the ECT(1) codepoint. > We call the service offered by this new queue 'L4S' for 'Low Delay, Low Loss, Scalable throughput' DCTCP works OK as it is, but it will need some safety features. There was a lot of energy in an ad hoc session in Prague back last July, which produced a prioritised list, including performance improvements (see TCP Prague Requirements ) but then everyonr went home, went on summer holidays, returned to their day jobs and it all went quiet... If you missed all the above, we've pulled together videos of demos, short papers, I-Ds etc here: https://riteproject.eu/dctth/ Incuding this particularly useful 2-pager: “Ultra-Low Delay for All ” IETF Journal, Nov 2015. Cheers Bob Briscoe & Koen De Schepper {Note 1} As the window scales, the number of congestion signals per RTT remains the same, whereas with classic TCPs it gets smaller. -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------090006030305010904050805 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Folks,

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.

If you don't know what all these buzzwords mean, pls read 'Background' at the end first.
If you don't know what a Bar BoF is, see https://www.ietf.org/tao.html

At least two purposes:
i) Updates so everyone can see progress on design, implementation, evaluation, specification of the different parts, who is working on what etc.
   Note: You might be working on, say, an improvement to DCTCP without being motivated by all this L4S stuff, but it might be relevant.
ii) To discuss how best to standardise all the different parts
iii) Anything else? Perhaps interop testing, but it's probably too early for that

Shout now, if you think this should be a real BoF, not just a Bar BoF, cos the deadline for BoF proposals is about 11 hrs from now: UTC 23:59 2016-02-19 (Friday).
Also shout - either on or off list - if you have something relevant you would like to present at item (i)

Regarding item (ii) on how best to standardise all this, we've been talking with the Transport ADs and relevant WG chairs, and there are two possible routes forward:
* Proposal #1: Standardise the pieces in their relevant existing WGs. Ie:
  - the IP packet identifier for the L4S service in tsvwg, e.g. <draft-briscoe-tsvwg-ecn-l4s-id>
  - the AQM mechanism in the aqm wg, e.g. <draft-briscoe-aqm-dualq-coupled>
  - The essential TCP Prague requirements in the tcpm wg (the essential requirements happen to all be applicable to regular TCP congestion avoidance as well)
  - The 'optional' TCP Prague requirements (performance improvements) in perhaps the IRTF iccrg or tcpm, whichever is most appropriate.
* Proposal #2: A new WG to do all the above.

Discuss!


Background
Back in July'15, at the IETF AQM wg in Prague, we presented the DualQ Coupled AQM. <draft-briscoe-aqm-dualq-coupled>
And we demonstrated it later that week at IETF bits-n-bites exhibition.

The message is, once you partition off the queuing delay of 'Classic' TCP congestion control (Reno, Cubic, etc), it's really easy to get ultra-low queueing delay with the family of TCPs that includes Data Center TCP (DCTCP).

The DCTCP family is more aggressive, so normally they would starve a Classic TCP flow. This coexistence problem is why it hasn't so far been possible to release DCTCP on the public Internet.
The DualQ solves this coexistence problem. it is like a semi-permeable membrane: it partitions delay, but flows share bandwidth across the divide as if they are all the same type of TCP.
So, as a fortunate side-effect, DualQ also solves the problem of scaling TCP throughput long term. {Note 1}

We are proposing that senders will identify packets for this new L4S queue with the ECT(1) codepoint. <draft-briscoe-tsvwg-ecn-l4s-id>
We call the service offered by this new queue 'L4S' for 'Low Delay, Low Loss, Scalable throughput'
DCTCP works OK as it is, but it will need some safety features. There was a lot of energy in an ad hoc session in Prague back last July, which produced a prioritised list, including performance improvements (see TCP Prague Requirements) but then everyonr went home, went on summer holidays, returned to their day jobs and it all went quiet...

If you missed all the above, we've pulled together videos of demos, short papers, I-Ds etc here: https://riteproject.eu/dctth/
Incuding this particularly useful 2-pager: “Ultra-Low Delay for All” IETF Journal, Nov 2015.

Cheers


Bob Briscoe & Koen De Schepper

{Note 1} As the window scales, the number of congestion signals per RTT remains the same, whereas with classic TCPs it gets smaller.
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------090006030305010904050805-- From nobody Fri Feb 19 10:24:12 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBBE1B2B05; Fri, 19 Feb 2016 10:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 H-4ECxd_b1U4; Fri, 19 Feb 2016 10:24:04 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 377471ACE6C; Fri, 19 Feb 2016 10:24:04 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 69834C94BF; Fri, 19 Feb 2016 13:23:59 -0500 (EST) Date: Fri, 19 Feb 2016 13:23:59 -0500 From: John Leslie To: Bob Briscoe Message-ID: <20160219182359.GA74531@verdi> References: <56C71869.9080503@bobbriscoe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56C71869.9080503@bobbriscoe.net> User-Agent: Mutt/1.4.1i Archived-At: Cc: tcpm IETF list , tsvwg IETF list , AQM IETF list , TCP Prague List , tsv-ads@ietf.org, "De Schepper, Koen \(Koen\)" Subject: Re: [tcpPrague] [tsvwg] (Bar) BoF @IETF-95 'Ultra-Low Queuing Delay for All' (L4S, DualQ Coupled AQM, TCP Prague)? X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 18:24:05 -0000 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. -- John Leslie From nobody Mon Feb 22 00:54:18 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9FC91B2B6F; Mon, 22 Feb 2016 00:54:16 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 H9LR2nYLJL4q; Mon, 22 Feb 2016 00:54:12 -0800 (PST) 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 7AA8B1B2B32; Mon, 22 Feb 2016 00:54:12 -0800 (PST) Received: from 238.28.198.146.dyn.plus.net ([146.198.28.238]:60114 helo=[192.168.0.3]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1aXmFu-0008GS-0W; Mon, 22 Feb 2016 08:54:10 +0000 To: John Leslie References: <56C71869.9080503@bobbriscoe.net> <20160219182359.GA74531@verdi> From: Bob Briscoe Message-ID: <56CACCB1.2080502@bobbriscoe.net> Date: Mon, 22 Feb 2016 08:54:09 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160219182359.GA74531@verdi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: tcpm IETF list , tsvwg IETF list , tsv-ads@ietf.org, TCP Prague List , "De Schepper, Koen \(Koen\)" , AQM IETF list Subject: Re: [tcpPrague] [tsvwg] (Bar) BoF @IETF-95 'Ultra-Low Queuing Delay for All' (L4S, DualQ Coupled AQM, TCP Prague)? X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 08:54:16 -0000 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. 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/ From nobody Mon Feb 22 09:21:31 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD2B1ACF19; Mon, 22 Feb 2016 09:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 adofOQvtrqQY; Mon, 22 Feb 2016 09:21:25 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 3F68B1A8796; Mon, 22 Feb 2016 09:21:25 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id u200so124504136ywf.0; Mon, 22 Feb 2016 09:21:25 -0800 (PST) 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:content-type; bh=bHev+2W9a4ZjGp3R/8N28gupmZwanuXHCSwd0Hr0Kow=; b=QNWBbxUYD+769XYgmsT2Vj8DZkxf39GXopOKdgQ4PIkSWVRHHpsyodbqDaGpCd+liP /YRN9VYKe9lohGgN6oQCc0aQtaFcql1xDRcgI6PDbILwxQfXRW3vX7GLTuFuXzEqBQIP jzRPy8wOtU3ap5Z+MCj73WJmlKo8zHf35O/WJtyYIyLMdmZmAwEE1hXyodRPdWuV4J9k krfRG+u5WAB3PXhirxjBkM4pYGY9n78dH94ZbVc39JqhtYjcfN/7utlYtB37JrwEi9gq ks9IgczgfGNHdzRUfsN5tpIaqoohW8W3G++NscE0jG8iwQjXUkJrYV4YH7hQRBpjZuho ukKg== 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:content-type; bh=bHev+2W9a4ZjGp3R/8N28gupmZwanuXHCSwd0Hr0Kow=; b=S9mQDtHXdeRMbijQvAFQrtn3Vd1yBs22gG7V9SW3pSSyVux8CaYMZZTJi8X5HXxnxO fdOUETrkTf602KodKnRSFpvI9UgEAagKP4E89okyS4lQUqOIAONb8c8jmyJOue0Abwv1 cYYUTSfnk7V4cf9a//wdLLhHxm796FWzjrBNEhVIyRiVTxCRxYHNEKQJmc5aN0wsXK/k IOjWAlkS0AJ1A2CGBs9rznIpujQ+9mQb1E8bRtjHHp5wR98EvfnvGR9Yp4N/r2f+ggsh DduXNubavxzZcORvly865G5r/0ZugP/M3jcXhzyrSOh5WudkN+iSPfXMPWk8aSCj1MYI PsUQ== X-Gm-Message-State: AG10YOTUqpNfTF2g6QCEbxUSXgEWUmQ7sBY/bX0gDCmyvXxIoHPu4npfVjKsKkMFdxKHQO+4txuPS/s+/+6g9w== MIME-Version: 1.0 X-Received: by 10.13.210.7 with SMTP id u7mr14225566ywd.100.1456161684492; Mon, 22 Feb 2016 09:21:24 -0800 (PST) Received: by 10.37.99.65 with HTTP; Mon, 22 Feb 2016 09:21:24 -0800 (PST) In-Reply-To: <56CACCB1.2080502@bobbriscoe.net> References: <56C71869.9080503@bobbriscoe.net> <20160219182359.GA74531@verdi> <56CACCB1.2080502@bobbriscoe.net> Date: Mon, 22 Feb 2016 11:21:24 -0600 Message-ID: From: Spencer Dawkins at IETF To: Bob Briscoe Content-Type: multipart/alternative; boundary=001a114e7e78f0aa6b052c5f0fd5 Archived-At: Cc: tcpm IETF list , tsvwg IETF list , John Leslie , TCP Prague List , "tsv-ads@ietf.org" , AQM IETF list , "De Schepper, Koen \(Koen\)" Subject: Re: [tcpPrague] [tsvwg] (Bar) BoF @IETF-95 'Ultra-Low Queuing Delay for All' (L4S, DualQ Coupled AQM, TCP Prague)? X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 17:21:29 -0000 --001a114e7e78f0aa6b052c5f0fd5 Content-Type: text/plain; charset=UTF-8 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/ > > --001a114e7e78f0aa6b052c5f0fd5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just to try to be helpful ...
On Mon, Feb 22, 2016 at 2:54 AM, Bob Briscoe <= span dir=3D"ltr"><ietf@bobbriscoe.net> wrote:
John,

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

We would like to propose a Bar BoF at the Buenos Aires IETF, about L4S,
DualQ and solutions to the TCP Prague Requirements.
=C2=A0 =C2=A0 This feels like it belongs as a non-WG-forming formal BoF.
=C2=A0 =C2=A0 It describes work spanning at least three WGs; and could bene= fit from
formal scheduling to avoid conflicts with those WGs and others.

=C2=A0 =C2=A0 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.

=C2=A0 =C2=A0 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=C2=A0http://www.ietf.org/meeting/amreq.html. If = you put "TSV" in as "type of meeting", your happy TSV A= Ds would see the request.

Thanks,

Spencer
=C2=A0
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<= /a>
https://www.ietf.org/mailman/listinfo/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://bobbriscoe.net/


--001a114e7e78f0aa6b052c5f0fd5--