From nobody Wed Jun 1 03:53:28 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3111E12D098 for ; Wed, 1 Jun 2016 03:53:27 -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, 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 FJwNgxBzKMQi for ; Wed, 1 Jun 2016 03:53:25 -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 104E412D0C6 for ; Wed, 1 Jun 2016 03:53:25 -0700 (PDT) Received: from [31.185.187.76] (port=45454 helo=[192.168.0.10]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1b83m6-0001SO-Qq for tcpPrague@ietf.org; Wed, 01 Jun 2016 11:53:23 +0100 To: TCP Prague List From: Bob Briscoe Message-ID: <574EBEA2.8080705@bobbriscoe.net> Date: Wed, 1 Jun 2016 11:53:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: [tcpPrague] Enough energy for an L4S/TCP Prague BoF? X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 01 Jun 2016 10:53:27 -0000 All, Can some folks respond on whether they think it is right to hold a BoF on this topic in Berlin. Back in Jul 2015, when we had the first ad hoc meeting about evolving DCTCP (the one where Matt Mathis suggested we call it TCP Prague), there was a huge amount of energy and excitement in the room. However, I've noticed that the discussion on this list seems to move in fits and starts. Can anyone suggest why? I see much more discussion off-list about building projects, around the enabling idea of the dualQ. Perhaps it's just that it takes a long time for some people to be able to to shift the focus of their work. If that's so, then I guess it is still worth the core proponents pressing ahead. Because others only need to influence the direction of travel of a project if it is moving! Thoughts? Bob PS. The BoF proposal deadline is on Friday. I'm guilty for not having yet delivered what I promised: a problem statement draft - working on it now. -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Wed Jun 1 04:04:37 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0665112D0A0 for ; Wed, 1 Jun 2016 04:04:34 -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=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 n0WjJFjbhcZc for ; Wed, 1 Jun 2016 04:04:29 -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 7F73812B05F for ; Wed, 1 Jun 2016 03:57:00 -0700 (PDT) Received: from [31.185.187.76] (port=45460 helo=[192.168.0.10]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1b83pa-00024f-Od; Wed, 01 Jun 2016 11:56:59 +0100 References: <573E0611.5070803@bobbriscoe.net> To: iccrg IRTF list From: Bob Briscoe X-Forwarded-Message-Id: <573E0611.5070803@bobbriscoe.net> Message-ID: <574EBF79.9030108@bobbriscoe.net> Date: Wed, 1 Jun 2016 11:56:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <573E0611.5070803@bobbriscoe.net> Content-Type: multipart/alternative; boundary="------------030805060306030105010006" 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: TCP Prague List Subject: [tcpPrague] Fwd: L4S/DualQ BoF-forming on tcpprague list: pls air your concerns X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 01 Jun 2016 11:04:34 -0000 This is a multi-part message in MIME format. --------------030805060306030105010006 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit ICCRG folks, I just realised I omitted the iccrg list from the distribution of the mail below. Bob -------- Forwarded Message -------- Subject: L4S/DualQ BoF-forming on tcpprague list: pls air your concerns Date: Thu, 19 May 2016 19:29:37 +0100 From: Bob Briscoe To: tsv-area IETF list , AQM IETF list , tcpm IETF list , tsvwg IETF list , rmcat@ietf.org CC: TCP Prague List Multiple IETF Transport mailing lists. This is to announce that discussions are proceeding on the tcpprague@ietf.org list [see archive ] about organising a BoF on Low Latency Low Loss Scalable throughput (L4S) service, for the IETF-96 Berlin timeframe. The proposed L4S BoF will be about the full implications of L4S - on ECN, SCTP, RMCAT, AQM, etc. Despite the name of the mailing list, it is not just about so-called "TCP Prague" and its implications solely on TCP. If you reply to this announcement, please cut all the mailing lists from the distr except tcpprague. Anyone who is sceptical of the L4S approach, or its safety for the public Internet, please air your concerns. Ideally now on the tcpprague list, but certainly at or preferably before the proposed BoF in Berlin. If you prefer to air your concerns on your favourite WG mailing list, pls at least ensure the tcpprague list is aware. You may know L4S as the DualQ Coupled AQM. Background info on L4S including I-Ds, code, videos, etc. can be found here: https://riteproject.eu/dctth/ Cheers Bob > > -------- Forwarded Message -------- > Subject: Volunteers pls: L4S non-WG-forming BoF proposal cut-off > approaching > Date: Wed, 18 May 2016 12:47:26 +0100 > From: Bob Briscoe > To: TCP Prague List > > > > Folks, > > At the Low Latency, Low Loss Scalable throughput (L4S) Bar Bof in > Buenos Aires, there was support for a BoF about L4S, In the IETF-96 > (Berlin) time-frame. > It was decided to initially use this ML, even tho the scope of L4S is > wider than TCP Prague. > Consensus was to aim for a non-WG-forming BoF, to demonstrate > willingness to work on the pieces in existing IETF WGs, and to > co-ordinate approaches to each WG. > > The cut-off is now 2.5 weeks away. > *2016-06-03 (Friday):* Cut-off date for BOF proposal requests to Area > Directors at UTC 23:59. > > To organise a successful BoF (referring to rfc5434 > ), we need volunteers for the > following tasks: > #/ Draft a statement of problem & scope > #/ List planned deliverables (incl. implementation, spec drafting), > milestones and target WG (also identify any critical interdependencies) > #/ Identify and draft any necessary changes to WG charters, to cover > the above deliverables > #/ Discuss with relevant WG chairs and ADs [see background below] > #/ Identify volunteers (pref before the BoF) planning to work on each > deliverable > > Some people have already volunteered in general to help with arranging > the BoF, but we now need to get specific. > > Let's get volunteers for the above priority tasks first, but for > completeness I'll also list the formalities we have to do: > #/ Decide on name of BoF (and mailing list) > #/ BoF facilitators - chairs, scribes, etc > #/ Draft the BoF agenda, incl. time constraints > #/ Decide on the BoF questions > #/ Estimate attendance, list conflicts, decide duration > #/ Submit a formal request for the BoF via > http://www.ietf.org/instructions/MTG-SLOTS.html and > http://www.ietf.org/ietf/1bof-procedures.txt > > I'll start off co-ordinating and chasing all the above, but contact me > if you would like to take on the co-ordinating task. > > *Background work so far** > * > The idea of this BoF has been floated with WG chairs and ADs for some > time now (since Nov'15 in Yokohama), except AFAIK, we haven't talked > with the RMCAT chairs. > Also we have already done considerable work on defining the problem > while writing various drafts and papers about L4S. > > But, that was just a small group of co-authors (me, Koen, Inton, > Olga). There's still a lot to do to build wider consensus. > We can go ahead with a BoF scheduling request even if disagreements on > scope/problem remain. > But before the BoF itself, we need to have any such disagreements > ironed out. > > At the Buenos Aires Bar Bof, we put up a todo list of pieces that will > need to be worked on: > See http://www.bobbriscoe.net/presents/1604ietf/1604-l4s-bar-bof.pdf > particularly slides 9 & 10 > and the target WGs for each were: > * TSVWG (the L4S identifier) > * AQM (the AQM - the name gives the clue ;) > * TCPM (the DCTCP-like congestion control, covering SCTP) > * RMCAT (L4S variants of real-time congestion controls, or at least > standardise existing controls using the identifier) > > I believe, formally, each WG has to decide to charter additional work > on its own ML. > > [Since then, Ingemar has pointed out on this list that we also need to > get AQM & ECN-marking in radio networks, and that will require working > with/through other SDOs and/or developer groups that deal with the MAC > layer . > V. important, but let's push that to a separate thread.] > > Many of the pieces have their own rationale, independent of L4S. The > idea of the BoF is to draw the bigger picture that motivates the work. > That doesn't preclude incremental work on the pieces for those who are > not motivated by a big picture. > > Cheers > > > > Bob -- ________________________________________________________________ Bob Briscoehttp://bobbriscoe.net/ --------------030805060306030105010006 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit ICCRG folks,

I just realised I omitted the iccrg list from the distribution of the mail below.

Bob

-------- Forwarded Message --------
Subject: L4S/DualQ BoF-forming on tcpprague list: pls air your concerns
Date: Thu, 19 May 2016 19:29:37 +0100
From: Bob Briscoe <ietf@bobbriscoe.net>
To: tsv-area IETF list <tsv-area@ietf.org>, AQM IETF list <aqm@ietf.org>, tcpm IETF list <tcpm@ietf.org>, tsvwg IETF list <tsvwg@ietf.org>, rmcat@ietf.org <rmcat@ietf.org>
CC: TCP Prague List <tcpPrague@ietf.org>


Multiple IETF Transport mailing lists.

This is to announce that discussions are proceeding on the tcpprague@ietf.org list [see archive] about organising a BoF on Low Latency Low Loss Scalable throughput (L4S) service, for the IETF-96 Berlin timeframe.
The proposed L4S BoF will be about the full implications of L4S - on ECN, SCTP, RMCAT, AQM, etc. Despite the name of the mailing list, it is not just about so-called "TCP Prague" and its implications solely on TCP.

If you reply to this announcement, please cut all the mailing lists from the distr except tcpprague.

Anyone who is sceptical of the L4S approach, or its safety for the public Internet, please air your concerns. Ideally now on the tcpprague list, but certainly at or preferably before the proposed BoF in Berlin.
If you prefer to air your concerns on your favourite WG mailing list, pls at least ensure the tcpprague list is aware.

You may know L4S as the DualQ Coupled AQM. Background info on L4S including I-Ds, code, videos, etc. can be found here:
https://riteproject.eu/dctth/

Cheers




Bob


-------- Forwarded Message --------
Subject: Volunteers pls: L4S non-WG-forming BoF proposal cut-off approaching
Date: Wed, 18 May 2016 12:47:26 +0100
From: Bob Briscoe <ietf@bobbriscoe.net>
To: TCP Prague List <tcpPrague@ietf.org>


Folks,

At the Low Latency, Low Loss Scalable throughput (L4S) Bar Bof in Buenos Aires, there was support for a BoF about L4S, In the IETF-96 (Berlin) time-frame.
It was decided to initially use this ML, even tho the scope of L4S is wider than TCP Prague.
Consensus was to aim for a non-WG-forming BoF, to demonstrate willingness to work on the pieces in existing IETF WGs, and to co-ordinate approaches to each WG.

The cut-off is now 2.5 weeks away.
*2016-06-03 (Friday):* Cut-off date for BOF proposal requests to Area Directors at UTC 23:59.

To organise a successful BoF (referring to rfc5434), we need volunteers for the following tasks:
#/ Draft a statement of problem & scope
#/ List planned deliverables (incl. implementation, spec drafting), milestones and target WG (also identify any critical interdependencies)
#/ Identify and draft any necessary changes to WG charters, to cover the above deliverables
#/ Discuss with relevant WG chairs and ADs [see background below]
#/ Identify volunteers (pref before the BoF) planning to work on each deliverable

Some people have already volunteered in general to help with arranging the BoF, but we now need to get specific.

Let's get volunteers for the above priority tasks first, but for completeness I'll also list the formalities we have to do:
#/ Decide on name of BoF (and mailing list)
#/ BoF facilitators - chairs, scribes, etc
#/ Draft the BoF agenda, incl. time constraints
#/ Decide on the BoF questions
#/ Estimate attendance, list conflicts, decide duration
#/ Submit a formal request for the BoF via
     http://www.ietf.org/instructions/MTG-SLOTS.html and
     http://www.ietf.org/ietf/1bof-procedures.txt

I'll start off co-ordinating and chasing all the above, but contact me if you would like to take on the co-ordinating task.

Background work so far

The idea of this BoF has been floated with WG chairs and ADs for some time now (since Nov'15 in Yokohama), except AFAIK, we haven't talked with the RMCAT chairs.
Also we have already done considerable work on defining the problem while writing various drafts and papers about L4S.

But, that was just a small group of co-authors (me, Koen, Inton, Olga). There's still a lot to do to build wider consensus.
We can go ahead with a BoF scheduling request even if disagreements on scope/problem remain.
But before the BoF itself, we need to have any such disagreements ironed out.

At the Buenos Aires Bar Bof, we put up a todo list of pieces that will need to be worked on:
See http://www.bobbriscoe.net/presents/1604ietf/1604-l4s-bar-bof.pdf particularly slides 9 & 10
and the target WGs for each were:
* TSVWG (the L4S identifier)
* AQM (the AQM - the name gives the clue ;)
* TCPM (the DCTCP-like congestion control, covering SCTP)
* RMCAT (L4S variants of real-time congestion controls, or at least standardise existing controls using the identifier)

I believe, formally, each WG has to decide to charter additional work on its own ML.

[Since then, Ingemar has pointed out on this list that we also need to get AQM & ECN-marking in radio networks, and that will require working with/through other SDOs and/or developer groups that deal with the MAC layer .
V. important, but let's push that to a separate thread.]

Many of the pieces have their own rationale, independent of L4S. The idea of the BoF is to draw the bigger picture that motivates the work.
That doesn't preclude incremental work on the pieces for those who are not motivated by a big picture.

Cheers



Bob




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


--------------030805060306030105010006-- From nobody Wed Jun 1 04:11:55 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF6512D0A0 for ; Wed, 1 Jun 2016 04:11:53 -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, 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 8kWly5ThGZ9Q for ; Wed, 1 Jun 2016 04:11:52 -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 A8BF412B027 for ; Wed, 1 Jun 2016 04:11:51 -0700 (PDT) Received: from [31.185.187.76] (port=45507 helo=[192.168.0.10]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1b843x-0003nI-8I; Wed, 01 Jun 2016 12:11:49 +0100 From: Bob Briscoe To: marcelo bagnulo braun References: <5742D224.6020205@it.uc3m.es> Message-ID: <574EC2F3.5010205@bobbriscoe.net> Date: Wed, 1 Jun 2016 12:11:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <5742D224.6020205@it.uc3m.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: TCP Prague List Subject: Re: [tcpPrague] L4S reading list X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 01 Jun 2016 11:11:53 -0000 Marcelo, Papers here: https://riteproject.eu/dctth/#papers Internet Drafts here: https://riteproject.eu/dctth/#ietf-specs Bob On 23/05/16 10:49, marcelo bagnulo braun wrote: > Hi Bob, > > I am back from a wek of holidays and was planning to devote some time > on this this week. > > In a previous email you said there are various papers and drafts about > L4S, can you proide a reading list? > > Maybe it would be useful to circulate this on the ml, if you havent > done so yet? > > thanks, marcelo > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Wed Jun 1 08:29:15 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C15812D5BD for ; Wed, 1 Jun 2016 08:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.026 X-Spam-Level: X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426] 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 QgHVRL28OeyF for ; Wed, 1 Jun 2016 08:29:11 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 70F5C12D5B7 for ; Wed, 1 Jun 2016 08:29:11 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 43456C9423; Wed, 1 Jun 2016 11:29:08 -0400 (EDT) Date: Wed, 1 Jun 2016 11:29:08 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20160601152908.GB1754@verdi> References: <574EBEA2.8080705@bobbriscoe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <574EBEA2.8080705@bobbriscoe.net> User-Agent: Mutt/1.4.1i Archived-At: Cc: TCP Prague List Subject: Re: [tcpPrague] Enough energy for an L4S/TCP Prague BoF? X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 01 Jun 2016 15:29:13 -0000 Bob Briscoe wrote: > > Can some folks respond on whether they think it is right to hold a BoF > on this topic in Berlin. I must admit I see little reason for a non-WG-forming formal-BoF. The formal-BoF process is really organized around forming a WG. An informal-BoF can be organized entirely outside this process; and were I to attend Berlin, I would certainly want to participate. It's getting awfully late to start organizing a WG-forming BoF, so I'd tend to set my sights on an informal-BoF. We should definitely note draft-khademi-tsvwg-ecn-response, recently submitted to TSVWG, presumably intended to become adopted as a WG draft, and setting a basis for relaxing the "same-as-drop" rule of RFC3168. It mentions draft-khademi-tcpm-alternativebackoff-ecn, which presumably is intended to become a TCPM WG draft and offers a different experiment from dualq which we've been discussing here. I think it's more important to get involved in those discussions than to try for a formal-BoF in Berlin. Obviously, YMMV... -- John Leslie From nobody Wed Jun 1 11:32:21 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF33512D16C for ; Wed, 1 Jun 2016 11:32:19 -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 RZmwFHrmyNfV for ; Wed, 1 Jun 2016 11:32:17 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17FCB12D0D1 for ; Wed, 1 Jun 2016 11:32:17 -0700 (PDT) Received: from [31.185.187.76] (port=46604 helo=[192.168.0.10]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1b8AwA-0006LE-LJ; Wed, 01 Jun 2016 19:32:15 +0100 To: John Leslie References: <574EBEA2.8080705@bobbriscoe.net> <20160601152908.GB1754@verdi> From: Bob Briscoe Message-ID: <574F2A2D.9070407@bobbriscoe.net> Date: Wed, 1 Jun 2016 19:32:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160601152908.GB1754@verdi> Content-Type: multipart/alternative; boundary="------------060600090907000908010203" 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: TCP Prague List Subject: Re: [tcpPrague] Enough energy for an L4S/TCP Prague BoF? X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 01 Jun 2016 18:32:20 -0000 This is a multi-part message in MIME format. --------------060600090907000908010203 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit John, Before getting back to the WG-forming vs. non-WG forming BoFs debate, let's explore your idea from a couple of weeks back, which might not even need a BoF: On 22/05/16 00:55, John Leslie wrote: > Thus, I'd like to see a first deliverable be a Proposed Standard laying > out ground-rules for (quite possibly multiple) Experimental status documents. > I know I've seen a fairly wide range of proposals differing in details from > L4S (some of them very dependent upon variations in delay); and it's hard > to believe that nobody will still want to push for their idea. I think you are saying this PS would: a) state the requirements for a new form of "ECN not the same as drop", targeted at much lower latency queuing (including L4S, ABE and others). b) free up the use of ECT(1) if necessary for this purpose (needed by L4S but not ABE), by formally declaring the end of the ECN nonce experiment, and updating all the RFCs (including PSs) that refer to "same as drop" behaviour for ECN, or the ECN Nonce. If such an RFC could be written (see below), it would serve the purpose we were hoping that a BoF would serve: to describe how a set of pieces might fit together as part of a larger programme of work, even if they are standardized in separate WGs (and even if some improve the Internet on their own whether or not the master-plan happens). It would have the advantage over a BoF that it would require the consensus of all the affected WGs (as does any IETF RFC). But... Can someone who understands IETF process better than I, answer these questions: * Can a Proposed Standard just 'clear a space' without actually defining a specific protocol to fill that space? Any examples from history? * Don't protocol requirements tend to be written in informational RFCs, not PS? Even if PS is an appropriate status, I see problems writing such an RFC so abstractly that it would encompass as-yet-unknown alternative proposals. Of course, I see no problem describing where an existing proposal fits, e.g. ABE. For instance, draft-briscoe-tsvwg-ecn-l4s-id-01 has very similar scope to the document you propose, except: a) It has currently been written as experimental (but it says what it would say if it was PS). b) it precisely (but very generally) describes the new semantics of the identifier. Take a read of it, then tell us how you think it could be written without any specifics,... to become the doc you are thinking of. I think the IESG (and the intended audience) would have a hard time understanding such an abstract document. Or perhaps you are /not/ saying that it has to be completely non-specific. Perhaps ecn-l4s-id is already close to the sort of doc you are talking about. For instance: * it describes the problem * it refers to the technology that would be necessary and sufficient in the network (some sort of DualQ); * it has a section on "Pre-Requisite Transport Layer Behaviour", where requirements on TCP, SCTP, RMCAT etc. have been written. * It also obsoletes the ECN nonce. *A New Working Group?** * I believe such a doc could and should be written in tsvwg, with formal last calls to tcpm, aqm, rmcat and iccrg as well. I do not see that a separate WG is necessary, or even useful, for writing this. What's your reasoning? We need to be quick, cos if we need a new WG, we've only got 2 days ;) There are a couple of things that a BoF would achieve that a new I-D would not achieve: * socializing with the rest of the IETF, particularly the IESG and IAB, that this work is starting, so they can understand it and expect it. * highlighting the potential architectural importance of the work, particularly to the IESG and the IAB (e.g. sunsetting TCP Reno, implications for Diffserv, etc). There must be other ways to achieve these two goals? A plenary presentation? An IAB workshop? Regards Bob On 01/06/16 16:29, John Leslie wrote: > Bob Briscoe wrote: >> Can some folks respond on whether they think it is right to hold a BoF >> on this topic in Berlin. > I must admit I see little reason for a non-WG-forming formal-BoF. > > The formal-BoF process is really organized around forming a WG. An > informal-BoF can be organized entirely outside this process; and were > I to attend Berlin, I would certainly want to participate. > > It's getting awfully late to start organizing a WG-forming BoF, so > I'd tend to set my sights on an informal-BoF. > > We should definitely note draft-khademi-tsvwg-ecn-response, recently > submitted to TSVWG, presumably intended to become adopted as a WG draft, > and setting a basis for relaxing the "same-as-drop" rule of RFC3168. > > It mentions draft-khademi-tcpm-alternativebackoff-ecn, which presumably > is intended to become a TCPM WG draft and offers a different experiment > from dualq which we've been discussing here. > > I think it's more important to get involved in those discussions > than to try for a formal-BoF in Berlin. > > Obviously, YMMV... > > -- > John Leslie > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ --------------060600090907000908010203 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit John,

Before getting back to the WG-forming vs. non-WG forming BoFs debate, let's explore your idea from a couple of weeks back, which might not even need a BoF:

On 22/05/16 00:55, John Leslie wrote:
   Thus, I'd like to see a first deliverable be a Proposed Standard laying
out ground-rules for (quite possibly multiple) Experimental status documents.
I know I've seen a fairly wide range of proposals differing in details from
L4S (some of them very dependent upon variations in delay); and it's hard
to believe that nobody will still want to push for their idea.

I think you are saying this PS would:
a) state the requirements for a new form of "ECN not the same as drop", targeted at much lower latency queuing (including L4S, ABE and others).
b) free up the use of ECT(1) if necessary for this purpose (needed by L4S but not ABE), by formally declaring the end of the ECN nonce experiment, and updating all the RFCs (including PSs) that refer to "same as drop" behaviour for ECN, or the ECN Nonce.

If such an RFC could be written (see below), it would serve the purpose we were hoping that a BoF would serve: to describe how a set of pieces might fit together as part of a larger programme of work, even if they are standardized in separate WGs (and even if some improve the Internet on their own whether or not the master-plan happens).

It would have the advantage over a BoF that it would require the consensus of all the affected WGs (as does any IETF RFC).

But...
Can someone who understands IETF process better than I, answer these questions:
* Can a Proposed Standard just 'clear a space' without actually defining a specific protocol to fill that space? Any examples from history?
* Don't protocol requirements tend to be written in informational RFCs, not PS?

Even if PS is an appropriate status, I see problems writing such an RFC so abstractly that it would encompass as-yet-unknown alternative proposals. Of course, I see no problem describing where an existing proposal fits, e.g. ABE.

For instance, draft-briscoe-tsvwg-ecn-l4s-id-01 has very similar scope to the document you propose, except:
a) It has currently been written as experimental (but it says what it would say if it was PS).
b) it precisely (but very generally) describes the new semantics of the identifier.

Take a read of it, then tell us how you think it could be written without any specifics,... to become the doc you are thinking of.
I think the IESG (and the intended audience) would have a hard time understanding such an abstract document.

Or perhaps you are /not/ saying that it has to be completely non-specific. Perhaps ecn-l4s-id is already close to the sort of doc you are talking about. For instance:
* it describes the problem
* it refers to the technology that would be necessary and sufficient in the network (some sort of DualQ);
* it has a section on "Pre-Requisite Transport Layer Behaviour", where requirements on TCP, SCTP, RMCAT etc. have been written.
* It also obsoletes the ECN nonce.

A New Working Group?

I believe such a doc could and should be written in tsvwg, with formal last calls to tcpm, aqm, rmcat and iccrg as well.

I do not see that a separate WG is necessary, or even useful, for writing this.
What's your reasoning?
We need to be quick, cos if we need a new WG, we've only got 2 days ;)


There are a couple of things that a BoF would achieve that a new I-D would not achieve:
* socializing with the rest of the IETF, particularly the IESG and IAB, that this work is starting, so they can understand it and expect it.
* highlighting the potential architectural importance of the work, particularly to the IESG and the IAB (e.g. sunsetting TCP Reno, implications for Diffserv, etc).

There must be other ways to achieve these two goals? A plenary presentation? An IAB workshop?

Regards


Bob



On 01/06/16 16:29, John Leslie wrote:
Bob Briscoe <research@bobbriscoe.net> wrote:

Can some folks respond on whether they think it is right to hold a BoF 
on this topic in Berlin.

   I must admit I see little reason for a non-WG-forming formal-BoF.

   The formal-BoF process is really organized around forming a WG. An
informal-BoF can be organized entirely outside this process; and were
I to attend Berlin, I would certainly want to participate.

   It's getting awfully late to start organizing a WG-forming BoF, so
I'd tend to set my sights on an informal-BoF.

   We should definitely note draft-khademi-tsvwg-ecn-response, recently
submitted to TSVWG, presumably intended to become adopted as a WG draft,
and setting a basis for relaxing the "same-as-drop" rule of RFC3168.

   It mentions draft-khademi-tcpm-alternativebackoff-ecn, which presumably
is intended to become a TCPM WG draft and offers a different experiment
from dualq which we've been discussing here.

   I think it's more important to get involved in those discussions
than to try for a formal-BoF in Berlin.

   Obviously, YMMV...

--
John Leslie <john@jlc.net>


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------060600090907000908010203-- From nobody Wed Jun 1 12:31:19 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4778712B039 for ; Wed, 1 Jun 2016 12:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 yvI0IB67hlht for ; Wed, 1 Jun 2016 12:31:16 -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 1B71112D1DE for ; Wed, 1 Jun 2016 12:31:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id EE361D930B; Wed, 1 Jun 2016 21:31:13 +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 25MaeIM9zu5r; Wed, 1 Jun 2016 21:31:13 +0200 (MEST) Received: from [192.168.220.145] (178-83-155-34.dynamic.hispeed.ch [178.83.155.34]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id B9FCFD9305; Wed, 1 Jun 2016 21:31:13 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <574EBEA2.8080705@bobbriscoe.net> Date: Wed, 1 Jun 2016 21:31:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <574EBEA2.8080705@bobbriscoe.net> To: Bob Briscoe X-Mailer: Apple Mail (2.3124) Archived-At: Cc: TCP Prague List Subject: Re: [tcpPrague] Enough energy for an L4S/TCP Prague BoF? X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 01 Jun 2016 19:31:18 -0000 Hi Bob, > Am 01.06.2016 um 12:53 schrieb Bob Briscoe : >=20 > However, I've noticed that the discussion on this list seems to move = in fits and starts. > Can anyone suggest why? I believe it would help to foster discussion if someone (you) would send = a problem statement to the list because right now there are a lot of = people interesting in this topic where everybody might have his/her own = idea what this is about. Having a common understanding of want we want = is the first step. For me most of things I=E2=80=99ve seen so far are = very wide spread and I guess there something for everybody that sounds = interesting=E2=80=A6 Just my 2c. Mirja From nobody Wed Jun 1 12:48:58 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D921200A0 for ; Wed, 1 Jun 2016 12:48:54 -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, 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 feYCQvLGZUId for ; Wed, 1 Jun 2016 12:48:52 -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 6FA3912B01C for ; Wed, 1 Jun 2016 12:48:52 -0700 (PDT) Received: from [31.185.187.76] (port=46678 helo=[192.168.0.10]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1b8C8I-0004Pp-Ko; Wed, 01 Jun 2016 20:48:50 +0100 To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <574EBEA2.8080705@bobbriscoe.net> From: Bob Briscoe Message-ID: <574F3C21.1090903@bobbriscoe.net> Date: Wed, 1 Jun 2016 20:48:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: TCP Prague List Subject: Re: [tcpPrague] Enough energy for an L4S/TCP Prague BoF? X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 01 Jun 2016 19:48:55 -0000 M, OK, Will do. B On 01/06/16 20:31, Mirja Kühlewind wrote: > Hi Bob, > >> Am 01.06.2016 um 12:53 schrieb Bob Briscoe : >> >> However, I've noticed that the discussion on this list seems to move in fits and starts. >> Can anyone suggest why? > I believe it would help to foster discussion if someone (you) would send a problem statement to the list because right now there are a lot of people interesting in this topic where everybody might have his/her own idea what this is about. Having a common understanding of want we want is the first step. For me most of things I’ve seen so far are very wide spread and I guess there something for everybody that sounds interesting… > > Just my 2c. > > Mirja > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Wed Jun 1 14:10:08 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D96112D612 for ; Wed, 1 Jun 2016 14:10:07 -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 pBL_iflL-fPQ for ; Wed, 1 Jun 2016 14:10:05 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76A6512B01F for ; Wed, 1 Jun 2016 14:10:04 -0700 (PDT) Received: from [31.185.187.76] (port=51784 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1b8DOs-0004vv-6e; Wed, 01 Jun 2016 22:10:02 +0100 To: John Leslie , Gorry Fairhurst References: <574EBEA2.8080705@bobbriscoe.net> <20160601152908.GB1754@verdi> <574F2A2D.9070407@bobbriscoe.net> From: Bob Briscoe Message-ID: <574F4F29.9040409@bobbriscoe.net> Date: Wed, 1 Jun 2016 22:10:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <574F2A2D.9070407@bobbriscoe.net> Content-Type: multipart/alternative; boundary="------------060904070108060900020508" 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: TCP Prague List Subject: Re: [tcpPrague] Enough energy for an L4S/TCP Prague BoF? X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 01 Jun 2016 21:10:07 -0000 This is a multi-part message in MIME format. --------------060904070108060900020508 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit John, Gorry, A random new thought... Another mechanism I've seen for this sort of thing is a mini-BoF within an existing WG agenda. I'm not sure whether a mini-BoF needs any official procedure. Am I correct that a mini-BoF is appropriate for extending a WG's charter in a more major direction than just adding one doc, and/or where it's not clear whether a new WG might be needed instead? It could possibly be a tsvwg mini-BoF. Or perhaps a joint tcpm, tsvwg, aqm mini-BoF, if such a thing exists? Bob On 01/06/16 19:32, Bob Briscoe wrote: > John, > > Before getting back to the WG-forming vs. non-WG forming BoFs debate, > let's explore your idea from a couple of weeks back, which might not > even need a BoF: > > On 22/05/16 00:55, John Leslie wrote: >> Thus, I'd like to see a first deliverable be a Proposed Standard laying >> out ground-rules for (quite possibly multiple) Experimental status documents. >> I know I've seen a fairly wide range of proposals differing in details from >> L4S (some of them very dependent upon variations in delay); and it's hard >> to believe that nobody will still want to push for their idea. > > I think you are saying this PS would: > a) state the requirements for a new form of "ECN not the same as > drop", targeted at much lower latency queuing (including L4S, ABE and > others). > b) free up the use of ECT(1) if necessary for this purpose (needed by > L4S but not ABE), by formally declaring the end of the ECN nonce > experiment, and updating all the RFCs (including PSs) that refer to > "same as drop" behaviour for ECN, or the ECN Nonce. > > If such an RFC could be written (see below), it would serve the > purpose we were hoping that a BoF would serve: to describe how a set > of pieces might fit together as part of a larger programme of work, > even if they are standardized in separate WGs (and even if some > improve the Internet on their own whether or not the master-plan > happens). > > It would have the advantage over a BoF that it would require the > consensus of all the affected WGs (as does any IETF RFC). > > But... > Can someone who understands IETF process better than I, answer these > questions: > * Can a Proposed Standard just 'clear a space' without actually > defining a specific protocol to fill that space? Any examples from > history? > * Don't protocol requirements tend to be written in informational > RFCs, not PS? > > Even if PS is an appropriate status, I see problems writing such an > RFC so abstractly that it would encompass as-yet-unknown alternative > proposals. Of course, I see no problem describing where an existing > proposal fits, e.g. ABE. > > For instance, draft-briscoe-tsvwg-ecn-l4s-id-01 has very similar scope > to the document you propose, except: > a) It has currently been written as experimental (but it says what it > would say if it was PS). > b) it precisely (but very generally) describes the new semantics of > the identifier. > > Take a read of it, then tell us how you think it could be written > without any specifics,... to become the doc you are thinking of. > I think the IESG (and the intended audience) would have a hard time > understanding such an abstract document. > > Or perhaps you are /not/ saying that it has to be completely > non-specific. Perhaps ecn-l4s-id is already close to the sort of doc > you are talking about. For instance: > * it describes the problem > * it refers to the technology that would be necessary and sufficient > in the network (some sort of DualQ); > * it has a section on "Pre-Requisite Transport Layer Behaviour", where > requirements on TCP, SCTP, RMCAT etc. have been written. > * It also obsoletes the ECN nonce. > > *A New Working Group?** > * > I believe such a doc could and should be written in tsvwg, with formal > last calls to tcpm, aqm, rmcat and iccrg as well. > > I do not see that a separate WG is necessary, or even useful, for > writing this. > What's your reasoning? > We need to be quick, cos if we need a new WG, we've only got 2 days ;) > > > There are a couple of things that a BoF would achieve that a new I-D > would not achieve: > * socializing with the rest of the IETF, particularly the IESG and > IAB, that this work is starting, so they can understand it and expect it. > * highlighting the potential architectural importance of the work, > particularly to the IESG and the IAB (e.g. sunsetting TCP Reno, > implications for Diffserv, etc). > > There must be other ways to achieve these two goals? A plenary > presentation? An IAB workshop? > > Regards > > > Bob > > > > On 01/06/16 16:29, John Leslie wrote: >> Bob Briscoe wrote: >>> Can some folks respond on whether they think it is right to hold a BoF >>> on this topic in Berlin. >> I must admit I see little reason for a non-WG-forming formal-BoF. >> >> The formal-BoF process is really organized around forming a WG. An >> informal-BoF can be organized entirely outside this process; and were >> I to attend Berlin, I would certainly want to participate. >> >> It's getting awfully late to start organizing a WG-forming BoF, so >> I'd tend to set my sights on an informal-BoF. >> >> We should definitely note draft-khademi-tsvwg-ecn-response, recently >> submitted to TSVWG, presumably intended to become adopted as a WG draft, >> and setting a basis for relaxing the "same-as-drop" rule of RFC3168. >> >> It mentions draft-khademi-tcpm-alternativebackoff-ecn, which presumably >> is intended to become a TCPM WG draft and offers a different experiment >> from dualq which we've been discussing here. >> >> I think it's more important to get involved in those discussions >> than to try for a formal-BoF in Berlin. >> >> Obviously, YMMV... >> >> -- >> John Leslie >> >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------060904070108060900020508 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit John, Gorry,

A random new thought...
Another mechanism I've seen for this sort of thing is a mini-BoF within an existing WG agenda.
I'm not sure whether a mini-BoF needs any official procedure. Am I correct that a mini-BoF is appropriate for extending a WG's charter in a more major direction than just adding one doc, and/or where it's not clear whether a new WG might be needed instead?

It could possibly be a tsvwg mini-BoF.
Or perhaps a joint tcpm, tsvwg, aqm mini-BoF, if such a thing exists?


Bob


On 01/06/16 19:32, Bob Briscoe wrote:
John,

Before getting back to the WG-forming vs. non-WG forming BoFs debate, let's explore your idea from a couple of weeks back, which might not even need a BoF:

On 22/05/16 00:55, John Leslie wrote:
   Thus, I'd like to see a first deliverable be a Proposed Standard laying
out ground-rules for (quite possibly multiple) Experimental status documents.
I know I've seen a fairly wide range of proposals differing in details from
L4S (some of them very dependent upon variations in delay); and it's hard
to believe that nobody will still want to push for their idea.

I think you are saying this PS would:
a) state the requirements for a new form of "ECN not the same as drop", targeted at much lower latency queuing (including L4S, ABE and others).
b) free up the use of ECT(1) if necessary for this purpose (needed by L4S but not ABE), by formally declaring the end of the ECN nonce experiment, and updating all the RFCs (including PSs) that refer to "same as drop" behaviour for ECN, or the ECN Nonce.

