Re: [tsvwg] FQ & VPNs

[Sebastian Moeller <[e-mail]>]

Hi Ingemar,


> On Feb 22, 2021, at 07:07, Ingemar Johansson S <[e-mail]> wrote:
> 
> Hi Tom, Sebastian 
> Just to clarify.. there is no SCE alternative on the table in TSVWG. SCE is only an individual contribution, it is not a WG item. L4S got a wide support, while SCE was only supported by a few when this discussion was brought up 9-10 months ago. 
> Only Sebastian and others can explain why they repeatedly bring up SCE over and over again..

	[SM] Since you seem to ask... I have come to the conclusion that L4S does not achieve its promises and for several years there have been essential zero effective efforts to remedy this (a few attempts have been started, like the ill-fated and misnamed RTT-independence push, that basically never achieved their goals and then just petered out; but these left me with an impression of being tailored at silencing objections to L4S instead of actually improving the L4S design and implementation). So I assume that L4S is going to fail, sooner (hopefully) or later (after first being deployed and hogging the ECT(1) codepoint for years to come), but failure is IMHO certain. So I bring up SCE only as an example as a post-L4S High Frequency/Low Amplitude congestion signaling contender. In the context of Tom's mail I simply pointed out that stopping ECN treatment of ECT(1) packets is not a clear cut improvement over the status quo. That is all.

Best Regards
	Sebastian


> Tom: I think the two step approach proposed by you is definitely worth a closer look. 
> 
> /Ingemar
> 
> Hämta Outlook för iOS
> Från: tsvwg <[e-mail]> på uppdrag av Tom Henderson <[e-mail]>
> Skickat: måndag, februari 22, 2021 12:37 fm
> Till: Sebastian Moeller
> Kopia: TSVWG
> Ämne: Re: [tsvwg] FQ & VPNs
>  
> 
> > 
> >        [SM] Why? Honest question. Sure L4S requires exclusive access to ECT(1) but in SCE promoting a weak ECT(1) to a stronger CE at a later node seems like exactly the right behavior.
> 
> Sebastien,
> OK, I see your point now; keeping legacy behavior would still allow 
> legacy code to generate CE for an SCE flow.  However, it would have to 
> be a multiple bottleneck scenario with the second bottleneck being the 
> classic one for this to matter, I suppose.
> 
> I was hoping to propose a way forward for the backward compatibility 
> concerns by decoupling these steps, but if it is not agreeable, I guess 
> the deadlock remains.
> 
> - Tom