Re: [tsvwg] start of WGLC on L4S drafts

["Gorry (erg)" <[e-mail]>]

Bob,

This makes sense to me he way you explain it - a little tweak here and there can perhaps avoid potential mis-reading 

Gorry

> On 20 Sep 2021, at 17:40, Bob Briscoe <[e-mail]> wrote:
> 
> Alex, Gorry, [Sry, just discovered I didn't click end on this]
> 
> In "all of a user's applications can shift" the word "can" is important.
> Similarly, in "The L4S architecture is intended to enable all Internet applications to transition" the word "enable" is important.
> 
> Neither statement was meant to imply that all applications would move, or should move, just that they would all be _able_ to.
> These statements are primarily intended as counterpoints to the commonly held view that low latency comes from priority scheduling (e.g. via differentiated service) so low latency can only be provided for a subset of traffic, because if all packets requested higher priority, there would be no difference to any packet's latency.
> 
> I've made a note to myself to make it clear that this is not an intention that all applications will transition, rather it is an intention not to prevent any application from transitioning.
> 
> 
> Bob
> 
>> On 02/09/2021 19:26, [e-mail] wrote:
>> Hi Gorry, tsvwg;
>> 
>> 
>> See inline [AB]
>> 
>> 
>> 
>> On Thursday, August 12, 2021, 11:23:49 AM GMT+1, Gorry Fairhurst<[e-mail]>  wrote:
>> 
>> ---
>> 1b) Issue: I’d also quibble with: “so that all of a user's applications
>> can shift to it when their stack is updated.“ - again, is the word “all”
>> really necessary or correct here?
>> ---
>> 
>> [AB]
>> Not  answering your point, but related:
>> 
>> L4s-arch has at the very start the following: “The L4S architecture is intended to enable   _all_ Internet applications to transition away from congestion control algorithms that cause queuing delay, to a new class of  congestion controls that induce very little queuing, aided by  explicit congestion signaling from the network. “
>> 
>> 
>>  There are two quite different end states here:
>> 
>> * An internet in which there are, end-to-end, two classes of traffic on an ongoing basis.
>> 
>> * An internet in which nearly all traffic has transitioned to L4S, remaining non-L4S traffic being supported on a backwards-compatibility basis
>> 
>> As I understand it, if L4S is deployed, either of these could be possible end states. At present it is not clear that all use cases could migrate (eg, long RTT traffic)
>> 
>> 
>> It seems like it would be a good idea for the draft to make clear:
>> * That either of these end states are possible
>> * What the formal position of the WG would be if the drafts are accepted, IE what decision has been made (or left for later) regarding the desired end state.
>> 
>> 
>> regards,
>> 
>> Alex
>> 
> 
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/