Re: [tsvwg] Review comments on a careful read of the L4S ID

[Gorry Fairhurst <[e-mail]>]

Thanks Sebastian,

Please se below marked [GF].

On 07/05/2021 07:34, Sebastian Moeller wrote:
> Gorry,
>
> On 6 May 2021 22:39:12 CEST, Gorry Fairhurst <[e-mail]> wrote:
>> Tom/David,
>>
>> Aha - I see now. Another possibility could be something like:
>>
>> "Explicit Congestion Notification (ECN) Protocol for Ultra-Low Queuing
>> Delay (L4S)" ??
> [SM] I thought "ultra-low" is going to be replaced with "consistently low"?

[GF] My comment was to ensure the abstract and title describe the goal 
of this architecture. (In terms of SLAs, operators often don't provide 
hard 100% guarentees, but do generally express the key aspects of their 
intended service class.) In this sense, "Ultra" seems like a marketing 
term, and I would expect that technical specifications avoid this word.

> Also if the ecn-id draft is considered a specification for protocols I very much would expect to see at least one fully functioning mostly-finished actual protocol being developed from that spec BEFORE standardisation as proof thar the spec itself is sufficiently complete and functional, no?

[GF] I'm not myself concerned about the Spec being implemented before it 
is published - but it was mist helpful to see implementor feedback on 
whether they understand the text. The IETF has published specs before 
and then after that the details have developed after the first round of 
documents were RFCs. In particular, any EXP spec would naturally be 
followed by another IETF spec that further details what is needed.

> And TCP Prague with all its unfinished/partly abandoned? attempts at implementing the 'specification's' requirements is not that convincing that the spec is complete and reasonably implementable.
> To be explicit, neither RTT-debiasing, nor rfc3168 detection are robustly and reliably tackled which is somewhat sobering given that the requirements exist for IIRC more than 5 years now...
>
> Regards
>          P.
>
[GF] I know in this period that support for DualQ has been added to some 
equipment - albeit while waiting for RFCs to finalise details.

I do expect that many larger endpoint implementors also do a lot of 
their initial development based on published RFCs, but also do 
prototyping of the details of algorithms in their various (often 
private) implementations. That appears to be very much the way of 
operation in working groups like QUIC. (QUIC has defined the fundamental 
feedback mechanisms needed for L4S). I'd love to see implementations 
emerge for TCP also.

The topic of RTT-debiasing always has been a really good direction, and 
remains so. I think that TSVWG would welcome more insight on this, and 
surely if people want to bring methods and experience to the WG, I'd 
personally encourage that.

So looking forward after the Specs are publsihed... I think network 
(router) deployment of the original ECN has to date been limited, this 
situation needs to change if L4S techniques are to be widley used. If 
there is wider support for L4S, then the incentives exist to get the 
protocol details correct, and my hope if that the implementors can bring 
their experience to the IETF.

>> Gorry

Best wishes,

Gorry

>>
>> On 06/05/2021 21:30, Black, David wrote:
>>> Tom,
>>>
>>> I'm the source of pushback here.  In my view, L4S is an interesting
>> mix, as the L4S ID draft does not define a complete protocol - rather,
>> it specifies the ECN marking mechanism and places requirements on the
>> endpoint congestion control response without specifying that response
>> in detail (e.g., to implement TCP Prague congestion control based on
>> L4S, one also needs to also go look at a TCP Prague spec).
>>> I'd be happy with "mechanism" or "functionality" but I don't see a
>> fully implementable "protocol" here.  What do you think?
>>> Thanks, --David
>>>
>>> -----Original Message-----
>>> From: tsvwg <[e-mail]> On Behalf Of Tom Henderson
>>> Sent: Thursday, May 6, 2021 1:19 PM
>>> To: Gorry Fairhurst
>>> Cc: [e-mail]
>>> Subject: Re: [tsvwg] Review comments on a careful read of the L4S ID
>>>
>>>
>>> [EXTERNAL EMAIL]
>>>
>>> On 5/5/21 11:52 PM, Gorry Fairhurst wrote:
>>>> =================================================================
>>>>
>>>> *5. Please be careful with the words here.*
>>>>
>>>> **
>>>>
>>>> This text:
>>>>
>>>> “This specificationdefines _the protocol to be used for_ a new
>> network
>>>> service called low latency, low loss and scalable throughput (L4S).”
>>>>
>>>> **
>>>>
>>>> ⁃This document does not define a protocol, so the words "_the
>> protocol
>>>> to be used for" _should be removed.
>>> Gorry, on this point, I made the original suggestion to call this a
>>> protocol document during the -13 review (email to the list on March
>> 7);
>>> please see below my original comment regarding this.
>>>
>>> - Tom
>>> Explicit Congestion Notification
>>>    > (ECN) Protocol for Ultra-Low Queuing Delay (L4S)
>>>
>>>    >
>>>    > Title
>>>    >
>>>    > The title of this draft suggests that the scope is narrowly
>> defining
>>>    > the identifier of L4S semantics, but the draft covers much more
>> than
>>>    > this; in fact, it perhaps it could more accurately be described
>> as an
>>>    > L4S protocol specification.  At the end of the abstract, the
>> draft
>>>    > states "This specification defines the rules that L4S transports
>> and
>>>    > network elements need to follow...", i.e. a protocol.  It also
>> gets
>>>    > into operational considerations and open questions for
>> experimentation.
>>>    >
>>>    > Perhaps a broader title such as "" would better match
>>>    > the contents.
>>>