Re: [tsvwg] DSCPs and L4S: Label DSCP

Jonathan Morton <chromatix99@gmail.com> Sun, 30 May 2021 14:31 UTC

Return-Path: <chromatix99@gmail.com>
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 51A223A3E20 for <tsvwg@ietfa.amsl.com>; Sun, 30 May 2021 07:31:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=gmail.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 v7RZtK6jLFsy for <tsvwg@ietfa.amsl.com>; Sun, 30 May 2021 07:30:57 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 D80753A3E1F for <tsvwg@ietf.org>; Sun, 30 May 2021 07:30:56 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id a5so12861211lfm.0 for <tsvwg@ietf.org>; Sun, 30 May 2021 07:30:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DTfBFaltM5jJm2cKzwAKtCVRGgXLXbl2el8cJy6XWEA=; b=pAKlD6g4/NuSawV0aHsVtrDCrhVLtmhoitmrA6ayE30UfO6ZM6h8Hv05C0L0pYb6nk UPHdLRqWLyk3Qk+XKrJndPSybd+H0jgW1vnCZLI4MuA1N7Kphnp1MGaRO7/G788nWDOz GdvWptRwrEaP7r3HM/phWZp2phRw3C/VylXAodUtqKIgI1o9cK5+USm8K3M/mo88y0OH Cd3njgECK7X8ik7c9vIEdmzoq97FgrDi3qvLhiySYJcN0F5HkNHyM3tq/LH6oJ/SS+qz zHMVIp+EOYwpgVXPqiJ0RIWI2tAnlPgbya/B5khNSf2AgDdrV374wridD4SCaZcZb149 jxuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DTfBFaltM5jJm2cKzwAKtCVRGgXLXbl2el8cJy6XWEA=; b=kNoRAHBhveNEXeD22STYcTTcwS3VE6oobHaWRnbLbjKZwUX/iBBE7FcI23pS5zvReQ tqIgXjR4WKjjosF+JZ+cysXf1zm8xIf6REvxOpphNjFMqUfQgR6PF9Q5dBi7H8n1E1RD 5BOeKN4UxHrbqKsk9eEpYhKaT3c6xuXaB4gYKPMdPMJeGfNn2OKklwJlWPBj5RDv/2bR IbDbKLKhAGGMZS25lTUhrNQ/WE7/MhyPqZEkL9Gb3yXESV0/ABkIIHM9XzocunddLxtH C3EADL3qMOeW1lsinEBrQs1a4GFX67WmvTdXdkV1K1MqSvBs2x+HdrtPvYgCb8uFpouH dKtA==
X-Gm-Message-State: AOAM533nJRQqAHZ4BY17T6dmZ3TRTQ6q458ovBofAaSDg3QQAvGbqJhZ AhqLBTUA0vfwBdBeevd8pH4=
X-Google-Smtp-Source: ABdhPJx9Lgd0qa3N0cTtoaeVgpB/0pw5JENi7TsFXYTRRrlMLb5+pkQ6NE4DI2OCoR2EzEpsPTP2Qg==
X-Received: by 2002:a05:6512:22d5:: with SMTP id g21mr12225105lfu.80.1622385054384; Sun, 30 May 2021 07:30:54 -0700 (PDT)
Received: from jonathartonsmbp.lan (87-93-133-133.bb.dnainternet.fi. [87.93.133.133]) by smtp.gmail.com with ESMTPSA id d21sm1033211lfs.165.2021.05.30.07.30.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 30 May 2021 07:30:53 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <e2bd16c2-373f-8eba-039e-445337e2aaf0@erg.abdn.ac.uk>
Date: Sun, 30 May 2021 17:30:52 +0300
Cc: "Black, David" <David.Black@dell.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BA453B4E-DEDA-45D6-AA2F-A6BA21F181EC@gmail.com>
References: <MN2PR19MB4045CC6F321E5B64B152FF0183229@MN2PR19MB4045.namprd19.prod.outlook.com> <6B4684DD-8130-4D0D-9061-DB2671650797@gmail.com> <e2bd16c2-373f-8eba-039e-445337e2aaf0@erg.abdn.ac.uk>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/23uVKyg2QQ10SUXpsAS0xlqVP4U>
Subject: Re: [tsvwg] DSCPs and L4S: Label DSCP
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: Sun, 30 May 2021 14:31:02 -0000

> On 30 May, 2021, at 2:20 pm, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
> 
> * This proposed approach is/was already possible for an operator/network using DiffServ without any IETF specification using an Experimental or Local Use DSCP from Pool 2.  One key aspect of the proposed re-design is to require assignment of a specific Pool1/3 DSCP or set of DSCPs to  identify L4S traffic. It seems highly unlikely the IETF will want to standardise a large set of DSCPs.

I think this is consistent with the initial use of a Pool 2 DSCP.  Discussion of whether an allocation in the other pools is warranted can take place later, with the benefit of field experience.

> * I expect the proposed experiment will not be attractive to people who are already using a set of DSCPs (e.g. to ensure traffic is queued/mapped in a way that reduces the latency of WiFI, MPLS and other subnets). How would such a DSCP assignment consider methods that expect some DSCPs to be mapped to lower latency treatments that are below IP? Is that OK?

I doubt that the set of DSCPs in use on any single network precludes the temporary allocation of one more for experimental purposes.  If that is an actual concern, let the concerned speak up for themselves.

> * Specifically, I don't think the current proposed behaviour of the DSCP Label is what was requested in the NQB draft. I think the latter seeks codepoints that can work end-to-end, and wouldn't be remarked at DiffServ domain edges. I'm not sure whether NQB traffic would therefore be counted as L4S?

David Black's wording permits the use of other DSCPs to explicitly include or exclude traffic from the L queue.  I think this is compatible with parallel use of NQB.  You may be right that this consideration excludes the NQB DSCP from use as the Label DSCP.

> * l can see the proposal could be used to defer the assignment of the ECT(1) codepoint, and would postpone any decisions about the need to obsolete the current ECT(0) usage - perhaps this is good for those who are focussed on other proposals, but is this delay to allow more experiments what is also wanted by others?

No comment.

 - Jonathan Morton