Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)

[Sebastian Moeller <[e-mail]>]

Hi Ingemar,

more below, prefixed [SM].

> On Mar 29, 2021, at 09:44, Ingemar Johansson S <[e-mail]> wrote:
> 
> Hi
> /Inline
> 
>> -----Original Message-----
>> From: Sebastian Moeller <[e-mail]>
>> Sent: den 28 mars 2021 22:08
>> To: Ingemar Johansson S <[e-mail]>
>> Cc: Jonathan Morton <[e-mail]>; Pete Heist
>> <[e-mail]>; Kyle Rose <[e-mail]>; C. M. Heard
>> <[e-mail]>; De Schepper, Koen (Nokia - BE/Antwerp)
>> <[e-mail]>; tsvwg IETF list <[e-mail]>
>> Subject: Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)
>> 
>> Hi ingemar,
>> 
>> let's take your "let it age out" proposal at face value. How long do you
>> estimate will it take for those problematic nodes to age out of the system
>> after the IETF has signaled that rfc3168 has changed?
>> And let's assume you come up with a number of X years, are you really willing
>> to put the L4S experiment on hold until that time has passed?
> [IJ] Things does not work that way. 

	[SM] What does not work that way? Conceptually, a discussion works best, if all sides enter only proposals they consider actually workable... here I tried to lay out the common sense consequences of arguing that the natural replacement cycle will solve the L4S rfc3168 interoperability/safety issues. As I said before, I do not think that L4S is prepared to give notice now and wait for another X years of grace period, so why even bring this argument in the first place?

> There are absolutely no incentives to adapt nodes on the internet that does feature A to work in concert with feature B, if feature B is put on hold until feature A adapts. 

	[SM] I tend to agree, hence I considered your approach, "wait for the natural replacement cycle to run its course" as an attempt at de-railing the discussion of meaningful methods to allow an experiment in an internet where rfc3168 AQMs are known to exist, and where their deployers expect them to continue to work as they did before the start of any IETF experiment. 
	As a thought experiment, would you agree that after L4S gets deployed, I can just register another experiment, running rough-shed over L4S based on the fact that doing so would be more convenient to my experiment? If you consider that to be appropriate I woulld at least have expected L4S having a designed in sun-set method allowing quit replacement for something better... IMHO this is simply not an honest argument from your side, but an attempt at constructing a staw-man argument to tear down.

> This would call for a flag day and these have so far not worked well on the internet.

	[SM] +1; but again, why did you propose this in the context of discussing actual solutions to the current stale-mate? 

I also repeat my invitation to actually look at my (and/or Jonathan's more comprehensive) proposals and try to poke holes into and/or improve them. 

@chairs, I have a hard time still assuming good-faith in team L4S, the continued ignoring of the actual proposals on the table and introduction of distractions like Ingemar's "proposal" here do not help getting to any conclusion. While I am understanding, I have zero leverage here, I want to explicitly state, that if L4S was a scientific experiment, it would have a hard time passing peer review... (it never is a grear idea to alienating all possible reviewers).


Best Regards
	Sebastian


> 
>> 
>> Unless the answer to that question is YES, let's just drop this proposal, okay?
>> This is not a path to a productive discussion/outcome.
>> 
>> Best Regards
>> 	Sebastian
>> 
>> 
>> 
>>> On Mar 28, 2021, at 22:03, Ingemar Johansson S
>> <[e-mail]> wrote:
>>> 
>>> Hi
>>> See below [IJ]
>>> 
>>>> -----Original Message-----
>>>> From: Jonathan Morton <[e-mail]>
>>>> Sent: den 28 mars 2021 21:34
>>>> To: Ingemar Johansson S <[e-mail]>
>>>> Cc: Sebastian Moeller <[e-mail]>; Pete Heist
>>>> <[e-mail]>; Kyle Rose <[e-mail]>; C. M. Heard
>>>> <[e-mail]>; De Schepper, Koen (Nokia - BE/Antwerp)
>>>> <[e-mail]>; tsvwg IETF list
>>>> <[e-mail]>
>>>> Subject: Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)
>>>> 
>>>>> On 28 Mar, 2021, at 10:01 pm, Ingemar Johansson S
>>>> <[e-mail]> wrote:
>>>>> 
>>>>> All I see is that this RFC3168 AQM is brought up repeatedly, when
>>>>> prompted
>>>> about the possibility that even RFC3168 AQMs can be updated…
>>>> 
>>>> The point here is that even if *some* existing AQMs can be updated
>>>> easily, there will be some which cannot or will not.  These are what
>>>> you must pessimistically take into account when analysing the risk of
>>>> deploying L4S.  Until you absorb that knowledge and start taking it
>>>> into account, you're not going to make any headway.
>>> 
>>> [IJ] And these that "can or will not.." will then continue to run across the
>> internet 10 years from now ?, 20 years ?.. Network gear is constantly being
>> replaced with the reason being that they either become too old to be
>> economically feasible to maintain or that they just break down. Home
>> gateways breakdown or are just been replaced because they don't meet
>> new demands. You don't normally keep a PC for more than ~5 years for a
>> bunch of reasons. Why would you keep networking gear for decades ?
>>> 
>>>> 
>>>> - Jonathan Morton
>