Re: [tsvwg] plan for L4S issue #29

[Sebastian Moeller <[e-mail]>]

Hi Koen,

thanks, more below in-line.

> On Sep 28, 2020, at 11:31, De Schepper, Koen (Nokia - BE/Antwerp) <[e-mail]> wrote:
> 
> -----Original Message-----
> From: tsvwg <[e-mail]> On Behalf Of Jonathan Morton
> Sent: Wednesday, September 23, 2020 10:13 PM
> To: Sebastian Moeller <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [tsvwg] plan for L4S issue #29
> 
>> On 23 Sep, 2020, at 11:00 pm, Sebastian Moeller <[e-mail]> wrote:
>> 
>>> We had a consensus call in April,
>> 
>> 	[SM] Did we? As far as I remember the decision back then was always a "vote" of confidence for L4S over SCE, to make team L4S continue with the experient, but it did not (even try to) answer the question whether L4S is ready for deployment.
> 
> It was a consensus call over whether ECT(1) should have input or output semantics, which is a somewhat different (though related) question than "L4S vs SCE".  Regardless of any subsequent spin, it ended with no consensus established for any single option presented.
> 
> [K] There was a big consensus to proceed with the L4S semantic.

	[SM] That was the phrasing back then, I agree, but without an actual consumer no decision would have been necessary. So in other words, the input/output question in reality just presented an indirect "L4S or something else" choice. And many of the pro-input comments were motivated with agreement to L4S' goals, IIRC. But let's just not dwell on this, but rather figure out whether ECT(1) as input actually is a sane and safe design ;). I still wonder whether, that was not putting the cart before the horse, to commit to input versus output before assessing the respective consequences... 

Best Regards
	Sebastian

> 
> It was also established at the same time that L4S in its current form was *not* sufficiently robust for deployment, and thus unlikely to succeed if forwarded to later stages of the IETF standardization process.  That was not merely the opinion of myself and others in my "camp", so to speak, but was explicitly stated by the Chairs.  An opportunity was given for L4S to undergo further development with the aim of resolving these concerns.
> 
> [K] Operational guidelines draft was proposed, because a sender-host-only resolution (the Classic ECN AQM detection) should not be the only means to resolve potential real world problems. All involved parties should be able to take actions if problems might appear.
> 
> If any concrete progress has been made in that direction, I have not yet seen it.  But then, Bob has apparently been out of the loop for a while.  In that context, perhaps he will consider the above a friendly memory refreshment exercise.
> 
> Of course, if I have somehow got this wrong, I'll hear corrections.
> 
> [K] Greg prepared a first Ops Guidelines draft, collecting all ideas.  I guess next, we should be able to close the issues they are sufficiently covered by guidelines to resolve them.
> 
> Koen.
> 
> 
> 
> - Jonathan Morton
>