If such an RFC could be written (see below), it would serve the purpose we were hoping that a BoF would serve: to describe how a set of pieces might fit together as part of a larger programme of work, even if they are standardized in separate WGs (and even if some improve the Internet on their own whether or not the master-plan happens).

It would have the advantage over a BoF that it would require the consensus of all the affected WGs (as does any IETF RFC).

But...
Can someone who understands IETF process better than I, answer these questions:
* Can a Proposed Standard just 'clear a space' without actually defining a specific protocol to fill that space? Any examples from history?
* Don't protocol requirements tend to be written in informational RFCs, not PS?

Even if PS is an appropriate status, I see problems writing such an RFC so abstractly that it would encompass as-yet-unknown alternative proposals. Of course, I see no problem describing where an existing proposal fits, e.g. ABE.

For instance, draft-briscoe-tsvwg-ecn-l4s-id-01 has very similar scope to the document you propose, except:
a) It has currently been written as experimental (but it says what it would say if it was PS).
b) it precisely (but very generally) describes the new semantics of the identifier.

Take a read of it, then tell us how you think it could be written without any specifics,... to become the doc you are thinking of.
I think the IESG (and the intended audience) would have a hard time understanding such an abstract document.

Or perhaps you are /not/ saying that it has to be completely non-specific. Perhaps ecn-l4s-id is already close to the sort of doc you are talking about. For instance:
* it describes the problem
* it refers to the technology that would be necessary and sufficient in the network (some sort of DualQ);
* it has a section on "Pre-Requisite Transport Layer Behaviour", where requirements on TCP, SCTP, RMCAT etc. have been written.
* It also obsoletes the ECN nonce.

A New Working Group?

I believe such a doc could and should be written in tsvwg, with formal last calls to tcpm, aqm, rmcat and iccrg as well.

I do not see that a separate WG is necessary, or even useful, for writing this.
What's your reasoning?
We need to be quick, cos if we need a new WG, we've only got 2 days ;)


There are a couple of things that a BoF would achieve that a new I-D would not achieve:
* socializing with the rest of the IETF, particularly the IESG and IAB, that this work is starting, so they can understand it and expect it.
* highlighting the potential architectural importance of the work, particularly to the IESG and the IAB (e.g. sunsetting TCP Reno, implications for Diffserv, etc).

There must be other ways to achieve these two goals? A plenary presentation? An IAB workshop?

Regards


Bob



On 01/06/16 16:29, John Leslie wrote:
Bob Briscoe <research@bobbriscoe.net> wrote:

Can some folks respond on whether they think it is right to hold a BoF 
on this topic in Berlin.

   I must admit I see little reason for a non-WG-forming formal-BoF.

   The formal-BoF process is really organized around forming a WG. An
informal-BoF can be organized entirely outside this process; and were
I to attend Berlin, I would certainly want to participate.

   It's getting awfully late to start organizing a WG-forming BoF, so
I'd tend to set my sights on an informal-BoF.

   We should definitely note draft-khademi-tsvwg-ecn-response, recently
submitted to TSVWG, presumably intended to become adopted as a WG draft,
and setting a basis for relaxing the "same-as-drop" rule of RFC3168.

   It mentions draft-khademi-tcpm-alternativebackoff-ecn, which presumably
is intended to become a TCPM WG draft and offers a different experiment
from dualq which we've been discussing here.

   I think it's more important to get involved in those discussions
than to try for a formal-BoF in Berlin.

   Obviously, YMMV...

