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

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 <research@bobbriscoe.net> 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 <john@jlc.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
>
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/