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

[Bob Briscoe <[e-mail]>]

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 <[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
>>>>
>>>
>>
>

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