--
John Leslie <john@jlc.net>


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

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------060904070108060900020508-- From nobody Wed Jun 1 14:53:20 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95AE912D61F for ; Wed, 1 Jun 2016 14:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.026 X-Spam-Level: X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426] 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 qnWzsdSrAnGX for ; Wed, 1 Jun 2016 14:53:17 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id DC77712D0C4 for ; Wed, 1 Jun 2016 14:53:16 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id C0638C9422; Wed, 1 Jun 2016 17:53:12 -0400 (EDT) Date: Wed, 1 Jun 2016 17:53:12 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20160601215312.GA25116@verdi> References: <574EBEA2.8080705@bobbriscoe.net> <20160601152908.GB1754@verdi> <574F2A2D.9070407@bobbriscoe.net> <574F4F29.9040409@bobbriscoe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <574F4F29.9040409@bobbriscoe.net> User-Agent: Mutt/1.4.1i Archived-At: Cc: Gorry Fairhurst , TCP Prague List Subject: Re: [tcpPrague] Enough energy for an L4S/TCP Prague BoF? X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 01 Jun 2016 21:53:19 -0000 Bob Briscoe wrote: > > John, Gorry, > > A random new thought... (I'm still working on a reply to Bob's earlier email today: I'm tending to make it a private reply since I'm not seeing a lot of interest in discussing it on the tcpprague list.) > Another mechanism I've seen for this sort of thing is a mini-BoF within > an existing WG agenda. I'm not aware of any rules pertaining to such a mini-BoF -- I'd guess the WGCs are entitled to call a section of their WG session a "mini-BoF" and operate under near-BoF rules... > Am I correct that a mini-BoF is appropriate for extending a WG's charter > in a more major direction than just adding one doc, and/or where it's > not clear whether a new WG might be needed instead? > It could possibly be a tsvwg mini-BoF. ISTM that is up to the TSVWG chairs. > Or perhaps a joint tcpm, tsvwg, aqm mini-BoF, if such a thing exists? I really doubt such a thing exists. I'd be happy to see what Bob is suggesting as part of a TSVWG agenda. -- John Leslie From nobody Thu Jun 2 09:03:54 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4021A12D7F3 for ; Thu, 2 Jun 2016 09:03:52 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 a0aVVb-kw3_c for ; Thu, 2 Jun 2016 09:03:50 -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 465C612D7A8 for ; Thu, 2 Jun 2016 09:02:58 -0700 (PDT) Received: from [31.185.187.76] (port=47485 helo=[192.168.0.10]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1b8V5D-0002WC-Ps; Thu, 02 Jun 2016 17:02:56 +0100 To: Jana Iyengar , iccrg IRTF list References: <574EBEA2.8080705@bobbriscoe.net> From: Bob Briscoe Message-ID: <575058AE.1020001@bobbriscoe.net> Date: Thu, 2 Jun 2016 17:02:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <574EBEA2.8080705@bobbriscoe.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: TCP Prague List Subject: [tcpPrague] Too fast for Google? X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 02 Jun 2016 16:03:52 -0000 Jana, When we held the L4S Bar BoF in Buenos Aires, you said we were moving too fast. I think the sentiment behind your point was that we seemed to be shutting out similar approaches too fast. Can you clarify if that's what you meant? If yes, I'd be interested to know if this impression came from the presentations or the drafts. Because: * in the drafts, we've specified example design(s) in appendices, and in the normative body text, we've distilled only the essential structure of the approach as normative standards statements. * in presentations, I (at least) have a tendency to want to be concrete - to demonstrate that there is real code and equipment and tests, etc. I'd also be interested to hear if you think we have been successful in generalising the drafts, or whether you think they are still too specific. In particular, you mentioned making space for delay-based congestion control, which I would /not/ want to include for the reasons below. Is there any rationale for being /that/ general? Background: L4S aims for a very shallow queue, which we indicate with immediate ECN notification (the L4S demo used a 5-MTU threshold when there is no traffic in the classic queue). ECN gives much more precision, and immediately. Rather than waiting for enough packets to get an imprecise delay-measurement heuristic. (for instance the sender can dither packet inter-arrival time during flow-start to sense available capacity, which it can then approach very rapidly without overshoot.) This is what I meant when I said we have created an "incrementally deployable clean-slate"... There is a brief window of opportunity during which we (ie. you, everyone) can all jiggle both host and AQM together. But it will have to be standardised soon, then it will ossify. We can't wait too long, otherwise everyone loses interest. Seriously, I first presented the idea of deploying DCTCP on the Internet in the same session as Van Jacobson introduced CoDel (Jul 2012). We published the main drafts on L4S in Jul 2015, so I think it's reasonable to expect to be moving on to setting standards agendas about a year after that. Your thoughts are always enlightening, so if you haven't set aside time to read, consider deeply and comment,... soon would be good. Bob [I actually wrote a similar email straight after Buenos Aires, but I just noticed I sent it from the wrong address, so the list rejected it.] On 01/06/16 11:53, Bob Briscoe wrote: > All, > > Can some folks respond on whether they think it is right to hold a BoF > on this topic in Berlin. > > Back in Jul 2015, when we had the first ad hoc meeting about evolving > DCTCP (the one where Matt Mathis suggested we call it TCP Prague), > there was a huge amount of energy and excitement in the room. > > However, I've noticed that the discussion on this list seems to move > in fits and starts. > Can anyone suggest why? > > I see much more discussion off-list about building projects, around > the enabling idea of the dualQ. > Perhaps it's just that it takes a long time for some people to be able > to to shift the focus of their work. > > If that's so, then I guess it is still worth the core proponents > pressing ahead. > Because others only need to influence the direction of travel of a > project if it is moving! > > Thoughts? > > > Bob > > PS. The BoF proposal deadline is on Friday. > I'm guilty for not having yet delivered what I promised: a problem > statement draft - working on it now. > > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ From nobody Fri Jun 3 09:17:08 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662B012D6EF for ; Fri, 3 Jun 2016 09:17:07 -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, 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 vL-UrD-t7Et6 for ; Fri, 3 Jun 2016 09:17:05 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 304AB12D6F1 for ; Fri, 3 Jun 2016 09:17:04 -0700 (PDT) Received: from 148.58.125.91.dyn.plus.net ([91.125.58.148]:50834 helo=[192.168.0.10]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1b8rmQ-0001jP-9T; Fri, 03 Jun 2016 17:17:02 +0100 To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <574EBEA2.8080705@bobbriscoe.net> From: Bob Briscoe Message-ID: <5751AD7D.6070807@bobbriscoe.net> Date: Fri, 3 Jun 2016 17:17:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: TCP Prague List Subject: Re: [tcpPrague] Enough energy for an L4S/TCP Prague BoF? X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 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, 03 Jun 2016 16:17:07 -0000 Mirja, Status report on the BoF proposal for you & the list:... You will have seen we've uploaded a problem statement. The BoF proposal is complete in theory, but completely absent on the wiki. I'll fill in the wiki in the next couple of hours. Sorry to everyone that this won't provide long to react to anything they disagree with. So here's a summary of what will be there: The proposal is to have a non-WG-forming BoF, with a suggestion that in practice it takes the form of a mini-BoF within TSV-AREA. We are still putting it through as a BoF request, because we think it is important that the IESG get a heads-up on this, rather than the first they know being when RFCs start to appear two years later. Then if it is decided to do a mini-BoF within TSVAREA, at least the IESG/IAB can know to come along. We will suggest that the questions asked are: 1/ Support this work? 2/ Interested in helping implement, test, write, review, etc.? We believe we should leave the question of how the work is organised (across WGs? a new WG? a hybrid of the two? etc.) for the ADs, rather than burn time in a meeting on that. One of the main purposes will be to demonstrate to the community that there are people working on this, and others that are planning to. Thank you for everyone who has volunteered to give short talks about your current activity around L4S, and/or your plans. Bob On 01/06/16 20:31, Mirja Kühlewind wrote: > Hi Bob, > >> Am 01.06.2016 um 12:53 schrieb Bob Briscoe : >> >> However, I've noticed that the discussion on this list seems to move in fits and starts. >> Can anyone suggest why? > I believe it would help to foster discussion if someone (you) would send a problem statement to the list because right now there are a lot of people interesting in this topic where everybody might have his/her own idea what this is about. Having a common understanding of want we want is the first step. For me most of things I’ve seen so far are very wide spread and I guess there something for everybody that sounds interesting… > > Just my 2c. > > Mirja > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ From nobody Fri Jun 3 09:19:33 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE09912D590 for ; Fri, 3 Jun 2016 09:19:32 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 qUHDrZgRz4Za for ; Fri, 3 Jun 2016 09:19:31 -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 C389212B031 for ; Fri, 3 Jun 2016 09:09:33 -0700 (PDT) Received: from 148.58.125.91.dyn.plus.net ([91.125.58.148]:50827 helo=[192.168.0.10]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1b8rf9-00015s-AS; Fri, 03 Jun 2016 17:09:31 +0100 References: <20160603155257.1438.57036.idtracker@ietfa.amsl.com> To: TCP Prague List From: Bob Briscoe Message-ID: <5751ABBA.8030707@bobbriscoe.net> Date: Fri, 3 Jun 2016 17:09:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160603155257.1438.57036.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: marcelo bagnulo braun , "De Schepper, Koen \(Koen\)" Subject: [tcpPrague] New L4S problem statement: draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem-00.txt X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 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, 03 Jun 2016 16:19:32 -0000 Folks, We've just posted a problem statement for the proposed L4S BoF (or mini-BoF, or whatever it will end up as). We put every affected WG in the filename string of the draft! It's nearly all there, except some parts are in bullet form, so we can improve it over the next couple of weeks. In particular there is space for use-cases to be added, where we've currently only bullet listed some ideas. Please send comments and suggested text to add, to the tcpprague list, of offlist if you prefer. Bob On 03/06/16 16:52, internet-drafts@ietf.org wrote: > A new version of I-D, draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem-00.txt > has been successfully submitted by Bob Briscoe and posted to the > IETF repository. > > Name: draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem > Revision: 00 > Title: Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Problem Statement > Document date: 2016-06-03 > Group: Individual Submission > Pages: 17 > URL: https://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem-00.txt > Status: https://datatracker.ietf.org/doc/draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem/ > Htmlized: https://tools.ietf.org/html/draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem-00 > > > Abstract: > This document motivates a new service that the Internet could provide > to eventually replace best efforts for all traffic: Low Latency, Low > Loss, Scalable throughput (L4S). It is becoming common for all (or > most) applications being run by a user at any one time to require low > latency, but the only solution the IETF can offer for ultra-low > queuing latency is Diffserv, which only offers low latency for some > packets at the expense of others. Diffserv has also proved hard to > deploy widely end-to-end. > > In contrast, a zero-config incrementally deployable solution has been > demonstrated that keeps average queuing delay under a millisecond for > _all_ applications even under very heavy load; and it keeps > congestion loss to zero. At the same time it solves the long-running > problem with the scalability of TCP throughput. Even with a high > capacity broadband access, the resulting performance under load is > remarkably and consistently improved for applications such as > interactive video, conversational video, voice, Web, gaming, instant > messaging, remote desktop and cloud-based apps. This document > explains the underlying problems that have been preventing the > Internet from enjoying such performance improvements. It then > outlines the parts necessary for a solution and the steps that will > be needed to standardize them. > > > > > 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. > > The IETF Secretariat > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Fri Jun 3 13:10:53 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5139D12D980 for ; Fri, 3 Jun 2016 13:10:52 -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, 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 rPPLK7oUUObu for ; Fri, 3 Jun 2016 13:10:49 -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 EBB6D12D981 for ; Fri, 3 Jun 2016 13:10:48 -0700 (PDT) Received: from 148.58.125.91.dyn.plus.net ([91.125.58.148]:52010 helo=[192.168.0.10]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1b8vQc-0003mm-Df; Fri, 03 Jun 2016 21:10:46 +0100 References: <574EBEA2.8080705@bobbriscoe.net> <5751AD7D.6070807@bobbriscoe.net> From: Bob Briscoe To: TCP Prague List Message-ID: <5751E445.9020104@bobbriscoe.net> Date: Fri, 3 Jun 2016 21:10:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <5751AD7D.6070807@bobbriscoe.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: "De Schepper, Koen \(Koen\)" Subject: [tcpPrague] L4S BoF Proposal on the wiki X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 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, 03 Jun 2016 20:10:52 -0000 All, The L4S BoF proposal is here: https://trac.tools.ietf.org/bof/trac/wiki#Transport There's 4 hours left, if anyone wants to suggest any changes. I'll be off-line for a while, but I'll look at email before the cut-off. In the mean time, I'll formally send the request to Mirja (we can change the wiki in parallel until the deadline). Cheers Bob On 03/06/16 17:17, Bob Briscoe wrote: > Mirja, > > Status report on the BoF proposal for you & the list:... > > You will have seen we've uploaded a problem statement. > The BoF proposal is complete in theory, but completely absent on the > wiki. > I'll fill in the wiki in the next couple of hours. > > Sorry to everyone that this won't provide long to react to anything > they disagree with. So here's a summary of what will be there: > > The proposal is to have a non-WG-forming BoF, with a suggestion that > in practice it takes the form of a mini-BoF within TSV-AREA. > We are still putting it through as a BoF request, because we think it > is important that the IESG get a heads-up on this, rather than the > first they know being when RFCs start to appear two years later. Then > if it is decided to do a mini-BoF within TSVAREA, at least the > IESG/IAB can know to come along. > > We will suggest that the questions asked are: > 1/ Support this work? > 2/ Interested in helping implement, test, write, review, etc.? > We believe we should leave the question of how the work is organised > (across WGs? a new WG? a hybrid of the two? etc.) for the ADs, rather > than burn time in a meeting on that. > > One of the main purposes will be to demonstrate to the community that > there are people working on this, and others that are planning to. > Thank you for everyone who has volunteered to give short talks about > your current activity around L4S, and/or your plans. > > > > Bob > > > > On 01/06/16 20:31, Mirja Kühlewind wrote: >> Hi Bob, >> >>> Am 01.06.2016 um 12:53 schrieb Bob Briscoe : >>> >>> However, I've noticed that the discussion on this list seems to move >>> in fits and starts. >>> Can anyone suggest why? >> I believe it would help to foster discussion if someone (you) would >> send a problem statement to the list because right now there are a >> lot of people interesting in this topic where everybody might have >> his/her own idea what this is about. Having a common understanding of >> want we want is the first step. For me most of things I’ve seen so >> far are very wide spread and I guess there something for everybody >> that sounds interesting… >> >> Just my 2c. >> >> Mirja >> >> >> -- >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Fri Jun 10 04:48:55 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A57F212B069 for ; Fri, 10 Jun 2016 04:48:53 -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, 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 8eAyAxWxVAVy for ; Fri, 10 Jun 2016 04:48:51 -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 EE9A912D81C for ; Fri, 10 Jun 2016 04:48:50 -0700 (PDT) Received: from 148.58.125.91.dyn.plus.net ([91.125.58.148]:44022 helo=[192.168.0.10]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bBKvg-0006A2-Vr; Fri, 10 Jun 2016 12:48:49 +0100 To: Mirja Kuehlewind References: <575926D4.6010807@bobbriscoe.net> From: Bob Briscoe Message-ID: <575AA920.6050906@bobbriscoe.net> Date: Fri, 10 Jun 2016 12:48:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: Spencer DAWKINS , TCP Prague List Subject: [tcpPrague] Minor L4S BoF proposal updates X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jun 2016 11:48:53 -0000 Mirja, Since the BoF proposal deadline, I've made a couple of edits to the L4S BoF proposal: * Ingemar Johansson's agenda slot is confirmed (if you approve the BoF) - he's implemented a 1/p variant of RMCAT SCREAM for 4G/5G - very early days, but encouraging initial results. * I've added Lars as a potential second chair - obviously ultimately for you / Spencer to decide. Marcelo, Koen and I will be posting a -01 draft of our L4S Problem Statement in a couple of hours: * the couple of parts that were roughed out have been properly finished, * an ASCII art architecture figure added, * added quantification of the size of the problem and the performance of example solutions so far, based on testing. Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Fri Jun 10 09:35:25 2016 Return-Path: X-Original-To: tcpprague@ietf.org Delivered-To: tcpprague@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB5F12D63C; Fri, 10 Jun 2016 09:35:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160610163522.30445.47431.idtracker@ietfa.amsl.com> Date: Fri, 10 Jun 2016 09:35:22 -0700 Archived-At: Cc: cmorgan@amsl.com, ietf@kuehlewind.net, l4s-chairs@ietf.org, tcpprague@ietf.org Subject: [tcpPrague] l4s - New Meeting Session Request for IETF 96 X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jun 2016 16:35:23 -0000 A new meeting session request has just been submitted by Cindy Morgan, on behalf of the l4s working group. --------------------------------------------------------- Working Group Name: Low Latency Low Loss Scalable throughput Area Name: Transport Area Session Requester: Cindy Morgan Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 200 Conflicts to Avoid: First Priority: avtcore, iccrg, alto, aqm, dtn, ippm, mptcp, nfsv4, rmcat, taps, tcpinc, tcpm, tram, tsvwg Special Requests: --------------------------------------------------------- From nobody Sun Jun 12 16:21:26 2016 Return-Path: X-Original-To: tcpprague@ietf.org Delivered-To: tcpprague@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE59312D0BD; Sun, 12 Jun 2016 16:21:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160612232124.5430.5829.idtracker@ietfa.amsl.com> Date: Sun, 12 Jun 2016 16:21:24 -0700 Archived-At: Cc: philip.eardley@bt.com, ietf@kuehlewind.net, l4s-chairs@ietf.org, tcpprague@ietf.org Subject: [tcpPrague] l4s - Update to a Meeting Session Request for IETF 96 X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 12 Jun 2016 23:21:25 -0000 An update to a meeting session request has just been submitted by Philip Eardley, a Chair of the l4s working group. --------------------------------------------------------- Working Group Name: Low Latency Low Loss Scalable throughput Area Name: Transport Area Session Requester: Philip Eardley Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 200 Conflicts to Avoid: First Priority: avtcore iccrg alto aqm dtn ippm mptcp nfsv4 rmcat taps tcpinc tcpm tram tsvwg lmap Special Requests: --------------------------------------------------------- From nobody Mon Jun 13 01:27:50 2016 Return-Path: X-Original-To: tcpprague@ietf.org Delivered-To: tcpprague@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB0712D0DD; Mon, 13 Jun 2016 01:27:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160613082748.12402.30468.idtracker@ietfa.amsl.com> Date: Mon, 13 Jun 2016 01:27:48 -0700 Archived-At: Cc: ietf@kuehlewind.net, l4s-chairs@ietf.org, tcpprague@ietf.org Subject: [tcpPrague] l4s - Update to a Meeting Session Request for IETF 96 X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jun 2016 08:27:48 -0000 An update to a meeting session request has just been submitted by Mirja Kuehlewind, a TSV Area Director. --------------------------------------------------------- Working Group Name: Low Latency Low Loss Scalable throughput Area Name: Transport Area Session Requester: Mirja Kühlewind Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 200 Conflicts to Avoid: First Priority: tsvwg tcpm tcpinc taps rmcat mptcp aqm iccrg avtcore lmap irtfopen Special Requests: --------------------------------------------------------- From nobody Mon Jun 13 01:29:12 2016 Return-Path: X-Original-To: tcpprague@ietf.org Delivered-To: tcpprague@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A0712D13D; Mon, 13 Jun 2016 01:29:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160613082911.12379.84414.idtracker@ietfa.amsl.com> Date: Mon, 13 Jun 2016 01:29:11 -0700 Archived-At: Cc: ietf@kuehlewind.net, l4s-chairs@ietf.org, tcpprague@ietf.org Subject: [tcpPrague] l4s - Update to a Meeting Session Request for IETF 96 X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jun 2016 08:29:11 -0000 An update to a meeting session request has just been submitted by Mirja Kuehlewind, a TSV Area Director. --------------------------------------------------------- Working Group Name: Low Latency Low Loss Scalable throughput Area Name: Transport Area Session Requester: Mirja Kühlewind Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 200 Conflicts to Avoid: First Priority: irtfopen lmap avtcore iccrg aqm mptcp rmcat taps tcpinc tcpm tsvwg tsvarea quic plus Special Requests: --------------------------------------------------------- From nobody Mon Jun 13 01:34:41 2016 Return-Path: X-Original-To: tcpprague@ietf.org Delivered-To: tcpprague@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D768A12D0C1; Mon, 13 Jun 2016 01:34:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160613083438.12502.67061.idtracker@ietfa.amsl.com> Date: Mon, 13 Jun 2016 01:34:38 -0700 Archived-At: Cc: ietf@kuehlewind.net, l4s-chairs@ietf.org, tcpprague@ietf.org Subject: [tcpPrague] l4s - Update to a Meeting Session Request for IETF 96 X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jun 2016 08:34:39 -0000 An update to a meeting session request has just been submitted by Mirja Kuehlewind, a TSV Area Director. --------------------------------------------------------- Working Group Name: Low Latency Low Loss Scalable throughput Area Name: Transport Area Session Requester: Mirja Kühlewind Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 200 Conflicts to Avoid: First Priority: plus quic tsvarea tsvwg tcpm tcpinc taps rmcat mptcp aqm iccrg avtcore lmap irtfopen maprg NMLRG Special Requests: --------------------------------------------------------- From nobody Mon Jun 13 01:36:21 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA27812D129; Mon, 13 Jun 2016 01:36:19 -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, 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 1s7zsQ0SsgvE; Mon, 13 Jun 2016 01:36:17 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E51B12D0DD; Mon, 13 Jun 2016 01:36:17 -0700 (PDT) Received: from 148.58.125.91.dyn.plus.net ([91.125.58.148]:45482 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bCNLz-0007ob-Ig; Mon, 13 Jun 2016 09:36:15 +0100 To: "Mirja Kuehlewind (IETF)" , philip.eardley@bt.com, l4s-chairs@ietf.org References: <20160610163522.30445.47431.idtracker@ietfa.amsl.com> <575B4FAC.7070306@bobbriscoe.net> <7916F760-08CF-40BF-995E-3C01258897AB@kuehlewind.net> <3B44AE67-C080-49D9-AD75-46414598EB1B@kuehlewind.net> <2F4CC5CB-BB01-4D3D-923C-600C363B4326@kuehlewind.net> From: Bob Briscoe Message-ID: <575E707F.6000700@bobbriscoe.net> Date: Mon, 13 Jun 2016 09:36:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <2F4CC5CB-BB01-4D3D-923C-600C363B4326@kuehlewind.net> 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: TCP Prague List , spencerdawkins.ietf@gmail.com Subject: [tcpPrague] L4S scheduling conflicts (was: l4s - New Meeting Session Request for IETF 96) X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jun 2016 08:36:20 -0000 Mirja, L4S chairs, [Adding the tcpprague list - which contains the most important people who might have conflicts] Here's my thinking behind the conflict list: I put: "all Transport Area WGs, avtcore, iccrg", which resulted in the current conflicts list: Conflicts to Avoid: First Priority: avtcore, iccrg, alto, aqm, dtn, ippm, mptcp, nfsv4, rmcat, taps, tcpinc, tcpm, tram, tsvwg We have a list of WGs that we have already said L4S will interact with in the problem statement: * tsvwg, aqm, tcpm, rmcat, iccrg, avtcore * mptcp will be added in the next draft of the problem-statement (omission pointed out by Marcelo) I think we should keep the following: * dtn: addressing a very similar problem of ultra-low loss, ultra-low latency, but currently in a very different way * taps: l4s is disruptive to taps, because it offers a protocol that removes the queuing delay dimension from the requirements dilemma - potentially eventually for all transport protocols That leaves the following that could be trimmed: * alto, nfsv4, tcpinc, tram I think tcpinc should stay as a second (or even first) priority conflict, because of all the tcp experts who would be conflicted. Bob On 11/06/16 19:11, Mirja Kuehlewind (IETF) wrote: > Hi Phil, > > I anyway want to trim the conflict list (because currently there is more stuff on than needed). I guess you as chair should be able to do that as well. Please do so if you want. But please do it soon if possible :-) > > Mirja > > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Mon Jun 13 01:58:01 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2FF12D16D; Mon, 13 Jun 2016 01:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.347 X-Spam-Level: X-Spam-Status: No, score=-8.347 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=-1.426, 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 YssSabZLZc_D; Mon, 13 Jun 2016 01:57:58 -0700 (PDT) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3301012D147; Mon, 13 Jun 2016 01:57:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.26,466,1459839600"; d="asc'?scan'208";a="116659516" Received: from hioexcmbx04-prd.hq.netapp.com ([10.122.105.37]) by mx142-out.netapp.com with ESMTP; 13 Jun 2016 01:57:32 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Mon, 13 Jun 2016 01:57:24 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::837:3f3:c8b1:8d6f%21]) with mapi id 15.00.1156.000; Mon, 13 Jun 2016 01:57:24 -0700 From: "Eggert, Lars" To: Bob Briscoe Thread-Topic: L4S scheduling conflicts (was: l4s - New Meeting Session Request for IETF 96) Thread-Index: AQHRxU6lx4tziPMssEWan+8LLIziGJ/njfWA Date: Mon, 13 Jun 2016 08:57:24 +0000 Message-ID: References: <20160610163522.30445.47431.idtracker@ietfa.amsl.com> <575B4FAC.7070306@bobbriscoe.net> <7916F760-08CF-40BF-995E-3C01258897AB@kuehlewind.net> <3B44AE67-C080-49D9-AD75-46414598EB1B@kuehlewind.net> <2F4CC5CB-BB01-4D3D-923C-600C363B4326@kuehlewind.net> <575E707F.6000700@bobbriscoe.net> In-Reply-To: <575E707F.6000700@bobbriscoe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_91F018CB-66A6-49FC-844D-A85117683A39"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: Philip Eardley , "Mirja Kuehlewind \(IETF\)" , "l4s-chairs@ietf.org" , "spencerdawkins.ietf@gmail.com" , TCP Prague List Subject: Re: [tcpPrague] L4S scheduling conflicts (was: l4s - New Meeting Session Request for IETF 96) X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jun 2016 08:57:59 -0000 --Apple-Mail=_91F018CB-66A6-49FC-844D-A85117683A39 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, On 2016-06-13, at 10:36, Bob Briscoe wrote: > Here's my thinking behind the conflict list: > I put: "all Transport Area WGs, avtcore, iccrg", which resulted in the = current conflicts list: >=20 > Conflicts to Avoid: > First Priority: avtcore, iccrg, alto, aqm, dtn, ippm, mptcp, nfsv4, = rmcat, taps, tcpinc, tcpm, tram, tsvwg I'd put these as 2nd order: avtcore, ippm, tram And these even lower: alto, dtn, nfsv4 Lars >=20 >=20 > We have a list of WGs that we have already said L4S will interact with = in the problem statement: > * tsvwg, aqm, tcpm, rmcat, iccrg, avtcore >=20 > * mptcp will be added in the next draft of the problem-statement = (omission pointed out by Marcelo) >=20 > I think we should keep the following: > * dtn: addressing a very similar problem of ultra-low loss, ultra-low = latency, but currently in a very different way > * taps: l4s is disruptive to taps, because it offers a protocol that = removes the queuing delay dimension from the requirements dilemma - = potentially eventually for all transport protocols >=20 > That leaves the following that could be trimmed: > * alto, nfsv4, tcpinc, tram >=20 > I think tcpinc should stay as a second (or even first) priority = conflict, because of all the tcp experts who would be conflicted. >=20 >=20 > Bob >=20 > On 11/06/16 19:11, Mirja Kuehlewind (IETF) wrote: >> Hi Phil, >>=20 >> I anyway want to trim the conflict list (because currently there is = more stuff on than needed). I guess you as chair should be able to do = that as well. Please do so if you want. But please do it soon if = possible :-) >>=20 >> Mirja >>=20 >>=20 >=20 > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ >=20 --Apple-Mail=_91F018CB-66A6-49FC-844D-A85117683A39 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIbBAEBCAAGBQJXXnV6AAoJEFS1wwm/cMFXBroP9RAjLv44uIfXdvkWkGSxpKku UTAy9QVxL9BkSY5tAusxlUbUNCk9mx5MaGMIBn3zdJCgdYsJ0q9zuc/NdBGRB2Mz oxXrSzVfdLEckkwv+Qk3pcdIoNREUO9O0WcJ4R6jOZWu0gM3yKHGEicEvu6tw94h 0m2wqGXLIFOzbgNXt895NW0QbEUZsc38/yQsrhpN7tjihGiPHJTgMnwoAArDnXmx orrL1JB4+P3+8xF+rQABYoNafOtte5ifdrpgmP4hq9T0bEyRy45m9JoEGh4TqPIQ rtagu/PCOtGQfgeJwLAHiRboNFo+451Dwmk+2ZtFNZHmzDMXT2ZdNrguECgEUFoO POjJXuD4Tr5mxqS1SD1RlQxazWTsRWlfit29fnW0VLTZg+yMTWnV/EGqCEopp+Ow +xzuq2gz9MtGECWcCYDYkjp8On4UixZbW+5rieZ88491T7uMWaCW9HabqU1KeVb6 HV9RPLpyxkZOeMYA8wJRlPcAKvF8SwNc91vN9ia7vJRDifmFsNkrqxmgB59klfUW nUikuaHEWruadPrOVVT+1guYEpRs7NH3b2VP4bVQShCdkFzpoZ/0nddXKvVUUGFi hKGjTo3Jv3IXiqV8p4jmQuUzbAxLYwRDbG23o+OzGVJDU8Xl3G1JfPPOD7H89l3y LXzGRFBAyL/iNkEop+w= =9Oz1 -----END PGP SIGNATURE----- --Apple-Mail=_91F018CB-66A6-49FC-844D-A85117683A39-- From nobody Mon Jun 13 03:48:25 2016 Return-Path: X-Original-To: tcpprague@ietfa.amsl.com Delivered-To: tcpprague@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5719C12D0B3; Mon, 13 Jun 2016 03:48:24 -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 twlAcOU2phGV; Mon, 13 Jun 2016 03:48:22 -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 E6A7D12D0EE; Mon, 13 Jun 2016 03:48:21 -0700 (PDT) Received: from 148.58.125.91.dyn.plus.net ([91.125.58.148]:45756 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bCPPo-0005tS-4E; Mon, 13 Jun 2016 11:48:20 +0100 To: "Eggert, Lars" References: <20160610163522.30445.47431.idtracker@ietfa.amsl.com> <575B4FAC.7070306@bobbriscoe.net> <7916F760-08CF-40BF-995E-3C01258897AB@kuehlewind.net> <3B44AE67-C080-49D9-AD75-46414598EB1B@kuehlewind.net> <2F4CC5CB-BB01-4D3D-923C-600C363B4326@kuehlewind.net> <575E707F.6000700@bobbriscoe.net> From: Bob Briscoe Message-ID: <575E8F73.7010504@bobbriscoe.net> Date: Mon, 13 Jun 2016 11:48:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050805090406010808020904" 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: TCP Prague List , Philip Eardley , "Mirja Kuehlewind \(IETF\)" , "l4s-chairs@ietf.org" , "spencerdawkins.ietf@gmail.com" Subject: Re: [tcpPrague] L4S scheduling conflicts X-BeenThere: tcpprague@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jun 2016 10:48:24 -0000 This is a multi-part message in MIME format. --------------050805090406010808020904 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Lars, avtcore specified RFC 6679 (ECN in RTP), which is proposed standard and contains more specific uses of ECT(1) than any other RFC (even tho the ECT(1) parts have not been implemented as far as anyone can tell). RFC6679 is also referenced by 19 3GPP specs (9 reference it normatively). Bob On 13/06/16 09:57, Eggert, Lars wrote: > Hi, > > On 2016-06-13, at 10:36, Bob Briscoe wrote: >> Here's my thinking behind the conflict list: >> I put: "all Transport Area WGs, avtcore, iccrg", which resulted in the current conflicts list: >> >> Conflicts to Avoid: >> First Priority: avtcore, iccrg, alto, aqm, dtn, ippm, mptcp, nfsv4, rmcat, taps, tcpinc, tcpm, tram, tsvwg > I'd put these as 2nd order: avtcore, ippm, tram > > And these even lower: alto, dtn, nfsv4 > > Lars > >> >> We have a list of WGs that we have already said L4S will interact with in the problem statement: >> * tsvwg, aqm, tcpm, rmcat, iccrg, avtcore >> >> * mptcp will be added in the next draft of the problem-statement (omission pointed out by Marcelo) >> >> I think we should keep the following: >> * dtn: addressing a very similar problem of ultra-low loss, ultra-low latency, but currently in a very different way >> * taps: l4s is disruptive to taps, because it offers a protocol that removes the queuing delay dimension from the requirements dilemma - potentially eventually for all transport protocols >> >> That leaves the following that could be trimmed: >> * alto, nfsv4, tcpinc, tram >> >> I think tcpinc should stay as a second (or even first) priority conflict, because of all the tcp experts who would be conflicted. >> >> >> Bob >> >> On 11/06/16 19:11, Mirja Kuehlewind (IETF) wrote: >>> Hi Phil, >>> >>> I anyway want to trim the conflict list (because currently there is more stuff on than needed). I guess you as chair should be able to do that as well. Please do so if you want. But please do it soon if possible :-) >>> >>> Mirja >>> >>> >> -- >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ >> > > > _______________________________________________ > tcpPrague mailing list > tcpPrague@ietf.org > https://www.ietf.org/mailman/listinfo/tcpprague -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------050805090406010808020904 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Lars,

avtcore specified RFC 6679 (ECN in RTP), which is proposed standard and contains more specific uses of ECT(1) than any other RFC (even tho the ECT(1) parts have not been implemented as far as anyone can tell). RFC6679 is also referenced by 19 3GPP specs (9 reference it normatively).


Bob

On 13/06/16 09:57, Eggert, Lars wrote:
Hi,

On 2016-06-13, at 10:36, Bob Briscoe <research@bobbriscoe.net> wrote:

Here's my thinking behind the conflict list:
I put: "all Transport Area WGs, avtcore, iccrg", which resulted in the current conflicts list:

Conflicts to Avoid:
First Priority: avtcore, iccrg, alto, aqm, dtn, ippm, mptcp, nfsv4, rmcat, taps, tcpinc, tcpm, tram, tsvwg

I'd put these as 2nd order: avtcore, ippm, tram

And these even lower: alto, dtn, nfsv4

Lars



We have a list of WGs that we have already said L4S will interact with in the problem statement:
* tsvwg, aqm, tcpm, rmcat, iccrg, avtcore

* mptcp will be added in the next draft of the problem-statement (omission pointed out by Marcelo)

I think we should keep the following:
* dtn: addressing a very similar problem of ultra-low loss, ultra-low latency, but currently in a very different way
* taps: l4s is disruptive to taps, because it offers a protocol that removes the queuing delay dimension from the requirements dilemma - potentially eventually for all transport protocols

That leaves the following that could be trimmed:
* alto, nfsv4, tcpinc, tram

I think tcpinc should stay as a second (or even first) priority conflict, because of all the tcp experts who would be conflicted.


Bob

On 11/06/16 19:11, Mirja Kuehlewind (IETF) wrote:

Hi Phil,

I anyway want to trim the conflict list (because currently there is more stuff on than needed). I guess you as chair should be able to do that as well. Please do so if you want. But please do it soon if possible :-)

Mirja



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



      

      

      

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


    

    

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

  


--------------050805090406010808020904--


From nobody Mon Jun 13 07:41:04 2016
Return-Path: 
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEECA12D696 for ; Mon, 13 Jun 2016 07:41: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 l7tw281GmH-J for ; Mon, 13 Jun 2016 07:41:00 -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 D14B212B051 for ; Mon, 13 Jun 2016 07:40:59 -0700 (PDT)
Received: from 148.58.125.91.dyn.plus.net ([91.125.58.148]:46553 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bCT2v-0002W6-Rw; Mon, 13 Jun 2016 15:40:58 +0100
References: <20160613142347.12387.63962.idtracker@ietfa.amsl.com>
To: TCP Prague List 
From: Bob Briscoe 
Message-ID: <575EC5F8.1090906@bobbriscoe.net>
Date: Mon, 13 Jun 2016 15:40:56 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <20160613142347.12387.63962.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------020607010305070700090208"
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: Marcelo Bagnulo , Koen De Schepper 
Subject: [tcpPrague] New L4S Problem Statement: draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem-01.txt
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.17
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, 13 Jun 2016 14:41:03 -0000

This is a multi-part message in MIME format.
--------------020607010305070700090208
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Folks,

We've just submitted a new version of our problem statement for L4S.

We'd be particularly interested to hear from anyone who has a use-case - 
either one that isn't mentioned already, or where they think one that is 
mentioned could be written better/differently.
If they would like to describe your use-case in a couple of sentences, 
we could add it.


*Diffs**
*You can get all the diffs via the links at the top of 
https://tools.ietf.org/html/draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem-01
The main diffs are:
* Abstract: Completely new (previous one talked about L4S service as if 
the network alone provided it, without mentioning the key role of the 
hosts);
* Quantification: of the problem and  quantified claims about example 
solutions
* Added ASCII art architecture, and made numbering of parts, and of 
proposed deliverables consistent
* Added more definitions of terminology
* Completed sections that were previously only bulletted:
   - 2 Rationale
     2.1 Why These Primary Components?
     2.2 Why Not Alternative Approaches?
   - 3.1 Use-Cases
   - 5.3 ECN Integrity
* Explained tables of deliverables in appendix



Bob

On 13/06/16 15:23, internet-drafts@ietf.org wrote:
> A new version of I-D, draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem-01.txt
> has been successfully submitted by Bob Briscoe and posted to the
> IETF repository.
>
> Name:		draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem
> Revision:	01
> Title:		Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Problem Statement
> Document date:	2016-06-10
> Group:		Individual Submission
> Pages:		23
> URL:            https://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem/
> Htmlized:       https://tools.ietf.org/html/draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem-01
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem-01
>
> Abstract:
>     This document motivates a new service that the Internet could provide
>     to eventually replace best efforts for all traffic: Low Latency, Low
>     Loss, Scalable throughput (L4S).  It is becoming common for _all_ (or
>     most) applications being run by a user at any one time to require low
>     latency.  However, the only solution the IETF can offer for ultra-low
>     queuing delay is Diffserv, which only favours a minority of packets
>     at the expense of others.  In extensive testing the new L4S service
>     keeps average queuing delay under a millisecond for _all_
>     applications even under very heavy load, without sacrificing
>     utilization; and it keeps congestion loss to zero.  It is becoming
>     widely recognized that adding more access capacity gives diminishing
>     returns, because latency is becoming the critical problem.  Even with
>     a high capacity broadband access, the reduced latency of L4S
>     remarkably and consistently improves performance under load for
>     applications such as interactive video, conversational video, voice,
>     Web, gaming, instant messaging, remote desktop and cloud-based apps
>     (even when all being used at once over the same access link).  The
>     insight is that the root cause of queuing delay is in TCP, not in the
>     queue.  By fixing the sending TCP (and other transports) queuing
>     latency becomes so much better than today that operators will want to
>     deploy the network part of L4S to enable new products and services.
>     Further, the network part is simple to deploy - incrementally with
>     zero-config.  Both parts, sender and network, ensure coexistence with
>     other legacy traffic.  At the same time L4S solves the long-
>     recognized problem with the future scalability of TCP throughput.
>
>     This document explains the underlying problems that have been
>     preventing the Internet from enjoying such performance improvements.
>     It then outlines the parts necessary for a solution and the steps
>     that will be needed to standardize them.  It points out opportunities
>     that will open up, and sets out some likely use-cases, including
>     ultra-low latency interaction with cloud processing over the public
>     Internet.
>
>                                                                                    
>
>
> 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.
>
> The IETF Secretariat
>

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


--------------020607010305070700090208
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Folks,

    

    We've just submitted a new version of our problem statement for L4S.

    

    We'd be particularly interested to hear from anyone who has a
    use-case - either one that isn't mentioned already, or where they
    think one that is mentioned could be written better/differently. 

    If they would like to describe your use-case in a couple of
    sentences, we could add it.

    

    

    Diffs

    You can get all the diffs via the links at the top of
https://tools.ietf.org/html/draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem-01

    The main diffs are:

    * Abstract: Completely new (previous one talked about L4S service as
    if the network alone provided it, without mentioning the key role of
    the hosts);

    * Quantification: of the problem and  quantified claims about
    example solutions

    * Added ASCII art architecture, and made numbering of parts, and of
    proposed deliverables consistent

    * Added more definitions of terminology

    * Completed sections that were previously only bulletted:

      - 2 Rationale

        2.1 Why These Primary Components?

        2.2 Why Not Alternative Approaches?

      - 3.1 Use-Cases

      - 5.3 ECN Integrity

    * Explained tables of deliverables in appendix

    

    

    

    Bob

    

    
On 13/06/16 15:23,
      internet-drafts@ietf.org wrote:

    

    

      
A new version of I-D, draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem-01.txt
has been successfully submitted by Bob Briscoe and posted to the
IETF repository.

Name:		draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem
Revision:	01
Title:		Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Problem Statement
Document date:	2016-06-10
Group:		Individual Submission
Pages:		23
URL:            https://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem-01.txt
Status:         https://datatracker.ietf.org/doc/draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem/
Htmlized:       https://tools.ietf.org/html/draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem-01

Abstract:
   This document motivates a new service that the Internet could provide
   to eventually replace best efforts for all traffic: Low Latency, Low
   Loss, Scalable throughput (L4S).  It is becoming common for _all_ (or
   most) applications being run by a user at any one time to require low
   latency.  However, the only solution the IETF can offer for ultra-low
   queuing delay is Diffserv, which only favours a minority of packets
   at the expense of others.  In extensive testing the new L4S service
   keeps average queuing delay under a millisecond for _all_
   applications even under very heavy load, without sacrificing
   utilization; and it keeps congestion loss to zero.  It is becoming
   widely recognized that adding more access capacity gives diminishing
   returns, because latency is becoming the critical problem.  Even with
   a high capacity broadband access, the reduced latency of L4S
   remarkably and consistently improves performance under load for
   applications such as interactive video, conversational video, voice,
   Web, gaming, instant messaging, remote desktop and cloud-based apps
   (even when all being used at once over the same access link).  The
   insight is that the root cause of queuing delay is in TCP, not in the
   queue.  By fixing the sending TCP (and other transports) queuing
   latency becomes so much better than today that operators will want to
   deploy the network part of L4S to enable new products and services.
   Further, the network part is simple to deploy - incrementally with
   zero-config.  Both parts, sender and network, ensure coexistence with
   other legacy traffic.  At the same time L4S solves the long-
   recognized problem with the future scalability of TCP throughput.

   This document explains the underlying problems that have been
   preventing the Internet from enjoying such performance improvements.
   It then outlines the parts necessary for a solution and the steps
   that will be needed to standardize them.  It points out opportunities
   that will open up, and sets out some likely use-cases, including
   ultra-low latency interaction with cloud processing over the public
   Internet.

                                                                                  


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.

The IETF Secretariat



    

    

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

  


--------------020607010305070700090208--


From nobody Wed Jun 15 10:40:16 2016
Return-Path: 
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A04B12D7A6 for ; Wed, 15 Jun 2016 10:40:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.626
X-Spam-Level: 
X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 5-eutpFiY8HK for ; Wed, 15 Jun 2016 10:40:12 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id C5C1D12D5E3 for ; Wed, 15 Jun 2016 10:40:12 -0700 (PDT)
Received: from dhcp-207-155.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:cdb2:4850:cc4a:7812]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id A58261B00257; Wed, 15 Jun 2016 18:40:11 +0100 (BST)
References: <574EBEA2.8080705@bobbriscoe.net> <20160601152908.GB1754@verdi> <574F2A2D.9070407@bobbriscoe.net> <574F4F29.9040409@bobbriscoe.net> <20160601215312.GA25116@verdi>
To: John Leslie , Bob Briscoe 
From: Gorry Fairhurst 
Organization: The University of Aberdeen is a charity registered in Scotland,  No SC013683.
Message-ID: <0898e249-03dd-aff9-7179-03cc8642efea@erg.abdn.ac.uk>
Date: Wed, 15 Jun 2016 18:40:11 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <20160601215312.GA25116@verdi>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: TCP Prague List 
Subject: Re: [tcpPrague] Enough energy for an L4S/TCP Prague BoF?
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
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: Wed, 15 Jun 2016 17:40:15 -0000

This topic may well fit within the scope of TSVWG.We could in principle 
consider such a discussion, *IF* that's the best use of face-to-face 
time at the meeting.

Since L4S is approved, please discuss the topics there.

Gorry


On 01/06/2016 22:53, John Leslie wrote:
> Bob Briscoe  wrote:
>>
>> John, Gorry,
>>
>> A random new thought...
>
>    (I'm still working on a reply to Bob's earlier email today: I'm
> tending to make it a private reply since I'm not seeing a lot of interest
> in discussing it on the tcpprague list.)
>
>> Another mechanism I've seen for this sort of thing is a mini-BoF within
>> an existing WG agenda.
>
>    I'm not aware of any rules pertaining to such a mini-BoF -- I'd guess
> the WGCs are entitled to call a section of their WG session a "mini-BoF"
> and operate under near-BoF rules...
>
>> Am I correct that a mini-BoF is appropriate for extending a WG's charter
>> in a more major direction than just adding one doc, and/or where it's
>> not clear whether a new WG might be needed instead?
>> It could possibly be a tsvwg mini-BoF.
>
>    ISTM that is up to the TSVWG chairs.
>
>> Or perhaps a joint tcpm, tsvwg, aqm mini-BoF, if such a thing exists?
>
>    I really doubt such a thing exists.
>
>    I'd be happy to see what Bob is suggesting as part of a TSVWG agenda.
>
> --
> John Leslie 
>
> _______________________________________________
> tcpPrague mailing list
> tcpPrague@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpprague
>


From nobody Thu Jun 16 00:34:28 2016
Return-Path: 
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E0412B01B for ; Thu, 16 Jun 2016 00:34:27 -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, 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 xCJyPqGHZdNz for ; Thu, 16 Jun 2016 00:34:24 -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 7091612B01C for ; Thu, 16 Jun 2016 00:34:24 -0700 (PDT)
Received: from 148.58.125.91.dyn.plus.net ([91.125.58.148]:50478 helo=[192.168.0.10]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bDRok-000730-B1; Thu, 16 Jun 2016 08:34:22 +0100
To: gorry@erg.abdn.ac.uk
References: <574EBEA2.8080705@bobbriscoe.net> <20160601152908.GB1754@verdi> <574F2A2D.9070407@bobbriscoe.net> <574F4F29.9040409@bobbriscoe.net> <20160601215312.GA25116@verdi> <0898e249-03dd-aff9-7179-03cc8642efea@erg.abdn.ac.uk>
From: Bob Briscoe 
Message-ID: <5762567D.8010609@bobbriscoe.net>
Date: Thu, 16 Jun 2016 08:34:21 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <0898e249-03dd-aff9-7179-03cc8642efea@erg.abdn.ac.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Cc: John Leslie , TCP Prague List 
Subject: Re: [tcpPrague] Enough energy for an L4S/TCP Prague BoF?
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 16 Jun 2016 07:34:27 -0000

Gorry,

Thank you for this - v useful.

I would like to get a sense of people's opinion on a particular 
political/procedural question that John L has raise that I think will be 
central. And you may have a better feel for 'public opinion' on this 
than me...

I expect any L4S aqm algos and any congestion control algos to be 
experimental track.
However, in order to be experimented with on the public Internet, they 
will need to distinguish their packets with an identifier.
ECT(1) is the leading contender, complemented by CE as the marking.{Note 1}

There are many pre-existing standards track docs {Note 2} that describe 
usage of ECT(1), based on the assumption that it was an experimental nonce.
A Proposed Standard RFC would be needed to update these PSs.

John L suggests (if I understand it correctly) a PS that makes space for 
experiments by reserving ECT(1) again, without redefining it for any new 
purpose (I guess it would mention L4S non-normatively). This RFC would 
be written to update all the mentioned PS RFCs. I assume he is proposing 
that then a new definition of ECT(1) for L4S could be written as a new 
experimental track use of this newly reserved codepoint.

a) Is this a feasible way to evolve these proposed standards?
b) Do you think there might be support for this?

