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

Sebastian Moeller <moeller0@gmx.de> Mon, 29 March 2021 08:23 UTC

Return-Path: <moeller0@gmx.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFCB13A34D1 for <tsvwg@ietfa.amsl.com>; Mon, 29 Mar 2021 01:23:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Level:
X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKuJqzKqtuEt for <tsvwg@ietfa.amsl.com>; Mon, 29 Mar 2021 01:23:35 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44B4E3A34C6 for <tsvwg@ietf.org>; Mon, 29 Mar 2021 01:23:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1617006203; bh=cQA8ramp9+vWOe8m10PdpLOmzNPQCNGMt40AhJPOVIQ=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=GcpKTVJOOL62cNlKoeK1j3bbmHF2slakl+nYn7H4uax9AQVdW5KxvL9HTYKtgxInD w/9E2HzfScSkrUzncZ01/XGyDXtKkw80W7UOffz+ZNp5H98/XeuvTFk4z0opmkxBVz UEejx6RfabOXhFU5YFPIHGENEilvRkuLTasnaZlI=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.250.106] ([134.76.241.253]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MNt0C-1lFrzn0pVA-00ODGX; Mon, 29 Mar 2021 10:23:23 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <HE1PR0701MB2299F7033E3E8857DD57F2AFC27E9@HE1PR0701MB2299.eurprd07.prod.outlook.com>
Date: Mon, 29 Mar 2021 10:23:21 +0200
Cc: Jonathan Morton <chromatix99@gmail.com>, Pete Heist <pete@heistp.net>, Kyle Rose <krose@krose.org>, "C. M. Heard" <heard@pobox.com>, "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>, tsvwg IETF list <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2CD12837-DEC7-4F01-8144-CA266B13354C@gmx.de>
References: <MN2PR19MB404527384A1B1DD9CFC2A3D983659@MN2PR19MB4045.namprd19.prod.outlook.com> <6f0ac4bf-bd1a-65cd-1d40-a97d4aa71aab@bobbriscoe.net> <7B4426F9-E1C5-4F88-A264-0D54C809D523@gmail.com> <AM8PR07MB74761AFC8F5BE0F9573DFF32B9629@AM8PR07MB7476.eurprd07.prod.outlook.com> <6481E606-2458-49D7-B580-8DF7B93494FD@gmx.de> <AM8PR07MB747675E421F0B7A6246C67BEB9619@AM8PR07MB7476.eurprd07.prod.outlook.com> <9A9D4AC3-43F0-4778-839B-E1E247A3C5FA@gmx.de> <AM8PR07MB7476026EA3AA7AD49622B296B9619@AM8PR07MB7476.eurprd07.prod.outlook.com> <CAJU8_nUgNa-W4wf2Vb8sUUqv4XUsSFdVQFUWwrTGw0gDshahiQ@mail.gmail.com> <92b3b23db1dc4ce11162a31acf83c0dd01868a27.camel@heistp.net> <HE1PR0701MB22999F18CBC7874B410B5E13C2609@HE1PR0701MB2299.eurprd07.prod.outlook.com> <9839D5ED-78DB-4F91-99F9-39CAB8C2121B@gmx.de> <HE1PR0701MB2299A10C53522C01802BDBBAC27F9@HE1PR0701MB2299.eurprd07.prod.outlook.com> <19119AD1-F49E-4B58-B988-E487391121AA@gmail.com> <HE1PR0701MB229922BAC35171679447AF3BC27F9@HE1PR0701MB2299.eurprd07.prod.outlook.com> <B459FC22-1F43-4812-951D-6247124417C4@gmail.com> <HE1PR0701MB2299F7033E3E8857DD57F2AFC27E9@HE1PR0701MB2299.eurprd07.prod.outlook.com>
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
X-Mailer: Apple Mail (2.3445.104.17)
X-Provags-ID: V03:K1:Nd1jXZlcgrwkLDhr9ZohfV437RGsJ+yfx1ErPrDvqBtNVRZ+KSH ijkRkROKcETw76lSAhrnMqUbGlLx/SE5eai0gh0AGcrEoRT634rubC1gUVqgBmtto4ZEG8c UuJzqaOJpwa76vKfxFbfL2RoSRlg7od+xj01mvgoYkbs2v9COzLExkyI0IPL9n0xltvDO4r Y8INREkgvmbjyASV0LEgw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:HWTFWw4Mr4k=:VglRu3dK4h6iX6IJ7cliyO 7CqUVPI3xGiWzzpxdqLdnwKDIFcJKB86KJTv+k9HPw2OZoyjuYTO7SlxjZuy4HgUp0cmRfnQO sJvmFZxGKnyjpHPf6jEOZwcsUPTPWvfSPPzu5WGeY44/BrGyR/DjGybLRoNjMQwPOqAVjnoNM Tj/BzgZl3N2qcEmGSc2Xq+f7Xe//GaXYJIaox4ME8YXIveMt3TTPQKTtGQPwc2Qk1ERVYBcBP 09tUH5fL/gp7dA/bK2UIOhf0SKaj2GimCvImpyGuheKH2a8v3x3RFn3zRGJUCcUXnmVzX1y4J sywaDmsoSsc+X3eUbcbENDaiHmjFJSuZtdwHfZzO2MUI5N6b0nK8DrGKBZr5Buetk4I7DmwAo W/NfMyDuJB/Ht2mgDRJhBaZmmkeFFObDvJLuohDl8KuJ5XMaquYhNgYE+fPQNCIIjNiU3GGW4 H6nYIH5d+pWZOaqy6uMyUBGbmiydQvhpcDGH+qzHC7kYRAsCLZlqQz57bIYCAm8/VRf0Mc6wa 6kBXy4AGYOfDpOcNyEOa7tc+IXcq92BvW1FZf2NTkX4It4XaQ/BmyRi6T6euE4CuOEJ/+KrsW jEIt7S4SkdKEfbCxXgA4qO83Ue/kVcWaoBHMLsECfEiuam22kA8vh9/c0qJlgzAp4FJsIODs7 D2lhu4shTQbo+V1zeMGS6m/3/DoVrgU9YRHgBBLDkNOVzBf9RqOEnSx+sZBq90SMXU5p1NSrT IymMew/ciShGOBMGGm3epkw8MGXbUFMt2UR0EpheEdwr8AbOtUoeODlWcthdJIrFXP3qMIGx/ xVSQE4r8fJGjI7YIS//QmeLbo4oZVBWEmRwrCvZC1k9Cy03jXEeOzXwaNGWZggxT1aKqePGEb FqjN7aqkZxqxyk3RZeF4S1SHDQgT9feAYBfZ1EokPET7yhczENlHRpoLpLkPgJer7iVv9Ob85 Kx2sxw98oeBSPRC6zvqvjqvegG/VHXK9wMvzpqxjUqtZBfzxDOuTIYx/l0ZUEsNRAOJfu8h9D 3UO/xYp24Fzn6XOrlbf6jL3NHbhum1m2G5B+dF/VqMfjIrl1LsJ/8GxwoZdSzaCxcLWMG+jRa baC31EDigSrmsTfELXJGkknRfy1ZixitqcS2ZsO93Vl5CAa66MvvtQu3NVBFrly4/k7zWaGtc OHlNJ2htJL3Be2GPI0km/7Nzpo7v4aQnmHcEt7NdBou+wr1ywLIP5E4YiovVCNlkflxvM=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/dAWh7nf38VMTzgVZzFCIi7PdRnA>
Subject: Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Mar 2021 08:23:45 -0000

Hi Ingemar,

more below inline, prefixed [SM].


> On Mar 29, 2021, at 09:36, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:
> 
> Hi
> Please see inline [IJ]
> 
> /Ingemar
> 
>> -----Original Message-----
>> From: Jonathan Morton <chromatix99@gmail.com>
>> Sent: den 28 mars 2021 23:30
>> To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
>> Cc: Sebastian Moeller <moeller0@gmx.de>; Pete Heist <pete@heistp.net>;
>> Kyle Rose <krose@krose.org>; C. M. Heard <heard@pobox.com>; De
>> Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-
>> labs.com>; tsvwg IETF list <tsvwg@ietf.org>
>> Subject: Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)
>> 
>>> On 28 Mar, 2021, at 11:03 pm, Ingemar Johansson S
>> <ingemar.s.johansson@ericsson.com> 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