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

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

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. 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. 

> 
> 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. 
2) There are good reasons to make these devices upgradeable e.g for security
patches, a full L4S upgrade could go in there.

> 
> 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