One problem I see:
* L4S needs to redefine the semantics of both ECT(1) /and/ CE, with the 
definition of CE shared between L4S and Classic flows. {Note 3}
   We may have to somehow word the "John-L-proposed-PS" to allow this?


Bob

{Note 1} There are no perfect choices (the choices and their compromises 
are listed in draft-briscoe-tsvwg-ecn-l4s-id).
{Note 2} Listed under "the standardization problem" in our L4S problem 
statement draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem.
                Also, quoting from the above l4s-id draft (which is 
written as intended for the experimental track):

"  Therefore, if the experiment is successful and a descendant of this
    document proceeds to the standards track, it would be expected to
    update the specification of ECN in IP [RFC3168].  It would also
    update the transport behaviour when using ECN in the standards track
    RFCs listed in Section 2.3 (i.e.  ECN in TCP [RFC3168], in SCTP
    [RFC4960], in RTP [RFC6679], and in DCCP [RFC4340]).
"
{Note 3} Hosts understand which meaning of CE is intended, because they 
have per-flow context. For the network, the l4s-id draft proposes that a 
stateless L4S-capable classifier classifies CE as L4S. Any ECN-capable 
queue can still re-mark either ECT(0) or ECT(1) to CE.
This last point is no change from RFC3168. But the first two points 
/are/ changes to the PSs.



On 15/06/16 18:40, Gorry Fairhurst wrote:
>
> This topic may well fit within the scope of TSVWG.We could in 
> principle consider such a discussion, *IF* that's the best use of 
> face-to-face time at the meeting.
>
> Since L4S is approved, please discuss the topics there.
>
> Gorry
>
>
> On 01/06/2016 22:53, John Leslie wrote:
>> Bob Briscoe  wrote:
>>>
>>> John, Gorry,
>>>
>>> A random new thought...
>>
>>    (I'm still working on a reply to Bob's earlier email today: I'm
>> tending to make it a private reply since I'm not seeing a lot of 
>> interest
>> in discussing it on the tcpprague list.)
>>
>>> Another mechanism I've seen for this sort of thing is a mini-BoF within
>>> an existing WG agenda.
>>
>>    I'm not aware of any rules pertaining to such a mini-BoF -- I'd guess
>> the WGCs are entitled to call a section of their WG session a "mini-BoF"
>> and operate under near-BoF rules...
>>
>>> Am I correct that a mini-BoF is appropriate for extending a WG's 
>>> charter
>>> in a more major direction than just adding one doc, and/or where it's
>>> not clear whether a new WG might be needed instead?
>>> It could possibly be a tsvwg mini-BoF.
>>
>>    ISTM that is up to the TSVWG chairs.
>>
>>> Or perhaps a joint tcpm, tsvwg, aqm mini-BoF, if such a thing exists?
>>
>>    I really doubt such a thing exists.
>>
>>    I'd be happy to see what Bob is suggesting as part of a TSVWG agenda.
>>
>> -- 
>> John Leslie 
>>
>> _______________________________________________
>> tcpPrague mailing list
>> tcpPrague@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpprague
>>
>
> _______________________________________________
> tcpPrague mailing list
> tcpPrague@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpprague
>
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/


From nobody Thu Jun 16 05:48:25 2016
Return-Path: 
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03BA212D594 for ; Thu, 16 Jun 2016 05:48:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level: 
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 G_0yuYhrHpCJ for ; Thu, 16 Jun 2016 05:48:22 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id CBD4312D195 for ; Thu, 16 Jun 2016 05:48:21 -0700 (PDT)
Received: from dhcp-207-155.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:cdb2:4850:cc4a:7812]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 8EB251B001C0; Thu, 16 Jun 2016 13:48:20 +0100 (BST)
References: <574EBEA2.8080705@bobbriscoe.net> <20160601152908.GB1754@verdi> <574F2A2D.9070407@bobbriscoe.net> <574F4F29.9040409@bobbriscoe.net> <20160601215312.GA25116@verdi> <0898e249-03dd-aff9-7179-03cc8642efea@erg.abdn.ac.uk> <5762567D.8010609@bobbriscoe.net>
To: Bob Briscoe 
From: Gorry Fairhurst 
Organization: The University of Aberdeen is a charity registered in Scotland,  No SC013683.
Message-ID: <3f8fa637-17b5-853b-b835-db486a2a69f6@erg.abdn.ac.uk>
Date: Thu, 16 Jun 2016 13:48:11 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <5762567D.8010609@bobbriscoe.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: John Leslie , TCP Prague List 
Subject: Re: [tcpPrague] Enough energy for an L4S/TCP Prague BoF?
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
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: Thu, 16 Jun 2016 12:48:24 -0000

Hi Bob,

As it currently stands, I think a proposal to change the meaning of the 
ECN base spec should come to TSVWG, as should updating the experimental 
codepoint use currently assigned to ECN-NONCE. This would mean 
re-defining ECT(0) as not equivalent to ECT(1) within the default (BE) 
diffserv class - currently this is only permitted as an alternate behaviour.

I think it could perhaps be argued that the meaning of CE is not 
significantly changed, rather the marking behaviour and interpretation 
would be updated for endpoints using the new proposed method. A short 
draft that notes the impact on existing RFCs would be good as a step 
forward.

For the moment, let's first discuss at the BoF what is needed - deciding 
where to get standards progressed comes later.

Gorry

On 16/06/2016 08:34, Bob Briscoe wrote:
> Gorry,
>
> Thank you for this - v useful.
>
> I would like to get a sense of people's opinion on a particular
> political/procedural question that John L has raise that I think will be
> central. And you may have a better feel for 'public opinion' on this
> than me...
>
> I expect any L4S aqm algos and any congestion control algos to be
> experimental track.
 >
> However, in order to be experimented with on the public Internet, they
> will need to distinguish their packets with an identifier.
> ECT(1) is the leading contender, complemented by CE as the marking.{Note 1}
>
> There are many pre-existing standards track docs {Note 2} that describe
> usage of ECT(1), based on the assumption that it was an experimental nonce.
> A Proposed Standard RFC would be needed to update these PSs.
>
> John L suggests (if I understand it correctly) a PS that makes space for
> experiments by reserving ECT(1) again, without redefining it for any new
> purpose (I guess it would mention L4S non-normatively). This RFC would
> be written to update all the mentioned PS RFCs. I assume he is proposing
> that then a new definition of ECT(1) for L4S could be written as a new
> experimental track use of this newly reserved codepoint.
>
> a) Is this a feasible way to evolve these proposed standards?
> b) Do you think there might be support for this?
>
> One problem I see:
> * L4S needs to redefine the semantics of both ECT(1) /and/ CE, with the
> definition of CE shared between L4S and Classic flows. {Note 3}
>   We may have to somehow word the "John-L-proposed-PS" to allow this?
>
>
> Bob
>
> {Note 1} There are no perfect choices (the choices and their compromises
> are listed in draft-briscoe-tsvwg-ecn-l4s-id).
> {Note 2} Listed under "the standardization problem" in our L4S problem
> statement draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem.
>                Also, quoting from the above l4s-id draft (which is
> written as intended for the experimental track):
>
> "  Therefore, if the experiment is successful and a descendant of this
>    document proceeds to the standards track, it would be expected to
>    update the specification of ECN in IP [RFC3168].  It would also
>    update the transport behaviour when using ECN in the standards track
>    RFCs listed in Section 2.3 (i.e.  ECN in TCP [RFC3168], in SCTP
>    [RFC4960], in RTP [RFC6679], and in DCCP [RFC4340]).
> "
> {Note 3} Hosts understand which meaning of CE is intended, because they
> have per-flow context. For the network, the l4s-id draft proposes that a
> stateless L4S-capable classifier classifies CE as L4S. Any ECN-capable
> queue can still re-mark either ECT(0) or ECT(1) to CE.
> This last point is no change from RFC3168. But the first two points
> /are/ changes to the PSs.
>
>
>
> On 15/06/16 18:40, Gorry Fairhurst wrote:
>>
>> This topic may well fit within the scope of TSVWG.We could in
>> principle consider such a discussion, *IF* that's the best use of
>> face-to-face time at the meeting.
>>
>> Since L4S is approved, please discuss the topics there.
>>
>> Gorry
>>
>>
>> On 01/06/2016 22:53, John Leslie wrote:
>>> Bob Briscoe  wrote:
>>>>
>>>> John, Gorry,
>>>>
>>>> A random new thought...
>>>
>>>    (I'm still working on a reply to Bob's earlier email today: I'm
>>> tending to make it a private reply since I'm not seeing a lot of
>>> interest
>>> in discussing it on the tcpprague list.)
>>>
>>>> Another mechanism I've seen for this sort of thing is a mini-BoF within
>>>> an existing WG agenda.
>>>
>>>    I'm not aware of any rules pertaining to such a mini-BoF -- I'd guess
>>> the WGCs are entitled to call a section of their WG session a "mini-BoF"
>>> and operate under near-BoF rules...
>>>
>>>> Am I correct that a mini-BoF is appropriate for extending a WG's
>>>> charter
>>>> in a more major direction than just adding one doc, and/or where it's
>>>> not clear whether a new WG might be needed instead?
>>>> It could possibly be a tsvwg mini-BoF.
>>>
>>>    ISTM that is up to the TSVWG chairs.
>>>
>>>> Or perhaps a joint tcpm, tsvwg, aqm mini-BoF, if such a thing exists?
>>>
>>>    I really doubt such a thing exists.
>>>
>>>    I'd be happy to see what Bob is suggesting as part of a TSVWG agenda.
>>>
>>> --
>>> John Leslie 
>>>
>>> _______________________________________________
>>> tcpPrague mailing list
>>> tcpPrague@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tcpprague
>>>
>>
>> _______________________________________________
>> tcpPrague mailing list
>> tcpPrague@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpprague
>>
>> --
>> ________________________________________________________________
>> Bob Briscoe                               http://bobbriscoe.net/
>
> _______________________________________________
> tcpPrague mailing list
> tcpPrague@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpprague
>


