Re: [tcpPrague] Enough energy for an L4S/TCP Prague BoF?

Bob Briscoe <ietf@bobbriscoe.net> Wed, 01 June 2016 18:32 UTC

Return-Path: <ietf@bobbriscoe.net>
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 <tcpprague@ietfa.amsl.com>; 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 <tcpprague@ietfa.amsl.com>; 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 <tcpPrague@ietf.org>; 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 <ietf@bobbriscoe.net>) id 1b8AwA-0006LE-LJ; Wed, 01 Jun 2016 19:32:15 +0100
To: John Leslie <john@jlc.net>
References: <574EBEA2.8080705@bobbriscoe.net> <20160601152908.GB1754@verdi>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <574F2A2D.9070407@bobbriscoe.net>
Date: Wed, 01 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: <http://mailarchive.ietf.org/arch/msg/tcpprague/fKzjZwnAJlaxknq9qzHYyhq5jSI>
Cc: TCP Prague List <tcpPrague@ietf.org>
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." <tcpprague.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpprague/>
List-Post: <mailto:tcpprague@ietf.org>
List-Help: <mailto:tcpprague-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jun 2016 18:32:20 -0000

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/