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

[Gorry Fairhurst <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
>>>
>>> _______________________________________________
>>> tcpPrague mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tcpprague
>>>
>>
>> _______________________________________________
>> tcpPrague mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpprague
>>
>> --
>> ________________________________________________________________
>> Bob Briscoe                               http://bobbriscoe.net/
>
> _______________________________________________
> tcpPrague mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpprague
>