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

[Bob Briscoe <[e-mail]>]

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/