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

["Black, David" <[e-mail]>]

Bob,

> I'm not going to push this one. We can go back to the previous title if preferred, which was
>      Identifying Modified Explicit Congestion Notification (ECN) Semantics for *****-Low Queuing Delay (L4S)
>          (The ***** is bleeped out, so it doesn't send this thread off into a rat-hole - I'll be responding to that point separately.)

Except that bringing back "Identifying" discards Tom's valid concern that this draft is doing much more than "Identifying" - dropping that word, and also dropping "Semantics" (to reduce pomposity) yields:
	Modified Explicit Congestion Notification (ECN) for *****-Low Queuing Delay (L4S)
Which can then be reworded to:
	Explicit Congestion Notification (ECN) Modifications for *****-Low Queuing Delay (L4S)
Which seems good, at least to me ;-).

That said, I'm going to agree to disagree with Tom on use of "protocol" and moreover, I'm willing to accept use of "protocol" if necessary, as this is now feeling like much more of an editorial discussion than a technical one.

Thanks, --David

-----Original Message-----
From: Bob Briscoe <[e-mail]> 
Sent: Friday, May 7, 2021 6:36 PM
To: Tom Henderson; Black, David
Cc: [e-mail]; Gorry Fairhurst
Subject: Re: [tsvwg] Review comments on a careful read of the L4S ID


[EXTERNAL EMAIL] 

Tom, David,

On 07/05/2021 00:53, Tom Henderson wrote:
> On 5/6/21 1:30 PM, 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?
>
> David,
> While I agree that congestion control is not specified in detail, the 
> title doesn't currently claim that it does.  It seems to me that 
> sections 4 and 5 define the protocol rules for the use of ECN.  My 
> earlier email suggested what more I thought could be included in those 
> sections, but I'm not sure whether the authors intend to pick up those 
> comments.

[BB] I'll pick up your comments in later email. But keeping to the 
question of whether ecn-l4s-id defines a protocol...

You might not be able to implement a protocol without its algorithms, 
but that doesn't mean the algorithms have to be standardized as part of 
a protocol. It is still a valid protocol if the algorithms are expected 
to be contributed by implementers.

For instance, the 3GPP defines a protocol to request upstream capacity. 
These requests are directed at the scheduling algorithm which gives out 
grants of capacity. Developers are not required to reveal their 
scheduling algorithms if they prefer to keep them as secret sauce, and 
there is no scheduling algorithm defined in the specs. So the spec's are 
not implementable without adding some of your own knowledge. But the 
spec's still define a request-grant protocol.

ecn-l4s-id defines a modification to the ECN protocol for L4S. The wire 
protocol is very simple, but that doesn't mean it's not a protocol. It 
sets requirements for an implementation of CC and of AQM, but doesn't 
define either in detail, although it refers to examples. That's a 
protocol, surely.

I'm not going to push this one. We can go back to the previous title if 
preferred, which was
     Identifying Modified Explicit Congestion Notification (ECN) 
Semantics for *****-Low Queuing Delay (L4S)
         (The ***** is bleeped out, so it doesn't send this thread off 
into a rat-hole - I'll be responding to that point separately.)

I just preferred Tom's suggestion of calling this a protocol, 'cos it's 
accurate and it's less pompous than calling it semantics (which was my 
choice originally, so I'm criticizing only myself).


Bob

>
> - Tom
>

-- 
________________________________________________________________
Bob Briscoe                               https://urldefense.com/v3/__http://bobbriscoe.net/__;!!LpKI!0jGSQESS07WxazAURFPBfqsCWuWhVr7qQQfKVNeXwDrGUXBm6312pu3yg9FaYTGY$ [bobbriscoe[.]net]