From nobody Thu Jun 16 06:02:43 2016
Return-Path: 
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05EC212D14F for ; Thu, 16 Jun 2016 06:02:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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] 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 1gqo5CvTT71t for ; Thu, 16 Jun 2016 06:02:34 -0700 (PDT)
Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::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 67A5B12D594 for ; Thu, 16 Jun 2016 06:02:34 -0700 (PDT)
Received: by mail-yw0-x234.google.com with SMTP id v137so41878040ywa.3 for ; Thu, 16 Jun 2016 06:02:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EdqAzjh3oY3ThUJnPmIY3rCYAYICkXHmosRgIUbwQYY=; b=HmjaGC7OL/R4RCiFNfON503bd9NyOU1sua+WEFpYJ3b1jd2vc5VSO/E9tywBTtU5t2 5RlHskewEGpTpuhATun2Xhl3laOHfi8HYez80JTKeHG0KIhpX0FhWcQnsqKPFB/0ME9M Oyboxgif3lRuF0ht+oQbpHFAmi2tXamk+lqBxabh5zFOHeY4e6vqEfFLqmuYZ6dJG6g6 eP4UCwzS1mge6s4sFOuggiVfpq2bLRUbj/3LbQLFq6hSggYgyg5GOFIBqxjaCM8m+xOi A1U36t5MFAm66e7aFDXshqdVMmK+/X50N4U1jY10KbMGAGTrqfHr6A0hBG+fM8oWYNTW xStg==
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:from:date :message-id:subject:to:cc; bh=EdqAzjh3oY3ThUJnPmIY3rCYAYICkXHmosRgIUbwQYY=; b=EpVXH2rhlD7pe81jiBKgfbDborUyKzJcoF2ts5BFTjl9XVdPC7Jb6MSny5Bx78739V 2DP2OtuUF2KqHBgWc6TWQEfAMBssE/oa1rU7vSDTafb0rYZXCZpDrglhYdR/USmZMER9 IWOGlXzKTveCmJjCUiL5ElGHs1TCZpWxI9/PhHSdGAqi/FAI+2Xou6ZaihC41SiX+XvI JuFDfx+PD/jp+l/P37tjmwRQTDMiKz360FlsU0OwBagsHcdiGZUkZTRQskf5vYT8TgWq TAukT+f2dIOS+DMVYQxX9iZiHzfAbybhFSPxwEQmfr9zEXqdpoqyczQbRrOTUz7d9c8I +EOw==
X-Gm-Message-State: ALyK8tLtWfvgNfVIicZDVjbSfH4B+ZYdGPikd7A9uy/MMGiRoCKTvFyGoqbD1SyTaDlKuaCHLTnzUbR7qdD70w==
X-Received: by 10.37.230.65 with SMTP id d62mr589606ybh.111.1466082153640; Thu, 16 Jun 2016 06:02:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.101.84 with HTTP; Thu, 16 Jun 2016 06:02:32 -0700 (PDT)
In-Reply-To: <3f8fa637-17b5-853b-b835-db486a2a69f6@erg.abdn.ac.uk>
References: <574EBEA2.8080705@bobbriscoe.net> <20160601152908.GB1754@verdi> <574F2A2D.9070407@bobbriscoe.net> <574F4F29.9040409@bobbriscoe.net> <20160601215312.GA25116@verdi> <0898e249-03dd-aff9-7179-03cc8642efea@erg.abdn.ac.uk> <5762567D.8010609@bobbriscoe.net> <3f8fa637-17b5-853b-b835-db486a2a69f6@erg.abdn.ac.uk>
From: Spencer Dawkins at IETF 
Date: Thu, 16 Jun 2016 08:02:32 -0500
Message-ID: 
To: "gorry@erg.abdn.ac.uk" 
Content-Type: multipart/alternative; boundary=94eb2c0a915afab70a053564d9db
Archived-At: 
Cc: Bob Briscoe , John Leslie , TCP Prague List 
Subject: Re: [tcpPrague] Enough energy for an L4S/TCP Prague BoF?
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 16 Jun 2016 13:02:40 -0000

--94eb2c0a915afab70a053564d9db
Content-Type: text/plain; charset=UTF-8

Hi, Bob and Gorry,

On Thu, Jun 16, 2016 at 7:48 AM, Gorry Fairhurst 
wrote:

> Hi Bob,
>
> As it currently stands, I think a proposal to change the meaning of the
> ECN base spec should come to TSVWG, as should updating the experimental
> codepoint use currently assigned to ECN-NONCE. This would mean re-defining
> ECT(0) as not equivalent to ECT(1) within the default (BE) diffserv class -
> currently this is only permitted as an alternate behaviour.
>
> I think it could perhaps be argued that the meaning of CE is not
> significantly changed, rather the marking behaviour and interpretation
> would be updated for endpoints using the new proposed method. A short draft
> that notes the impact on existing RFCs would be good as a step forward.
>
> For the moment, let's first discuss at the BoF what is needed - deciding
> where to get standards progressed comes later.


I agree with this (but see below) ...


> Gorry
>
>
> On 16/06/2016 08:34, Bob Briscoe wrote:
>
>> Gorry,
>>
>> Thank you for this - v useful.
>>
>> I would like to get a sense of people's opinion on a particular
>> political/procedural question that John L has raise that I think will be
>> central. And you may have a better feel for 'public opinion' on this
>> than me...
>>
>> I expect any L4S aqm algos and any congestion control algos to be
>> experimental track.
>>
> >
>
>> However, in order to be experimented with on the public Internet, they
>> will need to distinguish their packets with an identifier.
>> ECT(1) is the leading contender, complemented by CE as the marking.{Note
>> 1}
>
>
So, just to make sure I understand the proposal ... because I'm probably
confused.

I would support publication of these algorithms as Experimental, if that's
what is proposed.

Are you thinking the experiment is, that devices on the public Internet are
upgraded to provide this new functionality even if they aren't
participating in the experiment, and then this new functionality is then
experimented with, and the result of the experiment might be "now we know
why that's a bad idea, so we're not going to standardize it", so then the
devices revert to previous functionality?

The way I thought this worked was that when you experiment with a
standards-track protocol, the Experimental RFC is supported only by devices
that are participating in the experiment, and the Experimental RFC doesn't
update the standards-track RFC(s) until the experiment succeeds, and then
the Experimental RFC is republished as a standards-track RFC that updates
the previous standards-track RFCs. If you decide the experiment is a bad
idea, only devices that opt in to the experiment need to revert to previous
functionality.

Are you thinking that wouldn't work here?

Thanks,

Spencer


> There are many pre-existing standards track docs {Note 2} that describe
>> usage of ECT(1), based on the assumption that it was an experimental
>> nonce.
>> A Proposed Standard RFC would be needed to update these PSs.
>>
>> John L suggests (if I understand it correctly) a PS that makes space for
>> experiments by reserving ECT(1) again, without redefining it for any new
>> purpose (I guess it would mention L4S non-normatively). This RFC would
>> be written to update all the mentioned PS RFCs. I assume he is proposing
>> that then a new definition of ECT(1) for L4S could be written as a new
>> experimental track use of this newly reserved codepoint.
>>
>> a) Is this a feasible way to evolve these proposed standards?
>> b) Do you think there might be support for this?
>>
>> One problem I see:
>> * L4S needs to redefine the semantics of both ECT(1) /and/ CE, with the
>> definition of CE shared between L4S and Classic flows. {Note 3}
>>   We may have to somehow word the "John-L-proposed-PS" to allow this?
>>
>>
>> Bob
>>
>> {Note 1} There are no perfect choices (the choices and their compromises
>> are listed in draft-briscoe-tsvwg-ecn-l4s-id).
>> {Note 2} Listed under "the standardization problem" in our L4S problem
>> statement draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem.
>>                Also, quoting from the above l4s-id draft (which is
>> written as intended for the experimental track):
>>
>> "  Therefore, if the experiment is successful and a descendant of this
>>    document proceeds to the standards track, it would be expected to
>>    update the specification of ECN in IP [RFC3168].  It would also
>>    update the transport behaviour when using ECN in the standards track
>>    RFCs listed in Section 2.3 (i.e.  ECN in TCP [RFC3168], in SCTP
>>    [RFC4960], in RTP [RFC6679], and in DCCP [RFC4340]).
>> "
>> {Note 3} Hosts understand which meaning of CE is intended, because they
>> have per-flow context. For the network, the l4s-id draft proposes that a
>> stateless L4S-capable classifier classifies CE as L4S. Any ECN-capable
>> queue can still re-mark either ECT(0) or ECT(1) to CE.
>> This last point is no change from RFC3168. But the first two points
>> /are/ changes to the PSs.
>>
>>
>>
>> On 15/06/16 18:40, Gorry Fairhurst wrote:
>>
>>>
>>> This topic may well fit within the scope of TSVWG.We could in
>>> principle consider such a discussion, *IF* that's the best use of
>>> face-to-face time at the meeting.
>>>
>>> Since L4S is approved, please discuss the topics there.
>>>
>>> Gorry
>>>
>>>
>>> On 01/06/2016 22:53, John Leslie wrote:
>>>
>>>> Bob Briscoe  wrote:
>>>>
>>>>>
>>>>> John, Gorry,
>>>>>
>>>>> A random new thought...
>>>>>
>>>>
>>>>    (I'm still working on a reply to Bob's earlier email today: I'm
>>>> tending to make it a private reply since I'm not seeing a lot of
>>>> interest
>>>> in discussing it on the tcpprague list.)
>>>>
>>>> Another mechanism I've seen for this sort of thing is a mini-BoF within
>>>>> an existing WG agenda.
>>>>>
>>>>
>>>>    I'm not aware of any rules pertaining to such a mini-BoF -- I'd guess
>>>> the WGCs are entitled to call a section of their WG session a "mini-BoF"
>>>> and operate under near-BoF rules...
>>>>
>>>> Am I correct that a mini-BoF is appropriate for extending a WG's
>>>>> charter
>>>>> in a more major direction than just adding one doc, and/or where it's
>>>>> not clear whether a new WG might be needed instead?
>>>>> It could possibly be a tsvwg mini-BoF.
>>>>>
>>>>
>>>>    ISTM that is up to the TSVWG chairs.
>>>>
>>>> Or perhaps a joint tcpm, tsvwg, aqm mini-BoF, if such a thing exists?
>>>>>
>>>>
>>>>    I really doubt such a thing exists.
>>>>
>>>>    I'd be happy to see what Bob is suggesting as part of a TSVWG agenda.
>>>>
>>>> --
>>>> John Leslie 
>>>>
>>>> _______________________________________________
>>>> tcpPrague mailing list
>>>> tcpPrague@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tcpprague
>>>>
>>>>
>>> _______________________________________________
>>> tcpPrague mailing list
>>> tcpPrague@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tcpprague
>>>
>>> --
>>> ________________________________________________________________
>>> Bob Briscoe                               http://bobbriscoe.net/
>>>
>>
>> _______________________________________________
>> tcpPrague mailing list
>> tcpPrague@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpprague
>>
>>
> _______________________________________________
> tcpPrague mailing list
> tcpPrague@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpprague
>

--94eb2c0a915afab70a053564d9db
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi, Bob and Gorry,

On Thu, Jun 16, 2016 at 7:48 AM, Gorry Fairhurst <gor=
ry@erg.abdn.ac.uk> wrote:
H=
i Bob,



As it currently stands, I think a proposal to change the meaning of the ECN=
 base spec should come to TSVWG, as should updating the experimental codepo=
int use currently assigned to ECN-NONCE. This would mean re-defining ECT(0)=
 as not equivalent to ECT(1) within the default (BE) diffserv class - curre=
ntly this is only permitted as an alternate behaviour.



I think it could perhaps be argued that the meaning of CE is not significan=
tly changed, rather the marking behaviour and interpretation would be updat=
ed for endpoints using the new proposed method. A short draft that notes th=
e impact on existing RFCs would be good as a step forward.



For the moment, let's first discuss at the BoF what is needed - decidin=
g where to get standards progressed comes later.

I agree with this (but see below) ...
=C2=A0
Gorry<=
/font>




On 16/06/2016 08:34, Bob Briscoe wrote:



Gorry,



Thank you for this - v useful.



I would like to get a sense of people's opinion on a particular

political/procedural question that John L has raise that I think will be
central. And you may have a better feel for 'public opinion' on thi=
s

than me...



I expect any L4S aqm algos and any congestion control algos to be

experimental track.



>



However, in order to be experimented with on the public Internet, they

will need to distinguish their packets with an identifier.

ECT(1) is the leading contender, complemented by CE as the marking.{Note 1}=


So, just to make =
sure I understand the proposal ... because I'm probably confused.
=


I would support publication of these algorithms as Expe=
rimental, if that's what is proposed.

Are you =
thinking the experiment is, that devices on the public Internet are upgrade=
d to provide this new functionality even if they aren't participating i=
n the experiment, and then this new functionality is then experimented with=
, and the result of the experiment might be "now we know why that'=
s a bad idea, so we're not going to standardize it", so then the d=
evices revert to previous functionality?

The way I=
 thought this worked was that when you experiment with a standards-track pr=
otocol, the Experimental RFC is supported only by devices that are particip=
ating in the experiment, and the Experimental RFC doesn't update the st=
andards-track RFC(s) until the experiment succeeds, and then the Experiment=
al RFC is republished as a standards-track RFC that updates the previous st=
andards-track RFCs. If you decide the experiment is a bad idea, only device=
s that opt in to the experiment need to revert to previous functionality.

Are you thinking that wouldn't work here?
=


Thanks,

Spencer
=C2=
=A0
There are many pre-existing standards t=
rack docs {Note 2} that describe

usage of ECT(1), based on the assumption that it was an experimental nonce.=


A Proposed Standard RFC would be needed to update these PSs.



John L suggests (if I understand it correctly) a PS that makes space for
experiments by reserving ECT(1) again, without redefining it for any new
purpose (I guess it would mention L4S non-normatively). This RFC would

be written to update all the mentioned PS RFCs. I assume he is proposing
that then a new definition of ECT(1) for L4S could be written as a new

experimental track use of this newly reserved codepoint.



a) Is this a feasible way to evolve these proposed standards?

b) Do you think there might be support for this?



One problem I see:

* L4S needs to redefine the semantics of both ECT(1) /and/ CE, with the

definition of CE shared between L4S and Classic flows. {Note 3}

=C2=A0 We may have to somehow word the "John-L-proposed-PS" to al=
low this?





Bob



{Note 1} There are no perfect choices (the choices and their compromises
are listed in draft-briscoe-tsvwg-ecn-l4s-id).

{Note 2} Listed under "the standardization problem" in our L4S pr=
oblem

statement draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Also, quoting from t=
he above l4s-id draft (which is

written as intended for the experimental track):



"=C2=A0 Therefore, if the experiment is successful and a descendant of=
 this

=C2=A0 =C2=A0document proceeds to the standards track, it would be expected=
 to

=C2=A0 =C2=A0update the specification of ECN in IP [RFC3168].=C2=A0 It woul=
d also

=C2=A0 =C2=A0update the transport behaviour when using ECN in the standards=
 track

=C2=A0 =C2=A0RFCs listed in Section 2.3 (i.e.=C2=A0 ECN in TCP [RFC3168], i=
n SCTP

=C2=A0 =C2=A0[RFC4960], in RTP [RFC6679], and in DCCP [RFC4340]).

"

{Note 3} Hosts understand which meaning of CE is intended, because they

have per-flow context. For the network, the l4s-id draft proposes that a
stateless L4S-capable classifier classifies CE as L4S. Any ECN-capable

queue can still re-mark either ECT(0) or ECT(1) to CE.

This last point is no change from RFC3168. But the first two points

/are/ changes to the PSs.







On 15/06/16 18:40, Gorry Fairhurst wrote:





This topic may well fit within the scope of TSVWG.We could in

principle consider such a discussion, *IF* that's the best use of

face-to-face time at the meeting.



Since L4S is approved, please discuss the topics there.



Gorry





On 01/06/2016 22:53, John Leslie wrote:



Bob Briscoe <research@bobbriscoe.net> wrote:





John, Gorry,



A random new thought...





=C2=A0 =C2=A0(I'm still working on a reply to Bob's earlier email t=
oday: I'm

tending to make it a private reply since I'm not seeing a lot of

interest

in discussing it on the tcpprague list.)





Another mechanism I've seen for this sort of thing is a mini-BoF within=


an existing WG agenda.





=C2=A0 =C2=A0I'm not aware of any rules pertaining to such a mini-BoF -=
- I'd guess

the WGCs are entitled to call a section of their WG session a "mini-Bo=
F"

and operate under near-BoF rules...





Am I correct that a mini-BoF is appropriate for extending a WG's

charter

in a more major direction than just adding one doc, and/or where it's
not clear whether a new WG might be needed instead?

It could possibly be a tsvwg mini-BoF.





=C2=A0 =C2=A0ISTM that is up to the TSVWG chairs.





Or perhaps a joint tcpm, tsvwg, aqm mini-BoF, if such a thing exists?





=C2=A0 =C2=A0I really doubt such a thing exists.



=C2=A0 =C2=A0I'd be happy to see what Bob is suggesting as part of a TS=
VWG agenda.



--

John Leslie <john@jlc.=
net>



_______________________________________________

tcpPrague mailing list

tcpPrague@ietf.org<=
/a>

https://www.ietf.org/mailman/listinfo/tcpprague






_______________________________________________

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/





_______________________________________________

tcpPrague mailing list

tcpPrague@ietf.org<=
/a>

https://www.ietf.org/mailman/listinfo/tcpprague






_______________________________________________

tcpPrague mailing list

tcpPrague@ietf.org<=
/a>

https://www.ietf.org/mailman/listinfo/tcpprague




--94eb2c0a915afab70a053564d9db--


From nobody Thu Jun 16 07:50:48 2016
Return-Path: 
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8AF912D800 for ; Thu, 16 Jun 2016 07:50:46 -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, 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 asm5mgne2Rj8 for ; Thu, 16 Jun 2016 07:50:43 -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 F042812D7F9 for ; Thu, 16 Jun 2016 07:50:42 -0700 (PDT)
Received: from 148.58.125.91.dyn.plus.net ([91.125.58.148]:50896 helo=[192.168.0.10]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bDYcy-0005mq-W9; Thu, 16 Jun 2016 15:50:41 +0100
To: gorry@erg.abdn.ac.uk
References: <574EBEA2.8080705@bobbriscoe.net> <20160601152908.GB1754@verdi> <574F2A2D.9070407@bobbriscoe.net> <574F4F29.9040409@bobbriscoe.net> <20160601215312.GA25116@verdi> <0898e249-03dd-aff9-7179-03cc8642efea@erg.abdn.ac.uk> <5762567D.8010609@bobbriscoe.net> <3f8fa637-17b5-853b-b835-db486a2a69f6@erg.abdn.ac.uk>
From: Bob Briscoe 
Message-ID: <5762BCBF.8030703@bobbriscoe.net>
Date: Thu, 16 Jun 2016 15:50:39 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <3f8fa637-17b5-853b-b835-db486a2a69f6@erg.abdn.ac.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Cc: John Leslie , TCP Prague List 
Subject: Re: [tcpPrague] Enough energy for an L4S/TCP Prague BoF?
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 16 Jun 2016 14:50:47 -0000

Gorry,

On 16/06/16 13:48, Gorry Fairhurst wrote:
> Hi Bob,
>
> As it currently stands, I think a proposal to change the meaning of 
> the ECN base spec should come to TSVWG, as should updating the 
> experimental codepoint use currently assigned to ECN-NONCE. This would 
> mean re-defining ECT(0) as not equivalent to ECT(1) within the default 
> (BE) diffserv class - currently this is only permitted as an alternate 
> behaviour.
Understood and agreed that tsvwg is the place for these. Thx.
>
> I think it could perhaps be argued that the meaning of CE is not 
> significantly changed, rather the marking behaviour and interpretation 
> would be updated for endpoints using the new proposed method. A short 
> draft that notes the impact on existing RFCs would be good as a step 
> forward.
Well, CE (and ECT(1) would become a classifier to select a different 
queue as well as to select a mark/drop treatment. Admittedly that's 
pretty similar to today's definition, where the ECN field solely selects 
the latter, but it's a substantive difference.

Nonetheless, I guess no-one changed the TCP and UDP specs when fq 
starting using port numbers as queue selectors ;)
>
> For the moment, let's first discuss at the BoF what is needed - 
> deciding where to get standards progressed comes later.
Can I beg a little more of your time? I'd like to be able to discuss 
this by email first if poss - I am trying to ensure the BoF runs 
smoothly by trying to sense and adapt to consensus beforehand.

Reason: I'd like to produce a draft intended for the 'most likely' track 
before the draft deadline. That way it highlights all the potential 
pitfalls of choosing that track.

There are three possible approaches to get an identifier started:
1/ EXP only
2/ PS to reserve space, EXP to use it
3/ PS only

Pros and cons:
1/ draft-briscoe-tsvwg-ecn-l4s-id was written as "intended EXP" and it 
proved (to JohnL) that we needed something that could trump existing PSs.

2/ JohnL's 2-stage approach is less of a jump for the IESG to take, and 
it seems fairly clean, but it introduces two rounds of standardisation 
and therefore more interoperability complexity.

3/ Redefining the codepoints straightaway in a PS would be cleaner, but 
perhaps too much of a jump for the IESG.



Bob
>
> Gorry
>
> On 16/06/2016 08:34, Bob Briscoe wrote:
>> Gorry,
>>
>> Thank you for this - v useful.
>>
>> I would like to get a sense of people's opinion on a particular
>> political/procedural question that John L has raise that I think will be
>> central. And you may have a better feel for 'public opinion' on this
>> than me...
>>
>> I expect any L4S aqm algos and any congestion control algos to be
>> experimental track.
> >
>> However, in order to be experimented with on the public Internet, they
>> will need to distinguish their packets with an identifier.
>> ECT(1) is the leading contender, complemented by CE as the 
>> marking.{Note 1}
>>
>> There are many pre-existing standards track docs {Note 2} that describe
>> usage of ECT(1), based on the assumption that it was an experimental 
>> nonce.
>> A Proposed Standard RFC would be needed to update these PSs.
>>
>> John L suggests (if I understand it correctly) a PS that makes space for
>> experiments by reserving ECT(1) again, without redefining it for any new
>> purpose (I guess it would mention L4S non-normatively). This RFC would
>> be written to update all the mentioned PS RFCs. I assume he is proposing
>> that then a new definition of ECT(1) for L4S could be written as a new
>> experimental track use of this newly reserved codepoint.
>>
>> a) Is this a feasible way to evolve these proposed standards?
>> b) Do you think there might be support for this?
>>
>> One problem I see:
>> * L4S needs to redefine the semantics of both ECT(1) /and/ CE, with the
>> definition of CE shared between L4S and Classic flows. {Note 3}
>>   We may have to somehow word the "John-L-proposed-PS" to allow this?
>>
>>
>> Bob
>>
>> {Note 1} There are no perfect choices (the choices and their compromises
>> are listed in draft-briscoe-tsvwg-ecn-l4s-id).
>> {Note 2} Listed under "the standardization problem" in our L4S problem
>> statement draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem.
>>                Also, quoting from the above l4s-id draft (which is
>> written as intended for the experimental track):
>>
>> "  Therefore, if the experiment is successful and a descendant of this
>>    document proceeds to the standards track, it would be expected to
>>    update the specification of ECN in IP [RFC3168].  It would also
>>    update the transport behaviour when using ECN in the standards track
>>    RFCs listed in Section 2.3 (i.e.  ECN in TCP [RFC3168], in SCTP
>>    [RFC4960], in RTP [RFC6679], and in DCCP [RFC4340]).
>> "
>> {Note 3} Hosts understand which meaning of CE is intended, because they
>> have per-flow context. For the network, the l4s-id draft proposes that a
>> stateless L4S-capable classifier classifies CE as L4S. Any ECN-capable
>> queue can still re-mark either ECT(0) or ECT(1) to CE.
>> This last point is no change from RFC3168. But the first two points
>> /are/ changes to the PSs.
>>
>>
>>
>> On 15/06/16 18:40, Gorry Fairhurst wrote:
>>>
>>> This topic may well fit within the scope of TSVWG.We could in
>>> principle consider such a discussion, *IF* that's the best use of
>>> face-to-face time at the meeting.
>>>
>>> Since L4S is approved, please discuss the topics there.
>>>
>>> Gorry
>>>
>>>
>>> On 01/06/2016 22:53, John Leslie wrote:
>>>> Bob Briscoe  wrote:
>>>>>
>>>>> John, Gorry,
>>>>>
>>>>> A random new thought...
>>>>
>>>>    (I'm still working on a reply to Bob's earlier email today: I'm
>>>> tending to make it a private reply since I'm not seeing a lot of
>>>> interest
>>>> in discussing it on the tcpprague list.)
>>>>
>>>>> Another mechanism I've seen for this sort of thing is a mini-BoF 
>>>>> within
>>>>> an existing WG agenda.
>>>>
>>>>    I'm not aware of any rules pertaining to such a mini-BoF -- I'd 
>>>> guess
>>>> the WGCs are entitled to call a section of their WG session a 
>>>> "mini-BoF"
>>>> and operate under near-BoF rules...
>>>>
>>>>> Am I correct that a mini-BoF is appropriate for extending a WG's
>>>>> charter
>>>>> in a more major direction than just adding one doc, and/or where it's
>>>>> not clear whether a new WG might be needed instead?
>>>>> It could possibly be a tsvwg mini-BoF.
>>>>
>>>>    ISTM that is up to the TSVWG chairs.
>>>>
>>>>> Or perhaps a joint tcpm, tsvwg, aqm mini-BoF, if such a thing exists?
>>>>
>>>>    I really doubt such a thing exists.
>>>>
>>>>    I'd be happy to see what Bob is suggesting as part of a TSVWG 
>>>> agenda.
>>>>
>>>> -- 
>>>> John Leslie 
>>>>
>>>> _______________________________________________
>>>> tcpPrague mailing list
>>>> tcpPrague@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tcpprague
>>>>
>>>
>>> _______________________________________________
>>> tcpPrague mailing list
>>> tcpPrague@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tcpprague
>>>
>>> -- 
>>> ________________________________________________________________
>>> Bob Briscoe http://bobbriscoe.net/
>>
>> _______________________________________________
>> tcpPrague mailing list
>> tcpPrague@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpprague
>>
>

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


