Re: [tsvwg] DSCPs and L4S: Label DSCP

"C. M. Heard" <heard@pobox.com> Sat, 05 June 2021 22:08 UTC

Return-Path: <heard@pobox.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 764783A3205 for <tsvwg@ietfa.amsl.com>; Sat, 5 Jun 2021 15:08:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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=pobox.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 zRhds3z5gE25 for <tsvwg@ietfa.amsl.com>; Sat, 5 Jun 2021 15:08:41 -0700 (PDT)
Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C9043A3203 for <tsvwg@ietf.org>; Sat, 5 Jun 2021 15:08:41 -0700 (PDT)
Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id BFA85CDE24 for <tsvwg@ietf.org>; Sat, 5 Jun 2021 18:08:35 -0400 (EDT) (envelope-from heard@pobox.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h= mime-version:references:in-reply-to:from:date:message-id:subject :to:cc:content-type; s=sasl; bh=wmg3u3vSRBYoZbFR3B+OTFdBBb2pVExW aw9PEbxWhTo=; b=lp1jjwxtVpfUfTLZP+BtX/8ppQwHZTn9D2sJOOETCJI10axb CBAlv3uBsj9XRzXu6Pxuvjk82eArMzz34R/hkJ2DXi1yuAJzG3dRKIhET1Wm1wKZ 9nyRa2j55g2MaYLD5PHxmUP4KpnPBMq6R+O+8mPtY8pEMAGfL9X2Cg9mDL4=
Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id B82D5CDE21 for <tsvwg@ietf.org>; Sat, 5 Jun 2021 18:08:34 -0400 (EDT) (envelope-from heard@pobox.com)
Received: from mail-io1-f50.google.com (unknown [209.85.166.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 2E5F9CDE1F for <tsvwg@ietf.org>; Sat, 5 Jun 2021 18:08:34 -0400 (EDT) (envelope-from heard@pobox.com)
Received: by mail-io1-f50.google.com with SMTP id b25so14296771iot.5 for <tsvwg@ietf.org>; Sat, 05 Jun 2021 15:08:34 -0700 (PDT)
X-Gm-Message-State: AOAM531rGJLp0Ce70jn415aRSJv/Bl8FLKb2p9w2TlpSgx19u94r8AE0 9FTOSMf9KBTGuK/lsHgVOsN0FwJYx7fIeTJR+tg=
X-Google-Smtp-Source: ABdhPJxti+RLFHyAfXlozJnBl/s10HgOMWQtF3tfhu8/LKutG4rTOq964DYv+ICHdREotmN3HP4CQ0d0jDHFg+rXR4w=
X-Received: by 2002:a6b:3119:: with SMTP id j25mr8745169ioa.64.1622930913402; Sat, 05 Jun 2021 15:08:33 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR19MB4045CC6F321E5B64B152FF0183229@MN2PR19MB4045.namprd19.prod.outlook.com> <CACL_3VHCQXV+yyg6PYCWxMF3wHOdQEap+vSd=s2-s07sWibKjg@mail.gmail.com> <ABA32E4C-325D-4961-986F-71D5F5E262C0@gmail.com>
In-Reply-To: <ABA32E4C-325D-4961-986F-71D5F5E262C0@gmail.com>
From: "C. M. Heard" <heard@pobox.com>
Date: Sat, 05 Jun 2021 15:08:22 -0700
X-Gmail-Original-Message-ID: <CACL_3VFZo4kNGWsH3Q8K7miG6gyer8232M+5QyNSSL21XoZ4Vg@mail.gmail.com>
Message-ID: <CACL_3VFZo4kNGWsH3Q8K7miG6gyer8232M+5QyNSSL21XoZ4Vg@mail.gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: "Black, David" <David.Black@dell.com>, Martin Duke <martin.h.duke@gmail.com>, TSVWG <tsvwg@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000096a5c705c40c0c37"
X-Pobox-Relay-ID: 91DDB140-C64A-11EB-906D-FD8818BA3BAF-06080547!pb-smtp2.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/cj2_l0a8OuNax0JY45X8pZCCw-I>
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: Sat, 05 Jun 2021 22:08:48 -0000

On Tue, Jun 1, 2021 at 11:18 AM Jonathan Morton <chromatix99@gmail.com>
wrote:

> On Tue, Jun 1, 2021 at 8:35 pm, C. M. Heard <heard@pobox.com> wrote:
>
>> What I don't understand is how this proposal prevents an L4S sender from
>> competing unfairly with classic traffic when traversing a non-participating
>> domain.
>>
>> Doesn't the sender need feedback from the receiver that the label DSCP
>> was received? And the the the receiver is itself capable of providing the
>> type of CE feedback that the L4S send needs?
>>
>
> My understanding of this is that L4S traffic is not supposed to *exist*
> outside of the networks participating in the experiment.  The measures to
> enforce that invariant are:
>
> 1: Don't deploy L4S endpoints outside the participating networks.
>
> 2: Use existing Diffserv management infrastructure at the participating
> networks' border to prevent traffic carrying the Label DSCP from crossing
> the border (or, possibly, to limit their volume to a presumed harmless
> level).
>
> If I've got that wrong, I expect to hear a correction.
>

I've seen no corrections, and it seems that both Martin and David agree
with this assessment, particularly point #2.  *BUT*:

On Sun, Mar 28, 2021 at 5:35 PM Bob Briscoe <in@bobbriscoe.net> wrote:

> Many of the arguments for why a DSCP is not useful e2e also apply when it
> is used as a guard DSCP in a single network. For instance, when an IP
> header with a DSCP is tunnelled in pipe mode, it is not propagated to the
> outer. So it won't be visible, won't be bleached, etc.
>

That was in the "L4S DSCP" thread; see
https://mailarchive.ietf.org/arch/msg/tsvwg/A1HQwlbDSEONIEhU9DXOYreG8HA/. As
a reminder, allow me to also remind folks of a message from Olivier Tilmans
with subject "Prevalence of tunnels in mobile networks" at
https://mailarchive.ietf.org/arch/msg/tsvwg/ij5BqzNtMxKV8VbHE8pUevZjx7k/.
The gist was:

3GPP domains are literally a set of tunnels stitching together multiple NFs
> and nodes/equipments.
>

If the assertions in those messages are substantially correct, there are
good reasons to doubt the efficacy of a Label DSCP even within a
participating L4S domain.

And even if that were not the case, there is the question what would happen
if a Label DSCP did survive, and the traffic so labelled were not filtered
by a participating network at its border. It;s then left to the
non-participating network to do the filtering itself. That is not fair or
reasonable. Participating networks need to protect those who do not choose
to participate.

I think it's clear that what is wanted by the L4S proponents is an
experimental internet-wide deployment, not a set of isolated deployments.
If the WG agrees, it should have the courage of its convictions and declare
that RFC 3168 is obsolete.

No half-measures, please.

Thanks and regards,

Mike Heard