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

"alex.burr@ealdwulf.org.uk" <alex.burr@ealdwulf.org.uk> Sat, 03 April 2021 11:06 UTC

Return-Path: <alex.burr@ealdwulf.org.uk>
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 036103A18F3 for <tsvwg@ietfa.amsl.com>; Sat, 3 Apr 2021 04:06:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.118
X-Spam-Level:
X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com
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 V47gkZYFlp0r for <tsvwg@ietfa.amsl.com>; Sat, 3 Apr 2021 04:06:45 -0700 (PDT)
Received: from sonic303-2.consmr.mail.bf2.yahoo.com (sonic303-2.consmr.mail.bf2.yahoo.com [74.6.131.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ABF43A18F2 for <tsvwg@ietf.org>; Sat, 3 Apr 2021 04:06:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1617448003; bh=DsuLB1yGVAW2s5ye7qLSgAO3le+lwCYjeR0g+bbMdko=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=qGsDS5rEoqWuFfz13WopUMLzjsFhmb14s+5GCbzG6zM0LNL1u8QsMHOP5P5qVnkgrNw0JbgEDEHFa0jciIQmpaEaHea/wc4Y/AyG7HaVTNAd8Sh0VYeHLEfRTUCmt1c/mSNHEXsN+41vGMzTKAq+PpX3AEDU3vpLGJDTrNZZ/F+f9qTifzVLmlZe0FFDIXqZFYvoVGcCbOKeNDrc9jlzYxdvFRfX5Baq977ty/duSkqx4RNCPeia7t8r2fN/8CRIWPfeYhKl7mmWb3rzpKh0S+9/RlDB8ibbjIf5JJl37hfCPxo4iewMzs2XxAwzFKsevzwsipBEf7+ljc96aGZ60w==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1617448003; bh=lfyWSphBHLT7vaVroVuQkJ43aOt23zKNj9TZCenkSVX=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=NaSJpvCFyM00GkkXnhVyE5ZhdnKlKNKAi0tugoL54qbJ9Xb0nsLrp7zDIieOsgIST09NMreSrKGUaht6HBNTCcC5AJJ5IrCGhghDd9rVvmtrYSmV9sW9csSEDOgXGoKToNsUxyYHzrATFUL2n97IiGEAwfki1FxxSSkpCKtlUdOec/zKMViA6rfaepjp1+6pJEIA6RF+131PlW0cEJp1lRnDvNo0pE5V9reFuy2eHUfqGPfLAFY6UZmSoZXDoVKAbSQwFfNy8NivqNbIRHSqexRnI6cEbdXqBSs93p/ieqUyHi2ipgDpiWdF050da3AfAAXfOTRj05U29v7SC/QCAg==
X-YMail-OSG: TuXpuAYVM1kd.GguW_ixqgatiXtfFtkMTK6gkLTfoUSnnAVenwmjzXRXrAnqQU. nN1G20rRGjJf_Ya_W7biJC4GLOsKLRM3pUMjCoYTYmkMwWra3cirb9kaMg11r4XvoOWxQ6iIIHDs rb4pjsaKwk5bI0gDmgXDKTfF1G9pxPJgg50kyK01ir.PS7nIDW1s.hLRiX75wNKj71yT1LXyENs5 bTcYg4a6m6xjDM4E25Y8r5uQIS1t60dDkw62d5U9qpuCEU1xNRr4LDzYLi4_9sMTQzYsAo_VGZq8 OkruU8EMBNG6_guwL3JtmJ.7noqvGA_e_jDX_FhoJIHSkqG87cMQAugAKF6lmDKKK0DAKQi6qXcb L_3QULNZb2vgp9G3Mk7.YRyhdr1CVRJj.UoB4lT4SV7ZjTlJDynD97LxBLGnRAgIiVjWiFvfvlr4 kfsSIhqq_5Qg9uYcKGHRafG5WPOn1fuHw5fWXU3cuhWJFOjwZeVaCzQw869Jh8.sfv0LpLDR7Sxf 8NrtYcuCq0mZAe0dEELOBqJXDJNsvobPIc8P77abmNClhHD3zzI4_1aGtnSGuKwWnVoHOeVWxaGA .JbaHyU3OVsjwJLtfHg8n9Lho27LvXFlCVFbZkdqaoSBhuVnW9AWx2WViydiqLzxcbGhFi0gV.A4 AWgIuOgFLp2fdj.r31K4A.bjOqh9ZknBz4O6_m1Tk9OIsLzUdIqRuad9Ogut5URlL5QjQeMp94ev PobnTnajyBBZLv8z9a3jQKuUSJu8buZ59ESKGZEQkW1O8Rlm9Uxo0AKluDFmFhi_mRnLCEr2Y4xr yhpcpMXw9YD2XRV6bFTOBepTCSqNULPE84TfO8YZbNJd2Cw0D4qqEOx6t4aPz_zMeqfB9gJpzZmV 8OhhGq4pd09Gv7g1QbCG68v6K7mOIL7psSPxA3G.k30T2CX7p4Gzj8n6QKCIWEy_76W1.YLzrxXC 40euC9RUw8TF4SKtDO1.SUDQULkYPxWPpTERsCM_.ek45FK_ix_83siickhWCHwF3lPbtEAU3Ny5 9aJAGdH80Zgo9VtaMaBDUsss1Il8tHU1Iw_iCG5OW9vqMFeuJGLxtSXRTvvzeEttk1gipqAgRQ0R Lbao1q9amDe6W6JOrq9y7.E5.qt9L_h76ytwaqBNL7cvfzN6tARiRtWYDetlowsMf3EFcq7MXmyG 40NwL8WuwVU6lHpISdo5RCOCdJWQ3cG3aiE0QJI3djBu.RGUcPvvDr3tc_zQedOxGJlRLbDgLOWF 7.P6p1JK1vKuhrNgXrB.yms3qDRbw4F.pu3QLFV8D1ynlmpQnNgZgnwlytHIY1.rMwUsta5Htkgp pzh2r11TtYFkQf2K6vtiQ6j1_lezwF5JB8hqlXO6JkjWs9lKhfe1mhWVag3Q5yfBcya__KJ4ooaf YZkprzMRa30XiXU1EnpHjwtZyruQLgb2ZAB4_4S_i3U2RwHmPGXTj3931PFo7twJNZoxCdSltmvp nxZqqBPyYgE6b1XiRi3il7jUrSPcDaqhHthYis1dMcTl361pN92rEmBvLgmIvKVl0hymwQX6DmvN kimuSqTDsmgPvcs_o2z0pXK60t_lnlgIB4eH5Syj83nrvBRCCsNq2G4xQuMw1CVYkXYxWV.tTk0Q jtdEeUSql8j38GWxHlgPyM.40935gWdO6apdGRg0TkmVcBPCt_joWnF59Bp_1xb_.1OzC4kxovBG aaq3gNzFLQ2T3NBVM4L3Z8286.LF6XOz_HYCiRDpk5nz_M4qdL1uCwFvFdbORTachFCnFgfgB3qz 165ymPBqYsz2lICQTR296wtoOBUBGBU52gredN_uKAZCxFnAiXALdbZrADK9FNMDevJqdIcHGWmj 5xXJlv0ugT5A_gqSHueLrg3iwR0IK9_L7blWmeFe97dyJwUk6f1Ko092rswZ.8Fl..iA9SCnPQK9 9iCEbSOsCYXIuj.lwmDa.Ifop8.kayNKPDYVR.Jlh6pKag0ghGE4ZRyNZNRD9h0hgL2qk0ASjDmV v_MT6FYRF5tqFAuXpiEtlFiXAFzYsP8Iaws5sVfaLka_rjjFr9PWDxMq3KUiIYn8bxq12sD1YkN. n1wPtHf631AKvMwoL3xgTTb9IJjoUQXmkJbHS4bV_OczS3skfRwycSfDTPOwYU5WVeIdmZj_JSwm 2paRkTgW0Nt1ghJNSJqmF8vSxfiRpvqBX3FrqpRwAmyWoPrgKHYZN.DTKdsl14Tm4BA83ULu598X susNIUnExhLkGYNtnyjOaoQnV7_FluoOEavSEvOII0_MclUfkWs69Ryc.M3ilU53mfm98syXnq_r V7BLdM4NJnYA45AoBhXoKHmmcrurYoV6F_nuk2icZ7SBKe5oc80zOQT6nqhAUyDL_ZE3jWpjI9yq tIqcB_325fL5qdQP90zCVe1QPc_bE_gbvSIFDkiXJ1NHLTL80wOSo7dRZyNCgYyBY5JgkwTkCCwL PBaybVLE0qLlkl17274sWzCDr7blgDWJVqwgIoZ_5JReOonRSTbmu6wvfG0ho77c6X_iOHUmxkQx HVf._Uraw33rr9ICo5cfgNB5zuA76D5HzSxEBKgiiZNvZXhxDfBWys6aDzUn_UIbCmlOPgljB4oX UI0yeStShsSeiPx7ssp.kxkUbdD1aSdDyyhH4AY0.51NEiPHrBC.e_uSDMh_Fe2VEdkYS0Q--
X-Sonic-MF: <alex.burr@ealdwulf.org.uk>
Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Sat, 3 Apr 2021 11:06:43 +0000
Date: Sat, 3 Apr 2021 11:06:39 +0000 (UTC)
From: "alex.burr@ealdwulf.org.uk" <alex.burr@ealdwulf.org.uk>
Reply-To: "alex.burr@ealdwulf.org.uk" <alex.burr@ealdwulf.org.uk>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: tsvwg IETF list <tsvwg@ietf.org>, Pete Heist <pete@heistp.net>
Message-ID: <316659632.1952357.1617447999612@mail.yahoo.com>
In-Reply-To: <B2D6891F-8041-4E9E-BE57-09C861702718@gmail.com>
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> <1841247348.815218.1617024220610@mail.yahoo.com> <B2D6891F-8041-4E9E-BE57-09C861702718@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_1952356_1023559423.1617447999610"
X-Mailer: WebService/1.1.17936 YMailNorrin Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/deay0GC542rY2FTP99hTZUctW5A>
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: Sat, 03 Apr 2021 11:06:50 -0000

 Jonathan,see below [AB]

    On Monday, March 29, 2021, 3:05:05 PM GMT+1, Jonathan Morton <chromatix99@gmail.com> wrote:  
 
 > On 29 Mar, 2021, at 4:23 pm, alex.burr@ealdwulf.org.uk wrote:
> 
> I can see that the idea of using a guard DSCP is proposed as a pragmatic way to make progress. However, I think an experiment isolated from RFC3168 AQMs by a DSCP would not, of itself, resolve the problem of L4S and RFC3168 AQMs. 
> 
> Suppose the L4S folks go away and deploy L4S in such a DSCP-guarded domain. They  make progress on some of the experimental goals listed in draft-ietf-tsvwg-ecn-l4s-id, and come back and say it works really well, and now they want to deploy it on the full internet. At that point, the WG is pretty much in the same position it is now - not knowing how to resolve the RFC3168 issue. Except that the stakes would be even higher, because:
> 
> - the L4S folks would have made even more investment in L4S, in a production deployment across multiple companies
> - Other folks would potentially have deployed more RFC3168 AQMs
> 
> So unfortunately it seems to me that, although it now seems pretty hard for the WG to reach consensus on  how to resolve the RFC3168 issue, waiting for a DSCP-isolated experiment will make this harder, not easier. I think if would be better for the WG to find a path to that resolution sooner rather than later. That's not to say that a DSCP-guarded experiment couldn't contribute to such a resolution, but without some agreement on what the path to a decision looks like, it's not obvious that one is essential.

I think I can agree with the above.

A single-DSCP containment can limit the harm directly caused by the experiment, but it's not a long-term solution since it still leaves L4S as an RFC-4774 Option 1 scheme which *needs* to be contained to specially prepared networks.  I note also that even this minimal protection is not being greeted with any enthusiasm by L4S proponents.  Your argument against it is, however, the most coherent that I've heard so far.

I suggested a two-DSCP scheme as something with more robustness and longevity than a single-DSCP scheme, while still fitting the "L4S way" of doing things and requiring only minor implementation changes to try out.  The aim here is RFC-4774 Option 2, ie. explicitly detecting which signalling scheme is used by the network.  It doesn't solve all of the problems, but I think it does illuminate one path towards success.

Since two years ago, SCE has been available as an RFC-4774 Option 3 solution, though it has been opposed by Team L4S as an existential threat.  Adding DSCP labelling to SCE allows it to be used with simple dual-queue middleboxes, so far as the DSCP survives in the network, as well as the preferred FQ/AF AQMs, and without the serious compatibility problems that seem to be inherent to the conditional redefinition of a CE mark.  The same DSCP label could be used temporarily as an experiment containment mechanism, though SCE doesn't really need it.

What do you think of the latter two approaches?


[AB] 
Regarding the two DSCP scheme, I'm not sure that I follow you as to how it avoids my argument above. Specifically, what outcomes of such an experiment would help us decide how L4S should interact with RFC3168 AQMs in the long term? I thought you might be saying that it allows the experiment to detect RFC3168 AQMs. But if we see CE on a packet that doesn't have the Y DSCP, it might just have been bleached. If we see a CE marked packet with the X DSCP, I guess that's more evidence of an RFC3618 AQM, which would at least give us a lower bound?
As someone who is merely an interested bystander, I am trying to be careful for to comment where I can't add value; where I don't comment this is not necessarily a criticism. I don't think I have much of value to say about SCE; AFAICT the no-one questions that using two bits would have been better if it could be managed, but the question is deployability (and incentives to deploy) in operators, on which I don't have the background to have an informed opinion. Similarly on the deployability of guard-DSCP schemes.

Alex