From nobody Thu Jun 16 08:04:47 2016
Return-Path: 
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D840E12D7EF for ; Thu, 16 Jun 2016 08:04:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level: 
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 hR48dqFwVRSG for ; Thu, 16 Jun 2016 08:04:43 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 3F29712D86D for ; Thu, 16 Jun 2016 08:04:43 -0700 (PDT)
Received: from dhcp-207-155.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:cdb2:4850:cc4a:7812]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 71C541B001C0; Thu, 16 Jun 2016 16:04:42 +0100 (BST)
References: <574EBEA2.8080705@bobbriscoe.net> <20160601152908.GB1754@verdi> <574F2A2D.9070407@bobbriscoe.net> <574F4F29.9040409@bobbriscoe.net> <20160601215312.GA25116@verdi> <0898e249-03dd-aff9-7179-03cc8642efea@erg.abdn.ac.uk> <5762567D.8010609@bobbriscoe.net> <3f8fa637-17b5-853b-b835-db486a2a69f6@erg.abdn.ac.uk> <5762BCBF.8030703@bobbriscoe.net>
To: Bob Briscoe 
From: Gorry Fairhurst 
Organization: The University of Aberdeen is a charity registered in Scotland,  No SC013683.
Message-ID: <14e228eb-8991-126c-d981-3dce3483b7bb@erg.abdn.ac.uk>
Date: Thu, 16 Jun 2016 16:04:42 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <5762BCBF.8030703@bobbriscoe.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: John Leslie , TCP Prague List 
Subject: Re: [tcpPrague] Enough energy for an L4S/TCP Prague BoF?
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
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: Thu, 16 Jun 2016 15:04:46 -0000

My *own* take is this:

I think the proposed use is EXP, and the proposal should be in an EXP 
ID. I think your intention is to propose an experiment with the Default 
diffserv class and new use of the ECN field. As Spencer noted, be 
careful to explain the implications of the experiment)

If the ID requires an over-ride, or some other document to make that 
happen is less of an issue at the moment. After discussion, if the TSV 
AD, and relevant WG thinks this is a great idea and the risk of the 
experiment is acceptable, then we can help work out how to make this 
happen in the RFC-series. (That may involve a PS update to make this 
happen (2).) -- anyway I think it would be good to have an ID that 
identifies the scale of the update to existing RFCs.

Personally, I don't see option 3 as a likely successful path.

Gorry

On 16/06/2016 15:50, Bob Briscoe wrote:
> Gorry,
>
> On 16/06/16 13:48, Gorry Fairhurst wrote:
>> Hi Bob,
>>
>> As it currently stands, I think a proposal to change the meaning of
>> the ECN base spec should come to TSVWG, as should updating the
>> experimental codepoint use currently assigned to ECN-NONCE. This would
>> mean re-defining ECT(0) as not equivalent to ECT(1) within the default
>> (BE) diffserv class - currently this is only permitted as an alternate
>> behaviour.
> Understood and agreed that tsvwg is the place for these. Thx.
>>
>> I think it could perhaps be argued that the meaning of CE is not
>> significantly changed, rather the marking behaviour and interpretation
>> would be updated for endpoints using the new proposed method. A short
>> draft that notes the impact on existing RFCs would be good as a step
>> forward.
> Well, CE (and ECT(1) would become a classifier to select a different
> queue as well as to select a mark/drop treatment. Admittedly that's
> pretty similar to today's definition, where the ECN field solely selects
> the latter, but it's a substantive difference.
>
> Nonetheless, I guess no-one changed the TCP and UDP specs when fq
> starting using port numbers as queue selectors ;)
>>
>> For the moment, let's first discuss at the BoF what is needed -
>> deciding where to get standards progressed comes later.
> Can I beg a little more of your time? I'd like to be able to discuss
> this by email first if poss - I am trying to ensure the BoF runs
> smoothly by trying to sense and adapt to consensus beforehand.
>
> Reason: I'd like to produce a draft intended for the 'most likely' track
> before the draft deadline. That way it highlights all the potential
> pitfalls of choosing that track.
>
> There are three possible approaches to get an identifier started:
> 1/ EXP only
> 2/ PS to reserve space, EXP to use it
> 3/ PS only
>
> Pros and cons:
> 1/ draft-briscoe-tsvwg-ecn-l4s-id was written as "intended EXP" and it
> proved (to JohnL) that we needed something that could trump existing PSs.
>
> 2/ JohnL's 2-stage approach is less of a jump for the IESG to take, and
> it seems fairly clean, but it introduces two rounds of standardisation
> and therefore more interoperability complexity.
>
> 3/ Redefining the codepoints straightaway in a PS would be cleaner, but
> perhaps too much of a jump for the IESG.
>
>
>
> Bob
>>
>> Gorry
>>
>> On 16/06/2016 08:34, Bob Briscoe wrote:
>>> Gorry,
>>>
>>> Thank you for this - v useful.
>>>
>>> I would like to get a sense of people's opinion on a particular
>>> political/procedural question that John L has raise that I think will be
>>> central. And you may have a better feel for 'public opinion' on this
>>> than me...
>>>
>>> I expect any L4S aqm algos and any congestion control algos to be
>>> experimental track.
>> >
>>> However, in order to be experimented with on the public Internet, they
>>> will need to distinguish their packets with an identifier.
>>> ECT(1) is the leading contender, complemented by CE as the
>>> marking.{Note 1}
>>>
>>> There are many pre-existing standards track docs {Note 2} that describe
>>> usage of ECT(1), based on the assumption that it was an experimental
>>> nonce.
>>> A Proposed Standard RFC would be needed to update these PSs.
>>>
>>> John L suggests (if I understand it correctly) a PS that makes space for
>>> experiments by reserving ECT(1) again, without redefining it for any new
>>> purpose (I guess it would mention L4S non-normatively). This RFC would
>>> be written to update all the mentioned PS RFCs. I assume he is proposing
>>> that then a new definition of ECT(1) for L4S could be written as a new
>>> experimental track use of this newly reserved codepoint.
>>>
>>> a) Is this a feasible way to evolve these proposed standards?
>>> b) Do you think there might be support for this?
>>>
>>> One problem I see:
>>> * L4S needs to redefine the semantics of both ECT(1) /and/ CE, with the
>>> definition of CE shared between L4S and Classic flows. {Note 3}
>>>   We may have to somehow word the "John-L-proposed-PS" to allow this?
>>>
>>>
>>> Bob
>>>
>>> {Note 1} There are no perfect choices (the choices and their compromises
>>> are listed in draft-briscoe-tsvwg-ecn-l4s-id).
>>> {Note 2} Listed under "the standardization problem" in our L4S problem
>>> statement draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem.
>>>                Also, quoting from the above l4s-id draft (which is
>>> written as intended for the experimental track):
>>>
>>> "  Therefore, if the experiment is successful and a descendant of this
>>>    document proceeds to the standards track, it would be expected to
>>>    update the specification of ECN in IP [RFC3168].  It would also
>>>    update the transport behaviour when using ECN in the standards track
>>>    RFCs listed in Section 2.3 (i.e.  ECN in TCP [RFC3168], in SCTP
>>>    [RFC4960], in RTP [RFC6679], and in DCCP [RFC4340]).
>>> "
>>> {Note 3} Hosts understand which meaning of CE is intended, because they
>>> have per-flow context. For the network, the l4s-id draft proposes that a
>>> stateless L4S-capable classifier classifies CE as L4S. Any ECN-capable
>>> queue can still re-mark either ECT(0) or ECT(1) to CE.
>>> This last point is no change from RFC3168. But the first two points
>>> /are/ changes to the PSs.
>>>
>>>
>>>
>>> On 15/06/16 18:40, Gorry Fairhurst wrote:
>>>>
>>>> This topic may well fit within the scope of TSVWG.We could in
>>>> principle consider such a discussion, *IF* that's the best use of
>>>> face-to-face time at the meeting.
>>>>
>>>> Since L4S is approved, please discuss the topics there.
>>>>
>>>> Gorry
>>>>
>>>>
>>>> On 01/06/2016 22:53, John Leslie wrote:
>>>>> Bob Briscoe  wrote:
>>>>>>
>>>>>> John, Gorry,
>>>>>>
>>>>>> A random new thought...
>>>>>
>>>>>    (I'm still working on a reply to Bob's earlier email today: I'm
>>>>> tending to make it a private reply since I'm not seeing a lot of
>>>>> interest
>>>>> in discussing it on the tcpprague list.)
>>>>>
>>>>>> Another mechanism I've seen for this sort of thing is a mini-BoF
>>>>>> within
>>>>>> an existing WG agenda.
>>>>>
>>>>>    I'm not aware of any rules pertaining to such a mini-BoF -- I'd
>>>>> guess
>>>>> the WGCs are entitled to call a section of their WG session a
>>>>> "mini-BoF"
>>>>> and operate under near-BoF rules...
>>>>>
>>>>>> Am I correct that a mini-BoF is appropriate for extending a WG's
>>>>>> charter
>>>>>> in a more major direction than just adding one doc, and/or where it's
>>>>>> not clear whether a new WG might be needed instead?
>>>>>> It could possibly be a tsvwg mini-BoF.
>>>>>
>>>>>    ISTM that is up to the TSVWG chairs.
>>>>>
>>>>>> Or perhaps a joint tcpm, tsvwg, aqm mini-BoF, if such a thing exists?
>>>>>
>>>>>    I really doubt such a thing exists.
>>>>>
>>>>>    I'd be happy to see what Bob is suggesting as part of a TSVWG
>>>>> agenda.
>>>>>
>>>>> --
>>>>> John Leslie 
>>>>>
>>>>> _______________________________________________
>>>>> tcpPrague mailing list
>>>>> tcpPrague@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/tcpprague
>>>>>
>>>>
>>>> _______________________________________________
>>>> tcpPrague mailing list
>>>> tcpPrague@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tcpprague
>>>>
>>>> --
>>>> ________________________________________________________________
>>>> Bob Briscoe http://bobbriscoe.net/
>>>
>>> _______________________________________________
>>> tcpPrague mailing list
>>> tcpPrague@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tcpprague
>>>
>>
>


From nobody Thu Jun 16 08:32:15 2016
Return-Path: 
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA87B12D941 for ; Thu, 16 Jun 2016 08:32:14 -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, 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 dNd3dF3E4uvv for ; Thu, 16 Jun 2016 08:32:12 -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 0BE9F12D934 for ; Thu, 16 Jun 2016 08:32:12 -0700 (PDT)
Received: from 148.58.125.91.dyn.plus.net ([91.125.58.148]:51499 helo=[192.168.0.10]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bDZH8-0001gs-11; Thu, 16 Jun 2016 16:32:10 +0100
To: gorry@erg.abdn.ac.uk
References: <574EBEA2.8080705@bobbriscoe.net> <20160601152908.GB1754@verdi> <574F2A2D.9070407@bobbriscoe.net> <574F4F29.9040409@bobbriscoe.net> <20160601215312.GA25116@verdi> <0898e249-03dd-aff9-7179-03cc8642efea@erg.abdn.ac.uk> <5762567D.8010609@bobbriscoe.net> <3f8fa637-17b5-853b-b835-db486a2a69f6@erg.abdn.ac.uk> <5762BCBF.8030703@bobbriscoe.net> <14e228eb-8991-126c-d981-3dce3483b7bb@erg.abdn.ac.uk>
From: Bob Briscoe 
Message-ID: <5762C678.3070508@bobbriscoe.net>
Date: Thu, 16 Jun 2016 16:32:08 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <14e228eb-8991-126c-d981-3dce3483b7bb@erg.abdn.ac.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Cc: John Leslie , TCP Prague List 
Subject: Re: [tcpPrague] Enough energy for an L4S/TCP Prague BoF?
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 16 Jun 2016 15:32:14 -0000

Gorry,

Thanks.
Good to know where we stand with option #3.
To summarise, you're advising #1 for now, and perhaps #2 will be needed 
later.

I've already written #1 (in ecn-l4sl-id) and it doesn't work.

So I think #2 is not just something we might need later, but the only 
option.



Bob

On 16/06/16 16:04, Gorry Fairhurst wrote:
>
> My *own* take is this:
>
> I think the proposed use is EXP, and the proposal should be in an EXP 
> ID. I think your intention is to propose an experiment with the 
> Default diffserv class and new use of the ECN field. As Spencer noted, 
> be careful to explain the implications of the experiment)
>
> If the ID requires an over-ride, or some other document to make that 
> happen is less of an issue at the moment. After discussion, if the TSV 
> AD, and relevant WG thinks this is a great idea and the risk of the 
> experiment is acceptable, then we can help work out how to make this 
> happen in the RFC-series. (That may involve a PS update to make this 
> happen (2).) -- anyway I think it would be good to have an ID that 
> identifies the scale of the update to existing RFCs.
>
> Personally, I don't see option 3 as a likely successful path.
>
> Gorry
>
> On 16/06/2016 15:50, Bob Briscoe wrote:
>> Gorry,
>>
>> On 16/06/16 13:48, Gorry Fairhurst wrote:
>>> Hi Bob,
>>>
>>> As it currently stands, I think a proposal to change the meaning of
>>> the ECN base spec should come to TSVWG, as should updating the
>>> experimental codepoint use currently assigned to ECN-NONCE. This would
>>> mean re-defining ECT(0) as not equivalent to ECT(1) within the default
>>> (BE) diffserv class - currently this is only permitted as an alternate
>>> behaviour.
>> Understood and agreed that tsvwg is the place for these. Thx.
>>>
>>> I think it could perhaps be argued that the meaning of CE is not
>>> significantly changed, rather the marking behaviour and interpretation
>>> would be updated for endpoints using the new proposed method. A short
>>> draft that notes the impact on existing RFCs would be good as a step
>>> forward.
>> Well, CE (and ECT(1) would become a classifier to select a different
>> queue as well as to select a mark/drop treatment. Admittedly that's
>> pretty similar to today's definition, where the ECN field solely selects
>> the latter, but it's a substantive difference.
>>
>> Nonetheless, I guess no-one changed the TCP and UDP specs when fq
>> starting using port numbers as queue selectors ;)
>>>
>>> For the moment, let's first discuss at the BoF what is needed -
>>> deciding where to get standards progressed comes later.
>> Can I beg a little more of your time? I'd like to be able to discuss
>> this by email first if poss - I am trying to ensure the BoF runs
>> smoothly by trying to sense and adapt to consensus beforehand.
>>
>> Reason: I'd like to produce a draft intended for the 'most likely' track
>> before the draft deadline. That way it highlights all the potential
>> pitfalls of choosing that track.
>>
>> There are three possible approaches to get an identifier started:
>> 1/ EXP only
>> 2/ PS to reserve space, EXP to use it
>> 3/ PS only
>>
>> Pros and cons:
>> 1/ draft-briscoe-tsvwg-ecn-l4s-id was written as "intended EXP" and it
>> proved (to JohnL) that we needed something that could trump existing 
>> PSs.
>>
>> 2/ JohnL's 2-stage approach is less of a jump for the IESG to take, and
>> it seems fairly clean, but it introduces two rounds of standardisation
>> and therefore more interoperability complexity.
>>
>> 3/ Redefining the codepoints straightaway in a PS would be cleaner, but
>> perhaps too much of a jump for the IESG.
>>
>>
>>
>> Bob
>>>
>>> Gorry
>>>
>>> On 16/06/2016 08:34, Bob Briscoe wrote:
>>>> Gorry,
>>>>
>>>> Thank you for this - v useful.
>>>>
>>>> I would like to get a sense of people's opinion on a particular
>>>> political/procedural question that John L has raise that I think 
>>>> will be
>>>> central. And you may have a better feel for 'public opinion' on this
>>>> than me...
>>>>
>>>> I expect any L4S aqm algos and any congestion control algos to be
>>>> experimental track.
>>> >
>>>> However, in order to be experimented with on the public Internet, they
>>>> will need to distinguish their packets with an identifier.
>>>> ECT(1) is the leading contender, complemented by CE as the
>>>> marking.{Note 1}
>>>>
>>>> There are many pre-existing standards track docs {Note 2} that 
>>>> describe
>>>> usage of ECT(1), based on the assumption that it was an experimental
>>>> nonce.
>>>> A Proposed Standard RFC would be needed to update these PSs.
>>>>
>>>> John L suggests (if I understand it correctly) a PS that makes 
>>>> space for
>>>> experiments by reserving ECT(1) again, without redefining it for 
>>>> any new
>>>> purpose (I guess it would mention L4S non-normatively). This RFC would
>>>> be written to update all the mentioned PS RFCs. I assume he is 
>>>> proposing
>>>> that then a new definition of ECT(1) for L4S could be written as a new
>>>> experimental track use of this newly reserved codepoint.
>>>>
>>>> a) Is this a feasible way to evolve these proposed standards?
>>>> b) Do you think there might be support for this?
>>>>
>>>> One problem I see:
>>>> * L4S needs to redefine the semantics of both ECT(1) /and/ CE, with 
>>>> the
>>>> definition of CE shared between L4S and Classic flows. {Note 3}
>>>>   We may have to somehow word the "John-L-proposed-PS" to allow this?
>>>>
>>>>
>>>> Bob
>>>>
>>>> {Note 1} There are no perfect choices (the choices and their 
>>>> compromises
>>>> are listed in draft-briscoe-tsvwg-ecn-l4s-id).
>>>> {Note 2} Listed under "the standardization problem" in our L4S problem
>>>> statement draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem.
>>>>                Also, quoting from the above l4s-id draft (which is
>>>> written as intended for the experimental track):
>>>>
>>>> "  Therefore, if the experiment is successful and a descendant of this
>>>>    document proceeds to the standards track, it would be expected to
>>>>    update the specification of ECN in IP [RFC3168].  It would also
>>>>    update the transport behaviour when using ECN in the standards 
>>>> track
>>>>    RFCs listed in Section 2.3 (i.e.  ECN in TCP [RFC3168], in SCTP
>>>>    [RFC4960], in RTP [RFC6679], and in DCCP [RFC4340]).
>>>> "
>>>> {Note 3} Hosts understand which meaning of CE is intended, because 
>>>> they
>>>> have per-flow context. For the network, the l4s-id draft proposes 
>>>> that a
>>>> stateless L4S-capable classifier classifies CE as L4S. Any ECN-capable
>>>> queue can still re-mark either ECT(0) or ECT(1) to CE.
>>>> This last point is no change from RFC3168. But the first two points
>>>> /are/ changes to the PSs.
>>>>
>>>>
>>>>
>>>> On 15/06/16 18:40, Gorry Fairhurst wrote:
>>>>>
>>>>> This topic may well fit within the scope of TSVWG.We could in
>>>>> principle consider such a discussion, *IF* that's the best use of
>>>>> face-to-face time at the meeting.
>>>>>
>>>>> Since L4S is approved, please discuss the topics there.
>>>>>
>>>>> Gorry
>>>>>
>>>>>
>>>>> On 01/06/2016 22:53, John Leslie wrote:
>>>>>> Bob Briscoe  wrote:
>>>>>>>
>>>>>>> John, Gorry,
>>>>>>>
>>>>>>> A random new thought...
>>>>>>
>>>>>>    (I'm still working on a reply to Bob's earlier email today: I'm
>>>>>> tending to make it a private reply since I'm not seeing a lot of
>>>>>> interest
>>>>>> in discussing it on the tcpprague list.)
>>>>>>
>>>>>>> Another mechanism I've seen for this sort of thing is a mini-BoF
>>>>>>> within
>>>>>>> an existing WG agenda.
>>>>>>
>>>>>>    I'm not aware of any rules pertaining to such a mini-BoF -- I'd
>>>>>> guess
>>>>>> the WGCs are entitled to call a section of their WG session a
>>>>>> "mini-BoF"
>>>>>> and operate under near-BoF rules...
>>>>>>
>>>>>>> Am I correct that a mini-BoF is appropriate for extending a WG's
>>>>>>> charter
>>>>>>> in a more major direction than just adding one doc, and/or where 
>>>>>>> it's
>>>>>>> not clear whether a new WG might be needed instead?
>>>>>>> It could possibly be a tsvwg mini-BoF.
>>>>>>
>>>>>>    ISTM that is up to the TSVWG chairs.
>>>>>>
>>>>>>> Or perhaps a joint tcpm, tsvwg, aqm mini-BoF, if such a thing 
>>>>>>> exists?
>>>>>>
>>>>>>    I really doubt such a thing exists.
>>>>>>
>>>>>>    I'd be happy to see what Bob is suggesting as part of a TSVWG
>>>>>> agenda.
>>>>>>
>>>>>> -- 
>>>>>> John Leslie 
>>>>>>
>>>>>> _______________________________________________
>>>>>> tcpPrague mailing list
>>>>>> tcpPrague@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/tcpprague
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> tcpPrague mailing list
>>>>> tcpPrague@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/tcpprague
>>>>>
>>>>> -- 
>>>>> ________________________________________________________________
>>>>> Bob Briscoe http://bobbriscoe.net/
>>>>
>>>> _______________________________________________
>>>> tcpPrague mailing list
>>>> tcpPrague@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tcpprague
>>>>
>>>
>>
>

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


