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

[Sebastian Moeller <[e-mail]>]

Hi Ingemar,

more below inline, prefixed [SM].


> On Mar 29, 2021, at 09:36, Ingemar Johansson S <[e-mail]> wrote:
> 
> Hi
> Please see inline [IJ]
> 
> /Ingemar
> 
>> -----Original Message-----
>> From: Jonathan Morton <[e-mail]>
>> Sent: den 28 mars 2021 23:30
>> 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) <koen.de_schepper@nokia-bell-
>> labs.com>; tsvwg IETF list <[e-mail]>
>> Subject: Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)
>> 
>>> On 28 Mar, 2021, at 11:03 pm, Ingemar Johansson S
>> <[e-mail]> wrote:
>>> 
>>> And these that "can or will not.." will then continue to run across the
>> internet 10 years from now ?, 20 years ?
>> 
>> Yes.  Exactly.
>> 
>> I mentioned before that Pete's Czech ISP is still running 15-year-old
> routers
>> that date from their founding.  I personally still have a "UFO" Apple
> Airport
>> Base Station - the original one with 802.11b, 56-bit WEP, and a 56K
> analogue
>> modem - which doesn't get much *use* these days, but it still *works* and
> is
>> potentially useful.  Heck, I still write code for 40-year-old computers as
> a
>> hobby.
>> 
>> These old devices lack support for newer specifications.  But they still
> work
>> just fine in an environment that does use them, because backwards
>> compatibility was designed in when the new specifications were published.
>> ECN Capable transports still work with dumb drop-tail FIFOs, and Ethernet
>> frames carrying IPv6 packets still traverse Layer 2 devices that were in
> the
>> shops before IPv6 was finalised, and which require IPv4 (or maybe
>> AppleTalk) packets to configure the settings.  That is how Internet
>> engineering works.  In general, old network devices are expected to
>> continue working as before, and you only need to upgrade if you want to
>> benefit from the new technology.
> [IJ] OK, Sure, you can bring up all sorts of gear that can run like forever.
> I have a 40 years old cassette player that will only need a new rubber drive
> belt to be functional again.

	[SM] Your "walkman" is in all likelyhood not deployed over the internet, and hence this argument is not helping with the issue at hand. Sidenote, these "real life" examples tend to be really bad analogies for packet switched networks like the internet, can we, please keep these out of the discussion?


> But my take is that we are not designing
> protocols mainly for a few thousand netheads who can tweak old gear to work
> indefinitely long. ld have 

	[SM] Correction, team L4S is not actually designing protocols at all, they only took on wok on TCP Prague, since without any theoretically deployable protocol it would have been even harder to get their ID's describing the network bits of L4S adopted... The current attempt is mainly about forcing the network bits onto the existing internet with as little restrictions and safety as possible, as apparently safety is considered only as a hindrance for L4S expected evolution... Why are we actually still contemplating such haphazard engineering, again?


> 
>> 
>> But L4S is *not* designed that way.  If it is deployed as-is without
> effective
>> guarding, it will break quite a lot of stuff that isn't even very old.
> Your best
>> proposal is to scrap or materially change an existing specification that
> is
>> currently rapidly deploying in the Internet because people see real
> benefits
>> from it.  It's entirely conceivable that Pete's Czech ISP will choose this
> year to
>> finally upgrade those old routers, *specifically* for the purpose of
> deploying
>> fq_codel, now that they have some experience with it - and that would
> start
>> a new 15-year timer, wouldn't it?
> [IJ] Not necessarily so. 
> 1) FQ-CoDel as well as other AQMs can be updated to follow
> https://www.iana.org/assignments/dscp-registry/dscp-registry.xml and as a
> first step treat ECT(1) as Not-ECT. 

	[SM] Yes, I failed to see your patches so far on LKML though.


> 2) There are good reasons to make these devices upgradeable e.g for security
> patches, a full L4S upgrade could go in there.

	[SM] +1; but no amount of wishful thinking is going to solve the fact that currently deployed gear will stay for a long time on the net. And the security consequence of that is a real life nightmare. But even though this is potentially catastrophic it has NOT changed into a worls where automatic updates are the norm and where old insecure software gets replaced in a timely manner. IMHO the security consequences/side-effects of that are much more severe than the slight inconvenience this causes for L4S's potential deployment, and yet not enough parties care (including e.g. smartphone manufacturers that only supply OS updates for a short number of years, explicitly giving a shout-out to apple here, with ~7 years software support they are leading by good example, the android side is in a sorry state comparatively).
Tl;dr: Automatic updates and security fixes are not going to magically start working well enough any tie soon, to be a viable solution to L4S's coexistence issues with rfc3168. It would be great if that would be different, to that I agree.

Best Regards
	Sebastian


> 
>> 
>> I've personally put forward two different ways to make L4S safely
> deployable
>> in the past week - one which requires only minimal technical changes to at
>> least try out, and one which changes much more but which I think will work
>> better overall.  As before, it looks like those suggestions are being
> rejected
>> out of hand (though Koen's attitude appears to be more balanced, for a
>> change).  This is precisely what has delayed L4S for two years and
> counting,
>> and there is no end in sight.
>> 
>> - Jonathan Morton