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

Sebastian Moeller <moeller0@gmx.de> Fri, 26 March 2021 11:55 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 413E33A1C8C for <tsvwg@ietfa.amsl.com>; Fri, 26 Mar 2021 04:55:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 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_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 lacXosFQmkcB for <tsvwg@ietfa.amsl.com>; Fri, 26 Mar 2021 04:55:34 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 929F13A1C92 for <tsvwg@ietf.org>; Fri, 26 Mar 2021 04:55:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1616759685; bh=wIgn3pj2m+P9CuuprJz/iTV5R8w8jZpkq7j4e4P03Ro=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=lNJ7qNBpsZ+Ax0tt1I8pNBsxkbCEvlDlu2aABJHIsOW7OHSZs5j7mZWX2mlaY4od8 8mvJnhNIkmNOJMawJpD8BbA7XeskeoFWEJRaK0EJE4bNiNI5pRLhTXgLxxoVzAd/eT mIolW0WrG80icpDv3w0n9ZAkwrw8oRM0F4WLnG48=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.250.106] ([134.76.241.253]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MkYc0-1m4tZL19dW-00m0QV; Fri, 26 Mar 2021 12:54:45 +0100
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: <AM8PR07MB747675E421F0B7A6246C67BEB9619@AM8PR07MB7476.eurprd07.prod.outlook.com>
Date: Fri, 26 Mar 2021 12:54:43 +0100
Cc: Jonathan Morton <chromatix99@gmail.com>, Bob Briscoe <in@bobbriscoe.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9A9D4AC3-43F0-4778-839B-E1E247A3C5FA@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>
To: "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>
X-Mailer: Apple Mail (2.3445.104.17)
X-Provags-ID: V03:K1:7nAoW/vnNmE1QqCiYjjojnv6Tb94KlOqb99hkMkO7kLC+tINHu3 1lvYgx/HbJwksp9mH28WyqI0BWZObqqjvJ5Vd9IPkBS63BCQhyJaBCjZQ2EQp7+9Z+/Cjd4 P7Jb/aW5X+PlP8sFOuh+/6bGR3LuaIXmyDNU6jk1Z9Lv5b9VnSwwDDM0LJNMQbecxCZqPnG SzokDXsC/pKqT8fSI2h9w==
X-UI-Out-Filterresults: notjunk:1;V03:K0:T63rgCyosiU=:GRt+1wP8frMDobsFRPRiFS 5kkuCw12S9boMaSJVdqAsUcRy3azqlORdnch1r8GI9WWisEECSX9JW85Fq3WlcyclPvvpSRvC 3mYmwLF8I5bXwYzyawYouwGQ9ytoSGPOhZ2nZD3HOzLIFPK3zayGVjCh6combkdKI24UdhYit LXp1qQOcExYX3ocV7bUdn8Spxdhp8gYMm4ny72r46W8TfcyXv+4ihkbBnJ7O600BmTUDGF/0A NSLQSUI9MTfOclX6xe5lX77dv3z1PXS3AKYfT4NNdEwugngRq2AmbeTXAhWWrWbcL2EL+frDb CBHX3BkJEtK/rz+wn8yeVhTwud14UqMRJ+o0grRS3JJ79+ifIQySabnAntlc/1tXELSjDk4rd ItmQWtJ9kzOuFT6GbpbZrgqFNYz3Y6HwUGe5c/6VbeCgOJqjSBbc2bNj0/z3td0uBsljnpBqj JRuKorlyrWzH8vVyggraJKDynDuNIvep67qSNajW6b+izYn4PC1Sat1FjdeAAsSMUJIMCVS8x 67xBfD6JkdrFwXt7H1otB+Xy2/CDlvlMpPT6vK5aDnWH33kVIGaqaQDqZGnfjr3qfbMh5IMFC 8DBSVlcXBBVV4ovGNjpZm7cYItqjq9WEQ8KjttnpqZq9bjalCdCsemm6ynS+yq67x649Tq4tY l9C8GI6M4Bmwgnx8YtfHi7GHqlnDVT/Gl4HyIaWLtC2DQ3PDXmr9IA2YfMPfQtEuAXspPDmBE 96vGDAcIkTmxNXH3MBmgBU4DKZHLPZIO0QnsZf20vOU2lfHwbpJ4AxhLEbGWBbxiBFzBVjp25 iXaGvWROWhmSjlp+5lyVcR1dTLuNXSAgPrszw7jBmtxOu+ZkL69Dr3tmlnj9EKn+BMXunH7eM YS2DfjFDM9jMZ0zHurKxZy31qpQMVrJ6l+JEmOcBCl40G3Lji8QSJOJc6Hqg44xmun6OZMmF/ Q6ToqqN3IkJhIvnuxHeJJc6cAiQAZCkOQq6Nw7eVhUCkmg5L+UuU3ffIs6YUNDyEjBSzN/GQQ F79AflkbVDwmUY0vOjJGAI6LyXsbkbGUmZLhDJyYWTVDFWoODtZXUo3/GJAw5A2z6rOVTkxkd kADweXibPC8KSDqZqZUTK3kphtEm6y4QE6WTKPwGQEMWemZvO137agpHFbdStA4E22x9B+ZSK EoCoO+r/wK3BOkZSqv4irXfkhdgT48iefgNugRoSJusjdRsEYXvMM4JmZwFd7wxfRe9bU=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/nr-fjiGSRmvJHSxDePotIzJPHIY>
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: Fri, 26 Mar 2021 11:55:39 -0000

Hi Koen,

more below, prefixed [SM]. But as a preface, it seems while you addresses this mail at me, you do not actually discuss my proposal at all. Why?
	While I am fully sympathetic to the proposal to re-jig L4S' signaling mechanism, all I was/am proposing is a method to contain potential fall-out during an L4S experiment to those voluntarily participating in the experiment, while keeping innocent bystanders reasonably safe. 
	Is my proposal 100% perfect or technically elegant? Sure not, but it does not need be, the initial "mandatory" life-time of this would only cover L4S experimental phase and a PS phase only IFF it had proved itself to be functional and feasible, so the containment mechanism would need to survive the same level of evaluation and scrutiny as L4S itself.  



> On Mar 26, 2021, at 12:07, De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com> wrote:
> 
> Hi Sebastian,
> 
> The NQB codepoint is not needed to make L4S work.

	[SM] I know, but I did not claim that (the guard DSCP is about making the L4S experiment safe, not about L4S' core functionality). My claim is, that the biggest expected immediate user of L4S saw it fit to make sure that an L4S-DSCP exists. This indicates that they do/did not share your concerns about the applicability of such a DSCP. And in actual discussion Greg seemed to indicate that he sees the fact that SLA's/TCAs might be required to guarantee safe-passage of such an L4S-DSCP as acceptable and clearly not a show-stopper.


> It could be interesting within small network segments (near the access edges: home and DC, not the core) to add more traffic into the L4S Q. I don't think anyone considers it very realistic using NQB as a widely deployable E2E feature, although it would be a bonus if it would finally, and RFCs should allow it to become that. That doesn't mean it will be a fact within the next decades.

	[SM] Mind you, you are still discussing the "make DSCPs an integral part of L4S signaling" proposal. For my proposal of using a guard DSCP for the duration of the L4S experiment, your arguments do simply not hold. Not propagating by default E2E is part of what makes a guard DSCP actually helpful to contain an L4S experiment to participating networks. Also, the one use case where L4S is going to work for reasonably well, is short-RTT, low-hop count "fast-lanes", say, between eyeballs and content providers, a situation that typically involves a sufficient low number of AS/networks/actors to make the "negotioate DSCP-passage per contract" approach feasible.


> 
> I don't think your proposal is very simple,

	[SM] Well, the problem is complex, so any solution will have to have some complexity in itself, but conceptually my proposal is rather small; I do not claim that implementing it might not take work and effort though.

> and has quite some impact on all parts of the architecture.

	[SM] I disagree, adding configuration options that are required to be active for the experiment, will allow to require/allow to change these to inactive for full standards deployment. The impact would be to add these features/capabilities for the duration of the experiment sure. IMHO adding these sounds preferable than not running an experiment at all... As David indicated, with a safety proposal similar to my rough idea, the L4S experiment could have probably been started years ago, so is not changing the implementation really worth years of wall clock waiting time?


> If DiffServ would be in the picture, I see the DiffServ-input and ECN-output as the only simple straightforward solution.

	[SM] I agree that this sounds like a better design, than what L4S proposed right now, in regards to safety-by-design, but I maintain, that even my more modest guard-DSCP proposal might unlock the path to experimentation sooner. I would be delighted, if during experimentation such an "DiffServ-input and ECN-output" alternative would also be tested.

> It removes the disadvantages of both while keeping the advantages of both. This was always my understanding, and I don't see any reason why this has changed. Let's keep things to the point.

	[SM] Well, that is not my point, so if you will. I keep sticking to my point. If you want to deploy L4S signaling as currently designed and implemented for experimentation in live production networks soon, put L4S under the containment of a guarding DSCP would be a great way to convince me of the safety of doing so. And I assume that I am not alone in this.

> 
> Would you want SCE only to work if it has the right DiffServ codepoint on it? SCE would also need the DiffServ codepoint to protect SCE from non-SCE traffic. Even when using FQ, tunneled SCE gets trampled over by non-SCE traffic.

	[SM] I defer to Jonathan's point regarding fitting SCE-style ECT(1) output signaling into L4S. This is orthogonal to the issue of how to make experiments with existing L4S design and implementation safe.

> 
> Again, the only question is, who wants to deploy a feature that relies on a DiffServ codepoint that needs end to end path support??? 

	[SM] According to the NQG ID, Greg, assumes this to be an attractive feature. I assume that Greg speaks on behalf of CableLabs and also assume that CableLabs thinks that DOCSIS-ISPs will be interested in that feature as well. I did not notice you objecting to the NQB draft based on your doubts about DSCP passage... 

> Let it be clear: I'm NOT. I think this is suicide...

	[SM] Why? And "suicide" is not really an appropriate term here. That said IMHO, L4S is not going to fail because of a DSCP requirement; L4S is going to fail because L4S-compliant protocols fail to compete sufficiently well on non-L4S bottlenecks, and because L4S bottlenecks give such an undeserved advantage to L4S flows that folks will disable these pretty quickly. Whether or not you use a DSCP, is irrelevant to the sad fact that L4S is simply not ready for anything else than Eyeball<->nearCDN fast lanes (where ironically, DSCP can be reasonably expected to be E2E, either by default or facilitated by SLA/TCA).


> And I understood that was the main consensus during the input/output vote, and the main reason why people accepted L4S with the small risk of getting too high throughput, rather than SCE needing FQ or getting again the delay-based problems (getting trampled over by loss based and CE-only CCs).

	[SM] If we actually had asked folks about their motivations, we might know, but we didn't... so let's not go there, please.

Best Regards
	Sebastian



> 
> Regards,
> Koen.
> 
> -----Original Message-----
> From: Sebastian Moeller <moeller0@gmx.de> 
> Sent: Friday, March 26, 2021 9:06 AM
> To: De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com>
> Cc: Jonathan Morton <chromatix99@gmail.com>; Bob Briscoe <in@bobbriscoe.net>; tsvwg@ietf.org
> Subject: Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)
> 
> Hi Koen,
> 
> I think none of this addresses my simple proposal to use a guard DSCP for the duration of the L4S experiment. Looking at the NQB ID (https://tools.ietf.org/html/draft-ietf-tsvwg-nqb-05) and the low latency docsis (LLD) ID (https://tools.ietf.org/id/draft-white-tsvwg-lld-00.html) I think I can even propose a candidate DSCP pattern: 0x2A (for the use as guard DSCP the fact that this has a lower per-chance traversal likelihood than say 0x02 is actually a feature in the context of a guard DSCP). 
> 
> Here is cable labs position (NQB is used as synonym for the LL-queue and traffic having appropriate properties to qualify for the LL-queue):
> "As of the writing of this draft, it is proposed that the DiffServ value 0x2A be standardized in IETF/IANA to indicate NQB [I-D.white-tsvwg-nqb]."
> 
> So it seems pretty clear that one of the biggest drivers behind the L4S effort already assumes that a L4S DSCP is viable, desirable and standardization is already in process. One could say they consider "DiffServ [...] as a widely deployable technique on the internet", no?
> 
> Since I have seen no arguments from you on the list arguing against the feasibility of an NQB DSCP/PHB, I wonder why you accept that as viable for the NQB draft and LLD, but not for L4S. Especially since LLD contains L4S as one of its building blocks?
> 
> Best Regards
> 	Sebastian
> 
> 
> 
>> On Mar 25, 2021, at 18:54, De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com> wrote:
>> 
>> If using DiffServ is considered as a widely deployable technique on the internet, then we should simply use DiffServ as the "input" L4S identifier and use SCE as the congestion "output". I don't think we need more complex experimental schemes, especially if they end up needing a final DiffServ codepoint anyway even after the experiment (like in Jonathan's proposal).
>> 
>> As such it would be the perfect marriage of both L4S and SCE. So an AQM can only mark SCE if it has the DiffServ L4S-id and can protect and isolate the L4S-SCE flows from flows not responding to the SCE marks (in a DualQ or FQ, or any other scheme detecting presence of non-L4S flows).
>> 
>> This was one of the options that was considered before and which would be the simplest solution involving DiffServ.
>> 
>> The question was and still is if DiffServ "is" the perfect wedding proposal for Internet wide traffic. How many more hurdles do we need for deploying scalable and smooth congestion control (which is I assume the common goal of both L4S and SCE).
>> 
>> Main question is: Is the risk (pushing away Classic flows on a RFC3168 ECN bottleneck after tens of seconds) worth the extra deployment obstacles (practically making its deployment as constrained as an end-to-end managed service).
>> 
>> If the answer is yes, then we should define a DiffServ codepoint that identify L4S and only use SCE for those. If the risk is assumed minimal and comparable with other experimental CCs (see ICCRG https://datatracker.ietf.org/meeting/109/materials/slides-109-iccrg-the-great-internet-tcp-congestion-control-census-00), then we live with the (small?/controlled?) impact.
>> 
>> I understood the latter had the biggest support in the input/output vote during the previous interim. I think if L4S flows are not used for long time downloads (non-application-limited flows), the impact is minimal and a 3168 detection and fallback would never be needed. It also was known that Classic bottleneck detection would be a challenge, but I think Asad/Bob showed that a (maybe not 100% perfect, but already) very good implementation is possible if needed for the problem conditions that are known then. These could be used (experimented with) when using L4S for downloads.
>> 
>> So bottom-line question: Who believes an end-to-end DiffServ solution is realistically deployable???
>> Second sub question: who believes L4S is a bigger risk than all other CCs "experiments" on the Internet??
>> 
>> Regards,
>> Koen.
>> 
>> 
>> 
>> -----Original Message-----
>> From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Jonathan Morton
>> Sent: Wednesday, March 24, 2021 11:24 PM
>> To: Bob Briscoe <in@bobbriscoe.net>
>> Cc: tsvwg@ietf.org
>> Subject: Re: [tsvwg] L4S DSCP (was: L4S drafts: Next Steps)
>> 
>>> On 25 Mar, 2021, at 12:10 am, Bob Briscoe <in@bobbriscoe.net> wrote:
>>> 
>>> Can someone explain for the record how using a DSCP as an L4S identifier would solve the CE ambiguity problem?
>> 
>> It doesn't.  It only allows containing the resulting harm to participating networks, thereby protecting (most) innocent bystanders.  It's enough, I think, to conduct a field experiment to discover just how bad the problem really is in practice.
>> 
>> This is predicated on the notion that the L4S-ID DSCP(s) are bleached or dropped at the participating networks' border, and in the case of border bleaching, that L4S endpoints interpret CE marks *not* carrying the L4S-ID DSCP as per RFC-3168 or RFC-8511.
>> 
>> I refer you also to my recent post titled "L4S, DSCP, and RFC-4774 Option 2" in which I give a more detailed explanation of a two-DSCP proposal.  The short version is that a version of L4S using that scheme would have *some* positive confidence whether or not they were receiving L4S or conventional marking, without the need for heuristic probing or monitoring.
>> 
>> - Jonathan Morton
>> 
>