From nobody Fri Jun 24 09:03:14 2016
Return-Path: 
X-Original-To: tcpprague@ietf.org
Delivered-To: tcpprague@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F9C12DC82; Fri, 24 Jun 2016 09:00:42 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Secretariat\"" 
To: , 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160624160042.10933.11495.idtracker@ietfa.amsl.com>
Date: Fri, 24 Jun 2016 09:00:42 -0700
Archived-At: 
Cc: ietf@kuehlewind.net, tcpprague@ietf.org
Subject: [tcpPrague] l4s - Requested session has been scheduled for IETF 96
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.17
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, 24 Jun 2016 16:00:43 -0000

Dear Cindy Morgan,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 

l4s Session 1 (2:00:00)
    Tuesday, Afternoon Session I 1400-1600
    Room Name: Potsdam I size: 300
    ---------------------------------------------
    


Request Information:


---------------------------------------------------------
Working Group Name: Low Latency Low Loss Scalable throughput
Area Name: Transport Area
Session Requester: Cindy Morgan

Number of Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 200
Conflicts to Avoid: 
 First Priority: nmlrg maprg irtfopen lmap avtcore iccrg aqm mptcp rmcat taps tcpinc tcpm tsvwg tsvarea quic plus




Special Requests:
  
---------------------------------------------------------


From nobody Fri Jun 24 10:01:26 2016
Return-Path: 
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF0B12DC69 for ; Fri, 24 Jun 2016 10:01:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.026
X-Spam-Level: 
X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426] 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 LkQfXia3Efmx for ; Fri, 24 Jun 2016 10:01:23 -0700 (PDT)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC6112DC75 for ; Fri, 24 Jun 2016 10:01:22 -0700 (PDT)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 3D108C941E; Fri, 24 Jun 2016 13:01:18 -0400 (EDT)
Date: Fri, 24 Jun 2016 13:01:18 -0400
From: John Leslie 
To: Spencer Dawkins at IETF 
Message-ID: <20160624170118.GA52708@verdi>
References: <574EBEA2.8080705@bobbriscoe.net> <20160601152908.GB1754@verdi> <574F2A2D.9070407@bobbriscoe.net> <574F4F29.9040409@bobbriscoe.net> <20160601215312.GA25116@verdi> <0898e249-03dd-aff9-7179-03cc8642efea@erg.abdn.ac.uk> <5762567D.8010609@bobbriscoe.net> <3f8fa637-17b5-853b-b835-db486a2a69f6@erg.abdn.ac.uk> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.1i
Archived-At: 
Cc: "gorry@erg.abdn.ac.uk" , Bob Briscoe , John Leslie , TCP Prague List 
Subject: [tcpPrague] Experimental dual-queue ECN
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.17
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, 24 Jun 2016 17:01:25 -0000

Spencer Dawkins at IETF  wrote:
>...
> I would support publication of these algorithms as Experimental, if that's
> what is proposed.
> 
> Are you thinking the experiment is, that devices on the public Internet are
> upgraded to provide this new functionality even if they aren't
> participating in the experiment, and then this new functionality is then
> experimented with, and the result of the experiment might be "now we know
> why that's a bad idea, so we're not going to standardize it", so then the
> devices revert to previous functionality?

   I can't answer that part.

> The way I thought this worked was that when you experiment with a
> standards-track protocol, the Experimental RFC is supported only by
> devices that are participating in the experiment, and the Experimental
> RFC doesn't update the standards-track RFC(s) until the experiment
> succeeds, and then the Experimental RFC is republished as a standards-
> track RFC that updates the previous standards-track RFCs. If you decide
> the experiment is a bad idea, only devices that opt in to the experiment
> need to revert to previous functionality.

> Are you thinking that wouldn't work here?

   IMHO, such a path to  update RFC 3168 is impractical.

   At 62 pages, RFC 3168 simply covers too much territory. It covers both
the behavior of ECN-capable forwarders and the behavior of TCP senders
and receivers. (Fortunately, it doesn't try to cover the behavior of
non-TCP transports.)

   At the time it was written, it really wasn't practical to cover less
territory. But today, we understand that even TCP transport is entirely
too broad a topic.

   IMHO, we need to break off a limited part of it for Experimental
protocols:
1. that reaction to ECN-CE should be the "same as" drop; and
2. that ECN(1) MAY request marking for a lesser degree of congestion than
   ECN(0).

   This needs justification; and I believe we can give ample justification
without setting on _just_ dual-queue. Surely you've noticed there's
already a separate proposal for differing treatment of ECN-CE.

   I'm hoping we can agree that both experiments can co-exist...

   And even if _both_ experiments are declared a failure; the principle
of allowing differing requests and differing reactions is still 100%
valid.

   Your concern about backing out of an experiment is 100% correct.

   My preference is some kind of registration scheme to state which
senders and which forwarders are implementing an experiment. Registration
is conceptually simple; but associating senders with forwarders remains
challenging. IMHO, we need not solve that: it's sufficient to leave that
question to those who propose a particular experiment.

   Unfortunately, we have to deal with human beings to design experiments.
It is up to those who review the proposals to keep pressure on those
volunteers to distinguish their eventual aims from how to conduct and
evaluate experiments.

   IMHO, if we ask each experimental-track writer to solve that in addition
to designing the intended end-state _and_ how to modify RFC 3168, we're
inviting failure.

   Obviously, YMMV; but I think I owe it to you to provide whatever advice
I can.

--
John Leslie 


From nobody Fri Jun 24 10:41:45 2016
Return-Path: 
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBDE12D99F for ; Fri, 24 Jun 2016 10:41:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level: 
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 jxvX3XfZ6JAi for ; Fri, 24 Jun 2016 10:41:40 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 297FC12D13E for ; Fri, 24 Jun 2016 10:41:40 -0700 (PDT)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id D7E5A1B0025B; Fri, 24 Jun 2016 18:41:31 +0100 (BST)
Message-ID: <576D70CB.8060108@erg.abdn.ac.uk>
Date: Fri, 24 Jun 2016 18:41:31 +0100
From: Gorry Fairhurst 
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: John Leslie 
References: <574EBEA2.8080705@bobbriscoe.net> <20160601152908.GB1754@verdi> <574F2A2D.9070407@bobbriscoe.net> <574F4F29.9040409@bobbriscoe.net> <20160601215312.GA25116@verdi> <0898e249-03dd-aff9-7179-03cc8642efea@erg.abdn.ac.uk> <5762567D.8010609@bobbriscoe.net> <3f8fa637-17b5-853b-b835-db486a2a69f6@erg.abdn.ac.uk>  <20160624170118.GA52708@verdi>
In-Reply-To: <20160624170118.GA52708@verdi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: gorry Fairhurst , Bob Briscoe , Spencer Dawkins at IETF , TCP Prague List 
Subject: Re: [tcpPrague] Experimental dual-queue ECN
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
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, 24 Jun 2016 17:41:43 -0000

Since this is TCP-Prague, I'm speaking here only as an author of the ABE 
spec...

On 24/06/2016 18:01, John Leslie wrote:
> Spencer Dawkins at IETF  wrote:
>> ...
>> I would support publication of these algorithms as Experimental, if that's
>> what is proposed.
>>
>> Are you thinking the experiment is, that devices on the public Internet are
>> upgraded to provide this new functionality even if they aren't
>> participating in the experiment, and then this new functionality is then
>> experimented with, and the result of the experiment might be "now we know
>> why that's a bad idea, so we're not going to standardize it", so then the
>> devices revert to previous functionality?
>     I can't answer that part.
>
>> The way I thought this worked was that when you experiment with a
>> standards-track protocol, the Experimental RFC is supported only by
>> devices that are participating in the experiment, and the Experimental
>> RFC doesn't update the standards-track RFC(s) until the experiment
>> succeeds, and then the Experimental RFC is republished as a standards-
>> track RFC that updates the previous standards-track RFCs.
That seems correct to me.
>> If you decide
>> the experiment is a bad idea, only devices that opt in to the experiment
>> need to revert to previous functionality.
>> Are you thinking that wouldn't work here?
>     IMHO, such a path to  update RFC 3168 is impractical.
>
>     At 62 pages, RFC 3168 simply covers too much territory. It covers both
> the behavior of ECN-capable forwarders and the behavior of TCP senders
> and receivers. (Fortunately, it doesn't try to cover the behavior of
> non-TCP transports.)
>
>     At the time it was written, it really wasn't practical to cover less
> territory. But today, we understand that even TCP transport is entirely
> too broad a topic.
>
>     IMHO, we need to break off a limited part of it for Experimental
> protocols:
> 1. that reaction to ECN-CE should be the "same as" drop; and
I disagree of course - the CE-marking proposal has already been 
discussed at the IETF - and I suggest no ECN is likely to be found using 
RED - and ECN-marked RED is now anyway now deprecated. Many modern AQM 
methods CE-mark on a shallow queue - and I think we need to update the 
PS to reflect this.

I also don't see a specific experiment that is needed here  - what would 
be needed to test for safety in deployment? I *think* particular update 
can be taken directly to PS.
> 2. that ECN(1) MAY request marking for a lesser degree of congestion than
>     ECN(0).
That to me requires two changes - a standards action to address the 
current ECN PS requirement that the two codepoints (i.e., ECT(0) and 
ECT(1) are treated the same in the default DS class.

*AND* followed by an experimental proposal to use something different 
and obsolete the ECN-NONCE.

To me though, these are both TSVWG concerns - discussion should be taken 
on that list.
>     This needs justification; and I believe we can give ample justification
> without setting on _just_ dual-queue. Surely you've noticed there's
> already a separate proposal for differing treatment of ECN-CE.
>
>     I'm hoping we can agree that both experiments can co-exist...
If you refer to TCP's recation proposed in ABE (now a draft in TCPM), as 
a co-author I would suggest that these two experiments (and their usage 
if they continue) can co-exist. We have spoken to Bob and Koen on this 
topic.
>     And even if _both_ experiments are declared a failure; the principle
> of allowing differing requests and differing reactions is still 100%
> valid.
Indeed, until a PS is published.
>     Your concern about backing out of an experiment is 100% correct.
>
>     My preference is some kind of registration scheme to state which
> senders and which forwarders are implementing an experiment. Registration
> is conceptually simple; but associating senders with forwarders remains
> challenging. IMHO, we need not solve that: it's sufficient to leave that
> question to those who propose a particular experiment.
>     Unfortunately, we have to deal with human beings to design experiments.
> It is up to those who review the proposals to keep pressure on those
> volunteers to distinguish their eventual aims from how to conduct and
> evaluate experiments.
>
>     IMHO, if we ask each experimental-track writer to solve that in addition
> to designing the intended end-state _and_ how to modify RFC 3168, we're
> inviting failure.
>
>     Obviously, YMMV; but I think I owe it to you to provide whatever advice
> I can.
>
> --
> John Leslie
I can see we need to think about how to manage experiments and that 
there could indeed be lots of possibilities about how to manage the 
ECT(1) codepoint usage. I think your proposal should probably be 
analysed (at least discussed) if (hopefully when) TSVWG decides to allow 
experimental use of that codepoint.

Gorry


From nobody Fri Jun 24 13:24:35 2016
Return-Path: 
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FA612D620 for ; Fri, 24 Jun 2016 13:24:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.626
X-Spam-Level: 
X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 GOQacCmI8eke for ; Fri, 24 Jun 2016 13:24:30 -0700 (PDT)
Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 4E38912D1C2 for ; Fri, 24 Jun 2016 13:24:30 -0700 (PDT)
Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bGXeM-0006l2-CB; Fri, 24 Jun 2016 22:24:26 +0200
Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.104]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bGXeL-0001GW-Jz; Fri, 24 Jun 2016 22:24:26 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Michael Welzl 
In-Reply-To: <576D70CB.8060108@erg.abdn.ac.uk>
Date: Fri, 24 Jun 2016 22:24:23 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8D9E4035-23E9-4BAD-B689-BF82C54BC98F@ifi.uio.no>
References: <574EBEA2.8080705@bobbriscoe.net> <20160601152908.GB1754@verdi> <574F2A2D.9070407@bobbriscoe.net> <574F4F29.9040409@bobbriscoe.net> <20160601215312.GA25116@verdi> <0898e249-03dd-aff9-7179-03cc8642efea@erg.abdn.ac.uk> <5762567D.8010609@bobbriscoe.net> <3f8fa637-17b5-853b-b835-db486a2a69f6@erg.abdn.ac.uk>  <20160624170118.GA52708@verdi> <576D70CB.8060108@erg.abdn.ac.uk>
To: " Fairhurst" 
X-Mailer: Apple Mail (2.3124)
X-UiO-SPF-Received: 
X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 1 sum rcpts/h 5 sum msgs/h 1 total rcpts 43643 max rcpts/h 54 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 6B1DD33841F8240EEFBF57C5B23BADDD1253991A
X-UiO-SPAM-Test: remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1441 max/h 15 blacklist 0 greylist 0 ratelimit 0
Archived-At: 
Cc: TCP Prague List , Bob Briscoe , John Leslie , Spencer Dawkins 
Subject: Re: [tcpPrague] Experimental dual-queue ECN
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.17
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, 24 Jun 2016 20:24:34 -0000

Dear all,

Two comments in line below - about ABE, what else=E2=80=A6 sorry for =
derailing a bit, since this is the TCP Prague list...


> On 24. jun. 2016, at 19.41, Gorry Fairhurst  =
wrote:
>=20
> Since this is TCP-Prague, I'm speaking here only as an author of the =
ABE spec...
>=20
> On 24/06/2016 18:01, John Leslie wrote:
>> Spencer Dawkins at IETF  wrote:
>>> ...
>>> I would support publication of these algorithms as Experimental, if =
that's
>>> what is proposed.
>>>=20
>>> Are you thinking the experiment is, that devices on the public =
Internet are
>>> upgraded to provide this new functionality even if they aren't
>>> participating in the experiment, and then this new functionality is =
then
>>> experimented with, and the result of the experiment might be "now we =
know
>>> why that's a bad idea, so we're not going to standardize it", so =
then the
>>> devices revert to previous functionality?
>>    I can't answer that part.
>>=20
>>> The way I thought this worked was that when you experiment with a
>>> standards-track protocol, the Experimental RFC is supported only by
>>> devices that are participating in the experiment, and the =
Experimental
>>> RFC doesn't update the standards-track RFC(s) until the experiment
>>> succeeds, and then the Experimental RFC is republished as a =
standards-
>>> track RFC that updates the previous standards-track RFCs.
> That seems correct to me.
>>> If you decide
>>> the experiment is a bad idea, only devices that opt in to the =
experiment
>>> need to revert to previous functionality.
>>> Are you thinking that wouldn't work here?
>>    IMHO, such a path to  update RFC 3168 is impractical.
>>=20
>>    At 62 pages, RFC 3168 simply covers too much territory. It covers =
both
>> the behavior of ECN-capable forwarders and the behavior of TCP =
senders
>> and receivers. (Fortunately, it doesn't try to cover the behavior of
>> non-TCP transports.)
>>=20
>>    At the time it was written, it really wasn't practical to cover =
less
>> territory. But today, we understand that even TCP transport is =
entirely
>> too broad a topic.
>>=20
>>    IMHO, we need to break off a limited part of it for Experimental
>> protocols:
>> 1. that reaction to ECN-CE should be the "same as" drop; and
> I disagree of course - the CE-marking proposal has already been =
discussed at the IETF - and I suggest no ECN is likely to be found using =
RED - and ECN-marked RED is now anyway now deprecated. Many modern AQM =
methods CE-mark on a shallow queue - and I think we need to update the =
PS to reflect this.

+1 to Gorry  (unsurprisingly).

The ECN =E2=80=9CExperiment=E2=80=9D has hardly happened, so on what =
basis de we say that a reaction that is the =E2=80=9Csame as=E2=80=9D =
drop is safe?
If we just take operational experience, Cubic has first used a backoff =
(multiplication) factor of 0.8, then 0.7, deployed in Linux and widely =
used in the Internet.
This isn=E2=80=99t even limited to an ECN signal, which is likely to be =
produced by an AQM mechanism, and hence much more likely to indicate a =
shallow queue than loss.

So: I think we can now assert that the Internet won=E2=80=99t melt down =
if we'd back off using a different multiplication factor than 0.5.
Using such a larger factor *only* in response to ECN is even more =
conservative, so even safer.

Adding to this, what exactly is the logic that makes =E2=80=9Creact to =
marking the same way as you would react to drop=E2=80=9D particularly =
safe?
I can only assume that this assumes the same behavior in the network for =
ECN-marking and dropping, and so, if we keep as much as possible =
similar, this would be a safe way to go.
Reality is different. Please see, for example Figure 13 in this pdf:
=
https://www.duo.uio.no/bitstream/handle/10852/37381/khademi-AQM_Kids_TR434=
.pdf
Compare the left and right diagram - this is standard AQM marking =
behavior (mark where you would otherwise drop) and standard TCP behavior =
too, yet the result is pretty different.
This is because a packet that is marked, not dropped, is admitted into =
the queue and thereby changes the AQM dynamics.

So: you have a different result from *just* turning on ECN, =
similar-to-loss backoff or not.

In conclusion, I struggle to see the big reason why an =E2=80=9Cexactly =
like loss=E2=80=9D backoff is standard behavior and experimenting with =
other values should be prohibited.  A new particular value may =
constitute an experiment, but the =E2=80=9Cequal to loss=E2=80=9D =
limitation simply isn=E2=80=99t a good thing and should be removed - =
this removal isn=E2=80=99t an experiment, it's a bugfix. Other values =
are already used (in Cubic, as I said, and there not only for ECN), but =
for ECN-only, which is a more conservative route than doing this for =
loss, the IETF doesn=E2=80=99t even allow the Experiment.


> I also don't see a specific experiment that is needed here  - what =
would be needed to test for safety in deployment? I *think* particular =
update can be taken directly to PS.

+1


>> 2. that ECN(1) MAY request marking for a lesser degree of congestion =
than
>>    ECN(0).
> That to me requires two changes - a standards action to address the =
current ECN PS requirement that the two codepoints (i.e., ECT(0) and =
ECT(1) are treated the same in the default DS class.
>=20
> *AND* followed by an experimental proposal to use something different =
and obsolete the ECN-NONCE.
>=20
> To me though, these are both TSVWG concerns - discussion should be =
taken on that list.
>>    This needs justification; and I believe we can give ample =
justification
>> without setting on _just_ dual-queue. Surely you've noticed there's
>> already a separate proposal for differing treatment of ECN-CE.
>>=20
>>    I'm hoping we can agree that both experiments can co-exist...
> If you refer to TCP's recation proposed in ABE (now a draft in TCPM), =
as a co-author I would suggest that these two experiments (and their =
usage if they continue) can co-exist. We have spoken to Bob and Koen on =
this topic.

Yes - there are two queues for L4S, and, from a prior email from Bob in =
this list:
"L4S needs to redefine the semantics of both ECT(1) /and/ CE, with the =
definition of CE shared between L4S and Classic flows.=E2=80=9D
=20
These different semantics are necessary to differentiate between the =
=E2=80=9Cnormal=E2=80=9D and =E2=80=9CL4S=E2=80=9D ways of using ECN.


>>    And even if _both_ experiments are declared a failure; the =
principle
>> of allowing differing requests and differing reactions is still 100%
>> valid.
> Indeed, until a PS is published.
>>    Your concern about backing out of an experiment is 100% correct.
>>=20
>>    My preference is some kind of registration scheme to state which
>> senders and which forwarders are implementing an experiment. =
Registration
>> is conceptually simple; but associating senders with forwarders =
remains
>> challenging. IMHO, we need not solve that: it's sufficient to leave =
that
>> question to those who propose a particular experiment.
>>    Unfortunately, we have to deal with human beings to design =
experiments.
>> It is up to those who review the proposals to keep pressure on those
>> volunteers to distinguish their eventual aims from how to conduct and
>> evaluate experiments.
>>=20
>>    IMHO, if we ask each experimental-track writer to solve that in =
addition
>> to designing the intended end-state _and_ how to modify RFC 3168, =
we're
>> inviting failure.
>>=20
>>    Obviously, YMMV; but I think I owe it to you to provide whatever =
advice
>> I can.
>>=20
>> --
>> John Leslie
> I can see we need to think about how to manage experiments and that =
there could indeed be lots of possibilities about how to manage the =
ECT(1) codepoint usage. I think your proposal should probably be =
analysed (at least discussed) if (hopefully when) TSVWG decides to allow =
experimental use of that codepoint.
>=20
> Gorry


Cheers,
Michael


From nobody Sat Jun 25 07:08:11 2016
Return-Path: 
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A5612D0D1 for ; Sat, 25 Jun 2016 07:08:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.026
X-Spam-Level: 
X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426] 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 d4nBa7Kwp9FV for ; Sat, 25 Jun 2016 07:08:08 -0700 (PDT)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id A0A1E12B04C for ; Sat, 25 Jun 2016 07:08:06 -0700 (PDT)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 665D7C9417; Sat, 25 Jun 2016 10:08:03 -0400 (EDT)
Date: Sat, 25 Jun 2016 10:08:03 -0400
From: John Leslie 
To: Michael Welzl 
Message-ID: <20160625140803.GB52708@verdi>
References: <574F2A2D.9070407@bobbriscoe.net> <574F4F29.9040409@bobbriscoe.net> <20160601215312.GA25116@verdi> <0898e249-03dd-aff9-7179-03cc8642efea@erg.abdn.ac.uk> <5762567D.8010609@bobbriscoe.net> <3f8fa637-17b5-853b-b835-db486a2a69f6@erg.abdn.ac.uk>  <20160624170118.GA52708@verdi> <576D70CB.8060108@erg.abdn.ac.uk> <8D9E4035-23E9-4BAD-B689-BF82C54BC98F@ifi.uio.no>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8D9E4035-23E9-4BAD-B689-BF82C54BC98F@ifi.uio.no>
User-Agent: Mutt/1.4.1i
Archived-At: 
Cc: " Fairhurst" , Bob Briscoe , TCP Prague List , Spencer Dawkins , John Leslie 
Subject: Re: [tcpPrague] Experimental dual-queue ECN
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.17
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: Sat, 25 Jun 2016 14:08:10 -0000

   I seem to have flunked Robert Heinlein's class in writing orders!

   Gorry succeeded in misunderstanding my point 1: "that reaction to ECN-CE
should be the 'same as' drop". :^)

   It was "obvious" to me that RFC 3168 now requires that, and that we
need to change so that is no longer required.

   Fortunately, it seems the three of us agree it needs to change. :^)

Michael Welzl  wrote:
> From: Michael Welzl 
>... 
>> On 24. jun. 2016, at 19.41, Gorry Fairhurst  wrote:
>>... 
>> On 24/06/2016 18:01, John Leslie wrote:
>>> Spencer Dawkins at IETF  wrote:
>>>> ...
>>>> Are you thinking that wouldn't work here?
>>>
>>> IMHO, such a path to  update RFC 3168 is impractical.
>>>... 
>>> IMHO, we need to break off a limited part of it for Experimental
>>> protocols:
>>>
>>> 1. that reaction to ECN-CE should be the "same as" drop; and

>> I disagree of course - the CE-marking proposal has already been
>> discussed at the IETF - and I suggest no ECN is likely to be foundi
>> using RED - and ECN-marked RED is now anyway now deprecated.
>> Many modern AQM methods CE-mark on a shallow queue - and I think
>> we need to update the PS to reflect this.

   Fundamentally, I agree: but my concern was the minimum change needed
to 3168.

> +1 to Gorry  (unsurprisingly).
> 
> The ECN ???Experiment??? has hardly happened, so on what basis de
> we say that a reaction that is the ???same as??? drop is safe?

   IMHO, that is what 3168 meant to say. I've never agreed with it.

