Re: [tsvwg] FQ & VPNs

[Ingemar Johansson S <[e-mail]>]

Sebastian

You are not required to like or believe in L4S, but there is support for it in TSVWG. 
There are however a few roadblocks along the way. One particular solution is to patch OS kernels to treat ECT(1) as not-ECT as a first step as suggested by Tom. You don't want that do happen for whatever reasons you list below. 

But maybe this discussion is pointless?, after all you are not the only one to decide what goes into Linux or other OS kernels. Updates there happen with or without the blessing of the IETF.

/Ingemar

> -----Original Message-----
> From: Sebastian Moeller <[e-mail]>
> Sent: den 22 februari 2021 08:54
> To: Ingemar Johansson S <[e-mail]>
> Cc: Tom Henderson <[e-mail]>; TSVWG <[e-mail]>
> Subject: Re: [tsvwg] FQ & VPNs
> 
> 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