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

[Sebastian Moeller <[e-mail]>]

Hi Gorry,

see [SM2] below.


> On May 7, 2021, at 11:32, Gorry Fairhurst <[e-mail]> wrote:
> 
> 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.

	[SM2] An implementation is the best way to demonstrate that a spec is actually implementable and to assess how much of the expected behavior actually transfers to the real word. The rfc3168 example demonstrates how hard it is to fix/change such behavior once nodes are deployed in the field.


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

	[SM2] Is an untested implementation really proof of anything, though? I explicitly asked on list whether industry members had private data convincing them of safety and functionality of L4S' design. There was more or less zero response to that question, mind you I did not ask for data to be revealed, just whether people had seen subjectively convincing data.

> I do expect that many larger endpoint implementors also do a lot of their initial development based on published RFCs,

	[SM2] One more reason to make sure that published RFCs are actually implementable before ratification, IMHO. Unless you are convinced the TCP Prague proofs both sufficient safety and functionality we have no indication that the L4S design will be implementable to the advantage of the internet.

> but also do prototyping of the details of algorithms in their various (often private) implementations.

	[SM2] I am fine with private implementations, and also fine for the time being for developers to keep a low profile on the details, but asking "is L4S safe and functional according to your internal assessment" seems respectful of the desire for secrecy, no?


> 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).

	[SM2] But QUICK is missing quite a number of the other requirements for a L4S-compatible protocol, so can clearly not be used for open-internet testing at the current time, no?


> I'd love to see implementations emerge for TCP also.

	[SM2] So we agree that neither DCTCP nor TCP Prague count here, eh? ;) Partly kidding...

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

	[SM2] In theory I agree, yet the fact remains that L4S' AQM increases RTT bias between C and L queue traffic and that the reference L4S protocol TCP Prague displays quite large RTT-bias with itself in the ubiquitous FIFO bottleneck. In other words I agree that working against RTT-bias is a good direction, but L4S does not improve that situation (in fact it makes it worse, as can be seen in e.g. Pete's data).

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

	[SM2] This assumes that the network bits of L4S as designed right now are sufficiently functional and safe, and that short-comings in their design can be "fixed" on the protocol side. In fact quite a number of these short-comings are already (indirectly) documented in the L4S protocol requirements already, like RTT-bias and burst-intolerance. I fail to see the rush, so let's fix the next ECN-AQM contender before we try to deploy it en-masse, please?


Best Regards
	Sebastian



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