> If we just take operational experience, Cubic has first used a backoff
> (multiplication) factor of 0.8, then 0.7, deployed in Linux and widely
> used in the Internet.
> This isn???t even limited to an ECN signal, which is likely to be
> produced by an AQM mechanism, and hence much more likely to indicate
> a shallow queue than loss.

   I agree.

> So: I think we can now assert that the Internet won???t melt down if
> we'd back off using a different multiplication factor than 0.5.

   I agree that would be good background material for a PS RFC relaxing
that rule of 3168.

   (But I don't think we need to limit the difference to applying a
differentt factor: that is a really obvious way, and it has effectively
been tested in actual use; but it is not the _only_ way.

> Using such a larger factor *only* in response to ECN is even more
> conservative, so even safer.

   Exactly!

> Adding to this, what exactly is the logic that makes ???react to
> marking the same way as you would react to drop??? particularly safe?

   The argument, as best I recall, was that otherwise one flow would
starve the other. But there are other ways to treat that problem!

> I can only assume that this assumes the same behavior in the network
> for ECN-marking and dropping, and so, if we keep as much as possible
> similar, this would be a safe way to go.

   I don't see any reason to "keep as much as possible similay" if
it's for an Experimental RFC. We should aim for _significant_ improvement.

> Reality is different. Please see, for example Figure 13 in this pdf:
> https://www.duo.uio.no/bitstream/handle/10852/37381/khademi-AQM_Kids_TR434.pdf

   I shall get around to reading this today.

>...
> In conclusion, I struggle to see the big reason why an ???exactly like
> loss??? backoff is standard behavior and experimenting with other values
> should be prohibited.

   We three agree it shouldn't.

   But...

   Implementors should be able to read RFC3168 and its metadate and
understand that their ten-year-old code may no longer be compliant.

   It's about a warning-label!

> A new particular value may constitute an experiment, but the
> ???equal to loss??? limitation simply isn???t a good thing and should
> be removed - this removal isn???t an experiment, it's a bugfix.

   Exactly!

>...
>> I also don't see a specific experiment that is needed here  - what
>> would be needed to test for safety in deployment? I *think*
>> particular update can be taken directly to PS.
> 
> +1
 
   (I believe we could treat two issues in the same RFC, in order to
make implementors' jab a little easier. YMMV...)

>... 

--
John Leslie 


From nobody Sat Jun 25 07:21:03 2016
Return-Path: 
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D423E12B025 for ; Sat, 25 Jun 2016 07:21:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level: 
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 lmG11W5OwqAz for ; Sat, 25 Jun 2016 07:21:00 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id C8BFA12D0EE for ; Sat, 25 Jun 2016 07:21:00 -0700 (PDT)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id ABB9D1B0025B; Sat, 25 Jun 2016 15:20:52 +0100 (BST)
Message-ID: <576E9344.2010909@erg.abdn.ac.uk>
Date: Sat, 25 Jun 2016 15:20:52 +0100
From: Gorry Fairhurst 
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: John Leslie 
References: <574F2A2D.9070407@bobbriscoe.net> <574F4F29.9040409@bobbriscoe.net> <20160601215312.GA25116@verdi> <0898e249-03dd-aff9-7179-03cc8642efea@erg.abdn.ac.uk> <5762567D.8010609@bobbriscoe.net> <3f8fa637-17b5-853b-b835-db486a2a69f6@erg.abdn.ac.uk>  <20160624170118.GA52708@verdi> <576D70CB.8060108@erg.abdn.ac.uk> <8D9E4035-23E9-4BAD-B689-BF82C54BC98F@ifi.uio.no> <20160625140803.GB52708@verdi>
In-Reply-To: <20160625140803.GB52708@verdi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: Bob Briscoe , TCP Prague List , Michael Welzl , Spencer Dawkins 
Subject: Re: [tcpPrague] Experimental dual-queue ECN
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
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: Sat, 25 Jun 2016 14:21:03 -0000

Email is a wodnerful media... we seem to have a lot more agreement than 
I'd hoped.

(... and yes: If we have more than one simple PS update to 3168, and 
everyone agrees, I think these could form part of the same document).

Gorry

On 25/06/2016 15:08, John Leslie wrote:
>     I seem to have flunked Robert Heinlein's class in writing orders!
>
>     Gorry succeeded in misunderstanding my point 1: "that reaction to ECN-CE
> should be the 'same as' drop". :^)
>
>     It was "obvious" to me that RFC 3168 now requires that, and that we
> need to change so that is no longer required.
>
>     Fortunately, it seems the three of us agree it needs to change. :^)
>
> Michael Welzl  wrote:
>> From: Michael Welzl
>> ...
>>> On 24. jun. 2016, at 19.41, Gorry Fairhurst  wrote:
>>> ...
>>> On 24/06/2016 18:01, John Leslie wrote:
>>>> Spencer Dawkins at IETF   wrote:
>>>>> ...
>>>>> Are you thinking that wouldn't work here?
>>>> IMHO, such a path to  update RFC 3168 is impractical.
>>>> ...
>>>> IMHO, we need to break off a limited part of it for Experimental
>>>> protocols:
>>>>
>>>> 1. that reaction to ECN-CE should be the "same as" drop; and
>>> I disagree of course - the CE-marking proposal has already been
>>> discussed at the IETF - and I suggest no ECN is likely to be foundi
>>> using RED - and ECN-marked RED is now anyway now deprecated.
>>> Many modern AQM methods CE-mark on a shallow queue - and I think
>>> we need to update the PS to reflect this.
>     Fundamentally, I agree: but my concern was the minimum change needed
> to 3168.
>
>> +1 to Gorry  (unsurprisingly).
>>
>> The ECN ???Experiment??? has hardly happened, so on what basis de
>> we say that a reaction that is the ???same as??? drop is safe?
>     IMHO, that is what 3168 meant to say. I've never agreed with it.
>
>> If we just take operational experience, Cubic has first used a backoff
>> (multiplication) factor of 0.8, then 0.7, deployed in Linux and widely
>> used in the Internet.
>> This isn???t even limited to an ECN signal, which is likely to be
>> produced by an AQM mechanism, and hence much more likely to indicate
>> a shallow queue than loss.
>     I agree.
>
>> So: I think we can now assert that the Internet won???t melt down if
>> we'd back off using a different multiplication factor than 0.5.
>     I agree that would be good background material for a PS RFC relaxing
> that rule of 3168.
>
>     (But I don't think we need to limit the difference to applying a
> differentt factor: that is a really obvious way, and it has effectively
> been tested in actual use; but it is not the _only_ way.
>
>> Using such a larger factor *only* in response to ECN is even more
>> conservative, so even safer.
>     Exactly!
>
>> Adding to this, what exactly is the logic that makes ???react to
>> marking the same way as you would react to drop??? particularly safe?
>     The argument, as best I recall, was that otherwise one flow would
> starve the other. But there are other ways to treat that problem!
>
>> I can only assume that this assumes the same behavior in the network
>> for ECN-marking and dropping, and so, if we keep as much as possible
>> similar, this would be a safe way to go.
>     I don't see any reason to "keep as much as possible similay" if
> it's for an Experimental RFC. We should aim for _significant_ improvement.
>
>> Reality is different. Please see, for example Figure 13 in this pdf:
>> https://www.duo.uio.no/bitstream/handle/10852/37381/khademi-AQM_Kids_TR434.pdf
>     I shall get around to reading this today.
>
>> ...
>> In conclusion, I struggle to see the big reason why an ???exactly like
>> loss??? backoff is standard behavior and experimenting with other values
>> should be prohibited.
>     We three agree it shouldn't.
>
>     But...
>
>     Implementors should be able to read RFC3168 and its metadate and
> understand that their ten-year-old code may no longer be compliant.
>
>     It's about a warning-label!
>
>> A new particular value may constitute an experiment, but the
>> ???equal to loss??? limitation simply isn???t a good thing and should
>> be removed - this removal isn???t an experiment, it's a bugfix.
>     Exactly!
>
>> ...
>>> I also don't see a specific experiment that is needed here  - what
>>> would be needed to test for safety in deployment? I *think*
>>> particular update can be taken directly to PS.
>> +1
>
>     (I believe we could treat two issues in the same RFC, in order to
> make implementors' jab a little easier. YMMV...)
>
>> ...
> --
> John Leslie


From nobody Sat Jun 25 15:44:08 2016
Return-Path: 
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48BF812B012 for ; Sat, 25 Jun 2016 15:44:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.626
X-Spam-Level: 
X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 PnZmn_GZAXFw for ; Sat, 25 Jun 2016 15:44:03 -0700 (PDT)
Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (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 2876812B007 for ; Sat, 25 Jun 2016 15:44:02 -0700 (PDT)
Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bGwIw-0008K0-MJ; Sun, 26 Jun 2016 00:43:58 +0200
Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.100]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bGwIv-00043V-Qb; Sun, 26 Jun 2016 00:43:58 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Michael Welzl 
X-Mailer: iPhone Mail (13F69)
In-Reply-To: <576E9344.2010909@erg.abdn.ac.uk>
Date: Sun, 26 Jun 2016 00:43:53 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <574F2A2D.9070407@bobbriscoe.net> <574F4F29.9040409@bobbriscoe.net> <20160601215312.GA25116@verdi> <0898e249-03dd-aff9-7179-03cc8642efea@erg.abdn.ac.uk> <5762567D.8010609@bobbriscoe.net> <3f8fa637-17b5-853b-b835-db486a2a69f6@erg.abdn.ac.uk>  <20160624170118.GA52708@verdi> <576D70CB.8060108@erg.abdn.ac.uk> <8D9E4035-23E9-4BAD-B689-BF82C54BC98F@ifi.uio.no> <20160625140803.GB52708@verdi> <576E9344.2010909@erg.abdn.ac.uk>
To: gorry@erg.abdn.ac.uk
X-UiO-SPF-Received: 
X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 1 sum rcpts/h 6 sum msgs/h 1 total rcpts 43664 max rcpts/h 54 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, MIME_QP_LONG_LINE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 0EF162D0BE3D9EA0A84A74ADD18E341606A4D432
X-UiO-SPAM-Test: remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1453 max/h 15 blacklist 0 greylist 0 ratelimit 0
Archived-At: 
Cc: Bob Briscoe , John Leslie , Spencer Dawkins , TCP Prague List 
Subject: Re: [tcpPrague] Experimental dual-queue ECN
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.17
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: Sat, 25 Jun 2016 22:44:06 -0000

how nice to see, we all agree!

Sent from my iPhone

> On 25. jun. 2016, at 16.20, Gorry Fairhurst  wrote:
>=20
> Email is a wodnerful media... we seem to have a lot more agreement than I'=
d hoped.
>=20
> (... and yes: If we have more than one simple PS update to 3168, and every=
one agrees, I think these could form part of the same document).
>=20
> Gorry
>=20
>> On 25/06/2016 15:08, John Leslie wrote:
>>    I seem to have flunked Robert Heinlein's class in writing orders!
>>=20
>>    Gorry succeeded in misunderstanding my point 1: "that reaction to ECN-=
CE
>> should be the 'same as' drop". :^)
>>=20
>>    It was "obvious" to me that RFC 3168 now requires that, and that we
>> need to change so that is no longer required.
>>=20
>>    Fortunately, it seems the three of us agree it needs to change. :^)
>>=20
>> Michael Welzl  wrote:
>>> From: Michael Welzl
>>> ...
>>>> On 24. jun. 2016, at 19.41, Gorry Fairhurst  wrot=
e:
>>>> ...
>>>> On 24/06/2016 18:01, John Leslie wrote:
>>>>> Spencer Dawkins at IETF   wrote:
>>>>>> ...
>>>>>> Are you thinking that wouldn't work here?
>>>>> IMHO, such a path to  update RFC 3168 is impractical.
>>>>> ...
>>>>> IMHO, we need to break off a limited part of it for Experimental
>>>>> protocols:
>>>>>=20
>>>>> 1. that reaction to ECN-CE should be the "same as" drop; and
>>>> I disagree of course - the CE-marking proposal has already been
>>>> discussed at the IETF - and I suggest no ECN is likely to be foundi
>>>> using RED - and ECN-marked RED is now anyway now deprecated.
>>>> Many modern AQM methods CE-mark on a shallow queue - and I think
>>>> we need to update the PS to reflect this.
>>    Fundamentally, I agree: but my concern was the minimum change needed
>> to 3168.
>>=20
>>> +1 to Gorry  (unsurprisingly).
>>>=20
>>> The ECN ???Experiment??? has hardly happened, so on what basis de
>>> we say that a reaction that is the ???same as??? drop is safe?
>>    IMHO, that is what 3168 meant to say. I've never agreed with it.
>>=20
>>> If we just take operational experience, Cubic has first used a backoff
>>> (multiplication) factor of 0.8, then 0.7, deployed in Linux and widely
>>> used in the Internet.
>>> This isn???t even limited to an ECN signal, which is likely to be
>>> produced by an AQM mechanism, and hence much more likely to indicate
>>> a shallow queue than loss.
>>    I agree.
>>=20
>>> So: I think we can now assert that the Internet won???t melt down if
>>> we'd back off using a different multiplication factor than 0.5.
>>    I agree that would be good background material for a PS RFC relaxing
>> that rule of 3168.
>>=20
>>    (But I don't think we need to limit the difference to applying a
>> differentt factor: that is a really obvious way, and it has effectively
>> been tested in actual use; but it is not the _only_ way.
>>=20
>>> Using such a larger factor *only* in response to ECN is even more
>>> conservative, so even safer.
>>    Exactly!
>>=20
>>> Adding to this, what exactly is the logic that makes ???react to
>>> marking the same way as you would react to drop??? particularly safe?
>>    The argument, as best I recall, was that otherwise one flow would
>> starve the other. But there are other ways to treat that problem!
>>=20
>>> I can only assume that this assumes the same behavior in the network
>>> for ECN-marking and dropping, and so, if we keep as much as possible
>>> similar, this would be a safe way to go.
>>    I don't see any reason to "keep as much as possible similay" if
>> it's for an Experimental RFC. We should aim for _significant_ improvement=
.
>>=20
>>> Reality is different. Please see, for example Figure 13 in this pdf:
>>> https://www.duo.uio.no/bitstream/handle/10852/37381/khademi-AQM_Kids_TR4=
34.pdf
>>    I shall get around to reading this today.
>>=20
>>> ...
>>> In conclusion, I struggle to see the big reason why an ???exactly like
>>> loss??? backoff is standard behavior and experimenting with other values=

>>> should be prohibited.
>>    We three agree it shouldn't.
>>=20
>>    But...
>>=20
>>    Implementors should be able to read RFC3168 and its metadate and
>> understand that their ten-year-old code may no longer be compliant.
>>=20
>>    It's about a warning-label!
>>=20
>>> A new particular value may constitute an experiment, but the
>>> ???equal to loss??? limitation simply isn???t a good thing and should
>>> be removed - this removal isn???t an experiment, it's a bugfix.
>>    Exactly!
>>=20
>>> ...
>>>> I also don't see a specific experiment that is needed here  - what
>>>> would be needed to test for safety in deployment? I *think*
>>>> particular update can be taken directly to PS.
>>> +1
>>=20
>>    (I believe we could treat two issues in the same RFC, in order to
>> make implementors' jab a little easier. YMMV...)
>>=20
>>> ...
>> --
>> John Leslie
>=20


From nobody Tue Jun 28 13:53:24 2016
Return-Path: 
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18ED12D894 for ; Tue, 28 Jun 2016 13:53:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.728
X-Spam-Level: 
X-Spam-Status: No, score=-5.728 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_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.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 h7p9_uktcZJx for ; Tue, 28 Jun 2016 13:53:20 -0700 (PDT)
Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (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 CFA7412D8AF for ; Tue, 28 Jun 2016 13:52:52 -0700 (PDT)
Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5SKq0Ar022762 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Jun 2016 16:52:00 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com u5SKq0Ar022762
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1467147121; bh=JjR4aydAw8hT14IVk9pdUVXyqiA=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=LkNUIbC5Qp6YX20UFlyYJW8ZVDySN9Hse8KHyiWc8KvNYmTcju9qPx3NCMfr/dPY/ t+y7YLAQ0bTu0mG9uMyfd0ZcYai6kPaEler/B/Gd1ybBfMlyCNFCZMHiz8RP13iJjJ o1rhVBv0E5VyEvoE1CshGwnOZsYPlgdMeG3cYK9M=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com u5SKq0Ar022762
Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd51.lss.emc.com (RSA Interceptor); Tue, 28 Jun 2016 16:51:02 -0400
Received: from MXHUB317.corp.emc.com (MXHUB317.corp.emc.com [10.146.3.95]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u5SKpqKl013429 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 28 Jun 2016 16:51:53 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB317.corp.emc.com ([10.146.3.95]) with mapi id 14.03.0266.001; Tue, 28 Jun 2016 16:51:52 -0400
From: "Black, David" 
To: Michael Welzl , "gorry@erg.abdn.ac.uk" 
Thread-Topic: [tcpPrague] Experimental dual-queue ECN
Thread-Index: AQHRzjoOU9hADIZ3ekqkVV5CUdcAP5/5JeOAgAAtgYCAASkvgIAAA5UAgACMioCABFQDQA==
Date: Tue, 28 Jun 2016 20:51:51 +0000
Message-ID: 
References: <574F2A2D.9070407@bobbriscoe.net> <574F4F29.9040409@bobbriscoe.net> <20160601215312.GA25116@verdi> <0898e249-03dd-aff9-7179-03cc8642efea@erg.abdn.ac.uk> <5762567D.8010609@bobbriscoe.net> <3f8fa637-17b5-853b-b835-db486a2a69f6@erg.abdn.ac.uk>  <20160624170118.GA52708@verdi> <576D70CB.8060108@erg.abdn.ac.uk> <8D9E4035-23E9-4BAD-B689-BF82C54BC98F@ifi.uio.no> <20160625140803.GB52708@verdi> <576E9344.2010909@erg.abdn.ac.uk> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.238.45.60]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com
X-RSA-Classifications: public
Archived-At: 
Cc: TCP Prague List , "Black, David" , Bob Briscoe , John Leslie , Spencer Dawkins 
Subject: Re: [tcpPrague] Experimental dual-queue ECN
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 28 Jun 2016 20:53:23 -0000

+1 on a simple draft to revise RFC 3168 solely to clear the "space" needed
for this sort of experimentation without getting into any details of what t=
he
experiments will or will not do (NB: that sort of speculation on what's com=
ing
is part of what got the RTP circuit breaker draft into its current situatio=
n, so
let's not repeat that ...).

Thanks, --David


> -----Original Message-----
> From: tcpPrague [mailto:tcpprague-bounces@ietf.org] On Behalf Of Michael
> Welzl
> Sent: Saturday, June 25, 2016 6:44 PM
> To: gorry@erg.abdn.ac.uk
> Cc: Bob Briscoe; John Leslie; Spencer Dawkins; TCP Prague List
> Subject: Re: [tcpPrague] Experimental dual-queue ECN
>=20
> how nice to see, we all agree!
>=20
> Sent from my iPhone
>=20
> > On 25. jun. 2016, at 16.20, Gorry Fairhurst  wrot=
e:
> >
> > Email is a wodnerful media... we seem to have a lot more agreement than=
 I'd
> hoped.
> >
> > (... and yes: If we have more than one simple PS update to 3168, and ev=
eryone
> agrees, I think these could form part of the same document).
> >
> > Gorry
> >
> >> On 25/06/2016 15:08, John Leslie wrote:
> >>    I seem to have flunked Robert Heinlein's class in writing orders!
> >>
> >>    Gorry succeeded in misunderstanding my point 1: "that reaction to E=
CN-CE
> >> should be the 'same as' drop". :^)
> >>
> >>    It was "obvious" to me that RFC 3168 now requires that, and that we
> >> need to change so that is no longer required.
> >>
> >>    Fortunately, it seems the three of us agree it needs to change. :^)
> >>
> >> Michael Welzl  wrote:
> >>> From: Michael Welzl
> >>> ...
> >>>> On 24. jun. 2016, at 19.41, Gorry Fairhurst  w=
rote:
> >>>> ...
> >>>> On 24/06/2016 18:01, John Leslie wrote:
> >>>>> Spencer Dawkins at IETF   wrote:
> >>>>>> ...
> >>>>>> Are you thinking that wouldn't work here?
> >>>>> IMHO, such a path to  update RFC 3168 is impractical.
> >>>>> ...
> >>>>> IMHO, we need to break off a limited part of it for Experimental
> >>>>> protocols:
> >>>>>
> >>>>> 1. that reaction to ECN-CE should be the "same as" drop; and
> >>>> I disagree of course - the CE-marking proposal has already been
> >>>> discussed at the IETF - and I suggest no ECN is likely to be foundi
> >>>> using RED - and ECN-marked RED is now anyway now deprecated.
> >>>> Many modern AQM methods CE-mark on a shallow queue - and I think
> >>>> we need to update the PS to reflect this.
> >>    Fundamentally, I agree: but my concern was the minimum change neede=
d
> >> to 3168.
> >>
> >>> +1 to Gorry  (unsurprisingly).
> >>>
> >>> The ECN ???Experiment??? has hardly happened, so on what basis de
> >>> we say that a reaction that is the ???same as??? drop is safe?
> >>    IMHO, that is what 3168 meant to say. I've never agreed with it.
> >>
> >>> If we just take operational experience, Cubic has first used a backof=
f
> >>> (multiplication) factor of 0.8, then 0.7, deployed in Linux and widel=
y
> >>> used in the Internet.
> >>> This isn???t even limited to an ECN signal, which is likely to be
> >>> produced by an AQM mechanism, and hence much more likely to indicate
> >>> a shallow queue than loss.
> >>    I agree.
> >>
> >>> So: I think we can now assert that the Internet won???t melt down if
> >>> we'd back off using a different multiplication factor than 0.5.
> >>    I agree that would be good background material for a PS RFC relaxin=
g
> >> that rule of 3168.
> >>
> >>    (But I don't think we need to limit the difference to applying a
> >> differentt factor: that is a really obvious way, and it has effectivel=
y
> >> been tested in actual use; but it is not the _only_ way.
> >>
> >>> Using such a larger factor *only* in response to ECN is even more
> >>> conservative, so even safer.
> >>    Exactly!
> >>
> >>> Adding to this, what exactly is the logic that makes ???react to
> >>> marking the same way as you would react to drop??? particularly safe?
> >>    The argument, as best I recall, was that otherwise one flow would
> >> starve the other. But there are other ways to treat that problem!
> >>
> >>> I can only assume that this assumes the same behavior in the network
> >>> for ECN-marking and dropping, and so, if we keep as much as possible
> >>> similar, this would be a safe way to go.
> >>    I don't see any reason to "keep as much as possible similay" if
> >> it's for an Experimental RFC. We should aim for _significant_ improvem=
ent.
> >>
> >>> Reality is different. Please see, for example Figure 13 in this pdf:
> >>> https://www.duo.uio.no/bitstream/handle/10852/37381/khademi-
> AQM_Kids_TR434.pdf
> >>    I shall get around to reading this today.
> >>
> >>> ...
> >>> In conclusion, I struggle to see the big reason why an ???exactly lik=
e
> >>> loss??? backoff is standard behavior and experimenting with other val=
ues
> >>> should be prohibited.
> >>    We three agree it shouldn't.
> >>
> >>    But...
> >>
> >>    Implementors should be able to read RFC3168 and its metadate and
> >> understand that their ten-year-old code may no longer be compliant.
> >>
> >>    It's about a warning-label!
> >>
> >>> A new particular value may constitute an experiment, but the
> >>> ???equal to loss??? limitation simply isn???t a good thing and should
> >>> be removed - this removal isn???t an experiment, it's a bugfix.
> >>    Exactly!
> >>
> >>> ...
> >>>> I also don't see a specific experiment that is needed here  - what
> >>>> would be needed to test for safety in deployment? I *think*
> >>>> particular update can be taken directly to PS.
> >>> +1
> >>
> >>    (I believe we could treat two issues in the same RFC, in order to
> >> make implementors' jab a little easier. YMMV...)
> >>
> >>> ...
> >> --
> >> John Leslie
> >
>=20
> _______________________________________________
> tcpPrague mailing list
> tcpPrague@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpprague