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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Bob and Gorry,

On Thu, Jun 16, 2016 at 7:48 AM, Gorry Fairhurst <[e-mail]>
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 <[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
>>
>>
> _______________________________________________
> tcpPrague mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpprague
>