Re: [tsvwg] Some comments on NQB (part 2) - DSCP policy

Greg White <g.white@CableLabs.com> Wed, 11 May 2022 23:39 UTC

Return-Path: <g.white@CableLabs.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 418C3C14F75F for <tsvwg@ietfa.amsl.com>; Wed, 11 May 2022 16:39:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, RCVD_IN_DNSWL_BLOCKED=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=cablelabs.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6PcHf_E-llu for <tsvwg@ietfa.amsl.com>; Wed, 11 May 2022 16:39:03 -0700 (PDT)
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2070c.outbound.protection.outlook.com [IPv6:2a01:111:f400:7eaa::70c]) (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 802B6C1594B2 for <tsvwg@ietf.org>; Wed, 11 May 2022 16:38:47 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RW1zccNk3ic3RpRu8oS/1FLyD2Bew+dCvQim+BXQ3ttT8SIuOdBduL8KxheD0ni72UDOc6zbkI9AQfAJXE9RXs5VLzDVngV+QPdJ9vRWibPj0hPc9FLSRMGBYIT2VwZw+OIRSw0qwH3dQ7NKrLB0zW1PpmWqpZ2f02ij8OOu3PFZl4F8ngzMYNML6ToV/oNU1SCiQ5ZJhtKfq3jhrVroJu0NPr/mZC2nQyT+GPril3GEMLP1WtJjC/o50oHtkmTWNHOFjW2a4L78GMte0oPKDBifMYkTg3nyOg5f6dWFqO8x8Pp9aLJ2q1/7DAvSoNL2CoZN0s/BuOjYWv6IMasQuw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=JgUaQqs1pA1kL8XYp0A0E4olERo9HJlKV6lPVBvmTWY=; b=YjW7plvQ8OGH+gvl74o5rFbHXTP/raQ0J9fRdOlgLVAfXe51+GuVdw6Rj64AAynMu1uxte1ouSh7RKoTN9PUWbeh4aYCPnPz2irQSAqNBHm1+7fS9931CGL3rbQvRSo+NZmadfQmepcsb3AY0ncZoGd44bAfwlElElMoD7v7Oj3t0/vaBWlG/UoRcBuEYRHHTSND5ji7JKBMJC3MVXkCTp6lsuVSRrGzhp8EAJJ6l66pUyGssnAh1AUow5ALsgzhxccwobkVjWQiezRyAC8vDCdDnv5IIuvU4DoQNLLv5aWF6/rffVsr2J2AO3YuMnQpy/qkFXK5sedWevg1XEWMXw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cablelabs.com; dmarc=pass action=none header.from=cablelabs.com; dkim=pass header.d=cablelabs.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cablelabs.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JgUaQqs1pA1kL8XYp0A0E4olERo9HJlKV6lPVBvmTWY=; b=lpcCOxSk0oGgvKhWtMpM7j5LbF7prn3zPqSEP3mOynZK/yl0tQlsIQ9cdcdpf+6U1DvUDfOLSY4aDtQ6zFyUHHpfS77ikLkdI/vwomi9mnOcqEyJ4rZI2JLuiCiafLszNpC/WbFB3rgwuwWfNoIYmK/FvZZtoKDilTSmiiWmlPobeeKsmjdbkARpnMtpshP0jCGA7rgp5zOQgZ79nk+m15ZagaT7QL/Wij3tbRwrwnL6fvVzDZ4x1xdalj7qpGIwRyxilEpPrKVgsD4dwkBqiqkHDJMo4Um0ca1RWLxCaojA/TcreDqN+Ctczd44NrRp0sCHY4oMRLjfwtobQqguyQ==
Received: from SJ0PR06MB7861.namprd06.prod.outlook.com (2603:10b6:a03:38c::19) by BY5PR06MB6643.namprd06.prod.outlook.com (2603:10b6:a03:234::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5250.13; Wed, 11 May 2022 23:38:41 +0000
Received: from SJ0PR06MB7861.namprd06.prod.outlook.com ([fe80::c1a6:9034:98f0:f587]) by SJ0PR06MB7861.namprd06.prod.outlook.com ([fe80::c1a6:9034:98f0:f587%6]) with mapi id 15.20.5227.023; Wed, 11 May 2022 23:38:41 +0000
From: Greg White <g.white@CableLabs.com>
To: "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de>
CC: "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: [tsvwg] Some comments on NQB (part 2) - DSCP policy
Thread-Index: AdhfhMwo9tAhfmFsQDigQ9k2ShzGMwBJAGWAAByXCEAAEXhoAACDPQ1QAHv9HYA=
Date: Wed, 11 May 2022 23:38:41 +0000
Message-ID: <6778646C-383E-44EE-9840-18ECB69263DE@cablelabs.com>
References: <FRYSPRMB0001B90EB3C7E841618754079CC39@FRYSPRMB0001.DEUP281.PROD.OUTLOOK.COM> <BE74F267-CE34-450F-B66C-77C83A4856C0@cablelabs.com> <FRYSPRMB00011A7D6F642A7D4D0BEE4A9CC59@FRYSPRMB0001.DEUP281.PROD.OUTLOOK.COM> <DD59BEB2-622D-4BA9-842A-528F8DF7DF28@cablelabs.com> <FRYSPRMB000106B443E2CA75CEAD3AD59CC69@FRYSPRMB0001.DEUP281.PROD.OUTLOOK.COM>
In-Reply-To: <FRYSPRMB000106B443E2CA75CEAD3AD59CC69@FRYSPRMB0001.DEUP281.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.44.20121301
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=CableLabs.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 462c19c2-7f71-425c-733f-08da33a7618a
x-ms-traffictypediagnostic: BY5PR06MB6643:EE_
x-microsoft-antispam-prvs: <BY5PR06MB6643426D88C1E862EDEAFA5EEEC89@BY5PR06MB6643.namprd06.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: b9ynUpMWiuVMBYyBLqP3gSobStVMM9P5U1EWgeqo18fgLM3a49c04D3p1IEjQguozTB++e+sq/zuHLz/yPAd8AT6bmgraX4cgJWEnby8dfjvqxrN0LvxbyQt+/IvSOKM4YlubhlZT/tk/ZQl0m5WWrmBUK1SOvfTD/LTQDYRxnKImKLhMo1zz3vUbryMrqZQ37FU1dnijp2BJdsa9/aI58pGy5LHWs5L54Ec3h7k7yvDAftucbDnnWhyNFfZV00q7p/qAPcEb/DuegwHz9NQ/CKh8yJ27nqbp0TJ/hc1ZcnDYkB5AV8enu/DgdOqmm/evvi1SALILdZdOiK+C0n6ov+ysq79VNUa/ghfxYVw+acHiqMQO9wdYMMgCxXeT0PFK0TFZsBuvCR8l+E/+eNOxC2g26GGLalOTZlAgC4F15c5s22+8EfSVqXAHQe4BIv1nUhBkVKpioZ2cNxsOGM9fLaZHWqHkHTFxcAN/x83wUzPYOeKzrCvxyq2DqBqVpFhqp5m+iRFtHNZreyjpMRUJ/l807bShxhY3i67Z3qLL4n0c/QYhbWZLXhOf5ifMzcjZ9jdBHuY1e1CTmmVqLKvDZNgqEdPPLw7YeQO6vz1PpCWU1Sm1qXOpqLNZodumwLNIIMOunPVHtiNtNdZAGLjOUOXjdzR2vObgTG6er97tHXVSs5/7KIAX99acgdh5b/RzQVpiv3CQYjWMKO4H/lvR/O3IPidpIdTsZ0Um6Ed3RvQHRBoMEuclxKkNIVryXXjE/jI3wNjdgyL105KmgS4ooNQ144BNZHfW/TqtNwAntn/UCCRN6nSkrD+WLqc/zz0lFHitCY1RRiBcbKDaK3EZGS8fjp4NIh3XqVkngk8Hx0=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR06MB7861.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(122000001)(6916009)(5660300002)(6506007)(26005)(6512007)(83380400001)(186003)(2906002)(8936002)(53546011)(316002)(30864003)(38100700002)(38070700005)(71200400001)(508600001)(64756008)(66946007)(966005)(33656002)(76116006)(66446008)(66476007)(66556008)(6486002)(4326008)(8676002)(86362001)(36756003)(2616005)(66574015)(91956017)(45980500001)(85282002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: UHzaTjEl2Xf1XcySqfDoI2zB1HDvawUEj2Oxt6c2Rfy/TBKjEidnYlBfp/3XFh0WnNEAavUI4K8/+wZM8CiQp1R3awG/ZPOF8ZQUxeJE9abA+kNFi7FEs86i/+5XO/lMFkZNNACaQCBjRloPS+hyOCH/kfXDL/Q39b9i08q31zAplpuOqiPanwQp6vV0pC+hfpMzYiN57uWYmkAFjeWIH4mlBy4p/GQWL/tYEWopo96UIm99+qulIlCSSXMq6k4li4pb1UaNpcqJbD51QxPsoVP8HCQXItHlca6oJ4VgZ9tI9/xOFaTUOuGnY08AvyDzH1HwkJ4L38+jZnRXBzRkLqlGiCMcrV2qHo3JiHZPKE5q2lPZwE1TLnFNmQga4D9dUtCJ8ZpfN7DGXyar3mO6tIUCpYKDtKi9KnqyL1gd+vNu98SkS58W1QCnAR3XdnWJIFkO/7p/DQ+WeTgmzJE1Koq0eU930irgOtY4PRx01N2KSVVl0s1kKUIVNzyuMpPU0i3UA0mqc7+RfrE5o5FyymiNQG/wJck3bjby6bV1S1dtTAFNOjNp14L3G0LGux+U5SjyH7soKP9zritsvhSs/4AO8rA1+CiUd8/G9AJXwcLXBJ3svRKy1zMmXr51YC9lOqcVfZ4aV76Uacv3JH61zIRjhTrZANk94OvJAn6FhcyJ8UfQFS5HGp/8WmN9mFswRqPopsE/qbzh6ABcuIAadb6hGbaJY9bMqLlFxHZYKB0UkjZpUIIfvxgkC3DM/X2S5+c2krDP2rUG3XouNcxxvM9ke9lhS6KA47Mt/zzKmCG4BCxHp2uWEObOjAS9//1SMm0TaQUPfdh4nWYqdXF/Ibu8AIP/1/NiDyxZSCZCOo0bRpPYW1d2S6vC8g3wlK/Bwslxg5i0gEn3qoF3i23I2DkNOGmHeYItC7fmoWJEZivvGm+9BbYR9mBa/FgXLbNRVZy8ZzuPo+HohvwYf4EG5vfBsokMVobJXmNNKcMYLqw/2RN2BcUcvyyRFatfPfKfgF4crsESmcmw0kj689MP5kpYhTuNiPgEwo4hqQsNako/bhRbyQIGuPGIzpWm5rL5BarBflBSrSV2O6FPLq92LMrddn3SBAWODNx6pJvmhLVVhKVu5f1PcUh05vxOZQU3RThGRwzyplHfQfkSBHw2cEafe5+yDTQvigavWA7cF6Ac3qAXflAA2EBzHyRO7SiDJldHxHPTNNYWJ+jmiAQ16Uu1PSUZt9iRUFa4S1/rX0QHz+b5mscG7MEoRNBBdxK/kkChY/PsrFXHEfqKRPff3ZRpaPUVHwdwJlvSd6MFaFv2VjpsYFBCbQZfReE0n5y/RSSfv0k0LjClyv0ImOT0ANP+SuDTFZFyVH+nWeKrf2gDIr9zO4Ij3+AjTg3OVSq6A/Nxthb9w99vzC1SUw3P8HWr2/nUc/MHZ0d7O91Z07mEya2h/PXuapEYSRWN/HZw2zdD4OZXvkvLgIZU3JJ0eLTZXTYyf592R+Zrj/XLdnY4qaBcmt0PmA0kPeFdLQwFUeiTRbHSE7j2ONFHvHQHYLiiz60KkdaQa1uJkEbV21E7H2zHuD6jKskJeC9avUB5AR7aWSbvzfsxdRcGEuzYB/1vnNuNaGKhQhCPQYi6m0Jsv7lvLWU3YAw6oxvqkR48uY71VnUY8uVV6aN2+emdurG9TzuLyAZNb/hqK3xOMH72viq5vlidd5Dd1Yg6xZOCL03O0LusSroJSxQ6KVeBsK7Q94xkiUEO4yKEB9TfaTk=
Content-Type: text/plain; charset="utf-8"
Content-ID: <CAE83A605E08A946AF1241811513EA14@namprd06.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: cablelabs.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR06MB7861.namprd06.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 462c19c2-7f71-425c-733f-08da33a7618a
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2022 23:38:41.5052 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: ce4fbcd1-1d81-4af0-ad0b-2998c441e160
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: MjPBbAEekKZCv9uw1Po8o73uuUd5g8YLOjWHVJdbpaznsdoci4PdiFk2Hwnfi9pRBngUcrDCwYhu5lR9Z2S50Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR06MB6643
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/F4FjS5OZZoZc-z074T-ipfyk0lI>
Subject: Re: [tsvwg] Some comments on NQB (part 2) - DSCP policy
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.34
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: Wed, 11 May 2022 23:39:07 -0000

Hi Ruediger,

Ok, apologies for misunderstanding your earlier message. 

My interpretation of where we stand on this is:

I'd suggested text on April 4, where it is recommended to negotiate the use of 45 at interconnection, but where negotiation isn't possible, use 5.
RG agreed with that text.
GF wasn't super happy with it and would prefer the value 45 when negotiation isn't possible, but hasn't responded to RG and GW 
JL agreed with GF, but seems to be more concerned about direct peering as opposed to transit.

Is that summary accurate?  Any suggestions on how we reach rough consensus on this point?


Below I'll try to answer your technical questions. If I've missed some, misunderstood them, or this is unclear, please let me know.

For network operators that use DOCSIS access network equipment, the option definitely exists to classify upstream traffic based on L2,L3,L4 criteria (including e.g. DSCP 45) into traffic aggregates and then to re-mark such a traffic aggregate at the access network to the value 5.  Similarly downstream traffic can be classified (e.g. using DSCP 5) and then re-marked to 45 at the access network.   In the case of LLD, the Queue Protection function can also serve as a policy enforcement function of sorts, since traffic redirected to the Classic queue would get the DSCP re-marking appropriate for that queue (e.g. DSCP 0).  In cases where the operator provides the gateway device (this isn't universal, there is also no lock-in in the US and Canada), they could also implement more sophisticated policy enforcement and marking if they choose. Whether network operators choose to take this approach is entirely up to them.  They could choose to use a different, local-use, code point (or 45) in their core network, and re-mark at interconnection.  They could negotiate with their interconnection partner to use 45 end-to-end if they choose. This is entirely up to them, and whatever we put in an IETF draft/RFC is (in my view) simply a suggestion. I don't think that network operators are unwilling to perform re-marking, but if it isn't needed then I assume (and one has stated) they'd rather not. If ISP X and Application Provider Y directly interconnect, they can choose whichever DSCP they want, and if it is convenient to use 45, then why not?  

You'd asked whether cable ISPs support DiffServ, and I am not exactly sure how to answer that question, because I don't know what you mean by it.  If you are asking, do cable ISPs implement the IETF defined DiffServ PHBs (CSx, AFxx, EF, VA, LE) and use the recommended IANA DSCPs, I think the answer to that is generally no. If you are asking, do cable ISPs use DSCP within their network for differentiated treatment of traffic, I think the answer is generally yes.  If you are asking, do cable ISPs differentiate inbound traffic at interconnections based on DSCP (with or without an SLA), I think the answer is that most likely some do.  I hope that helps somewhat.  If not, maybe you can try to clarify what specifically you are asking, but I can't guarantee to know the answer, and I am almost certain that the answer will vary depending on which ISP it is. 

-Greg







On 5/9/22, 1:52 AM, "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de> wrote:

    Hi Greg,

    I've never asked for decDSCP 5 end-to-end. Please stop this way of arguing. To repeat: 
    - IF there's no negotiated SLA at interconnection
    - AND standard conforming NQB traffic is sent to DT
    - THEN mark by decDSCP 5.

    That's it. If DT intends to support NQB for traffic received that way, the DSCP useful to give priority to NQB over Best Effort traffic at WiFi APs, decDSCP 45, will be set by the Access-Policy Point (valid for fixed and mobile networks). 

    I'd think IETF best should implement standards, which follow operational practice of carriers:
    - simple and generic (to operate and configure)
    - allow for simple and generic aggregation at interconnection gateways and within backbones

    Please answer the technical questions I've been asking you. I don't know any detail about the DiffServ related architecture of and whether DiffServ is supported by the backbones of these operators you claim to talk for. Greg, you continue to go at length arguing about DT's DiffServ deployment, never providing any reference for your beliefs. Please stop that (or start to provide references supporting your claims).

    I'd be happy to technically understand why assigning decDSCP 45 and recommendation for use at interconnection gateways, especially those without an SLA,  should be done by IETF. So far, I just heard that some operators, who are not known, may like that. Well, you've heard that others don't (at least one is known). 

    I don't share your interpretation RFCs 2474 & 2475 and RFC2597, as you so far failed to support your argumentation by any reference.

    Regards, Ruediger




    -----Ursprüngliche Nachricht-----
    Von: Greg White <g.white@CableLabs.com> 
    Gesendet: Freitag, 6. Mai 2022 23:51
    An: Geib, Rüdiger <Ruediger.Geib@telekom.de>
    Cc: tsvwg@ietf.org
    Betreff: Re: [tsvwg] Some comments on NQB (part 2) - DSCP policy

    Hi Ruediger,

    I'm afraid you may have taken my statements too literally. You had made an argument that I interpreted as "DT has an established interpretation of DSCPs, and so the DSCP assigned for NQB needs to align with that, and thus be 5 end-to-end".  What I was trying to point out is that DT isn't the only entity with an established DSCP practice (in fact there are some others that I argue may be more important to align with), and that some have questioned whether DT's practice is aligned with the IETF's intention for DiffServ in the first place*.  I was not trying to ask you to defend your DSCP implementation, but rather was simply pointing out that others may think that their approach is the "correct" way too, or they may think the DT model isn't necessarily the one that all IETF standards need to be based on.  For these reasons, I don't think that assigning the value 5 end-to-end is the solution. 

    To be clear, I'm not saying that your implementation is incorrect or in violation of the letter of the RFCs.  I'm just saying I don't believe that it provides a compelling argument against assigning the value 45 for use at the edge (at least).

    Like I said yesterday, no one is arguing from a position of architectural purity here.  In my view there are a lot of conflicting established practices in place, none of which foresaw the definition of NQB, so I think we need to find a set of DSCP recommendations that have the greatest chance of success with the least effort and confusion.  I think we are close to achieving that with the recommendations to use two DSCPs (45 & 5) and the language that we've discussed on this thread.  I'd rather that we continue down that path.

    Not that anyone has actually suggested this yet, but if assigning two DSCPs is somehow not possible, then I would argue that we assign 45, since any DS domain in the core can decide to use different DSCPs and either A) re-mark inbound traffic from the IANA assigned NQB DSCP to whichever local-use DSCP (e.g. 5) that they wish, or B) inform its peers that they need to mark NQB traffic in a particular way if they wish that traffic to receive NQB treatment. Neither of these options are available at the edge.

    To your specific questions, I'm not sure how to answer them. If it is important for resolving this thread then I'm willing to try, but it isn't clear to me what you were asking.

    * For me personally, it has always been my understanding that the DiffServ architecture was intended that the 64 DSCPs are independent values without a defined structure, and that there was no special meaning *in general* for the upper 3 bits separate from the lower 3 bits.  Interoperation with IP Precedence was defined only for the case where the lower 3 bits are 000, and only then do the upper 3 bits indicate something akin to numerical priority. If the lower 3 bits are not 000, then the DSCP is just an index in the number space, and (other than the Pool 1, 2, 3 concept for local use vs standards) there is no structure to that number space.    The AF PHB Group created a structure within its set of 12 DSCPs, where the upper 3 bits convey the "AF class" (which doesn't equate to priority or precedence at all) and the next 2 bits convey the "AF drop precedence" (which is more akin to IP precedence, but here the order is inverted with lower values being higher "priority"), but that only applies to the DSCPs within that set of 12.  DT's practice of using IP Precedence - ignoring the lower 3 bits - (what you refer to as classifying based on DSCP ranges) doesn't align with what I thought was the intention of RFCs 2474 & 2475 (and it sounds like it might not comply with RFC2597), but to your point, I don't see any explicit requirement that forbids it.  Furthermore, the DiffServ specs all seem to allow quite a bit of flexibility (particularly on DSCP values - they are only recommendations after all).

    - Greg 






    On 5/6/22, 2:43 AM, "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de> wrote:

        Greg,

        I can't tell what the exact QoS deployments of operators competing in Germany are, but I know that at least the larger operators negotiate QoS for all types of interconnection. Some DiffServ related home gateway interface specifications are public, as there is no home gateway operator lock in in Germany (meaning DSCP marking policies helpful for e.g. Wifi gear could be specified there too, and home gateway vendors can support it - I agree, that this "no operator home gateway lock in" is likely specific for Germany an few other countries).

        I know that Bob worked on BT's DiffServ QoS a long time ago, when he was working with BT. I'd expect Orange to run some QoS differentiation too, but don't know details (M. Boucadair is active on BGP related QoS signaling in IETF, one may ask him). I also don't know details about US and Asian deployments, or whether these exist at all. I'd recommend not to ignore these deployments, if you'd like to increase benefit for consumers (noting that no one knows all these daggering QoS deployments). 

        I'd think the best way of reaching the widest support is looking for consent and part of that is respecting existing operational environments to largest extent possible.

        Your message doesn't state that operators you've been talking with support DiffServ. Could you clarify that? They don't seem to be able or willing to re-mark DSCPs at access policy points (which are the QoS policy management points in fixed and mobile networks). You didn't answer my question related to broadband cable network Access Policy points yet, I'd appreciate you doing that.
        To the extent I can tell, no IP packet viable for some differentiated service passes a mobile edge or fixed network access policy point without being Multi-Field classified. I don't think our vendors sold us equipment having QoS features just and only built for DT.

        You write: "And, we've heard the view that IP precedence is deprecated and is not what standards should be written for." - Could you be more precise, so that I understand, what you mean by that? Dou you want to say that classification based on DSCP ranges is not conforming to DiffServ standards? If your answer is yes, please point to a suitable reference. 

        I'm not sure, whether https://datatracker.ietf.org/doc/html/rfc8837 is supported across carrier backbones. If you or anyone else can shed some light on that, I'd appreciate. It's another example for a recently specified DSCP scheme not requiring any particular operator support apart from transparent transport of DSCPs.

        Regards,

        Ruediger

        -----Ursprüngliche Nachricht-----
        Von: Greg White <g.white@CableLabs.com> 
        Gesendet: Freitag, 6. Mai 2022 01:52
        An: Geib, Rüdiger <Ruediger.Geib@telekom.de>; gorry@erg.abdn.ac.uk
        Cc: tsvwg@ietf.org
        Betreff: Re: [tsvwg] Some comments on NQB (part 2) - DSCP policy

        See [GW].

        On 5/4/22, 1:42 AM, "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de> wrote:

            Greg, Gorry

            I favour an approach on the recommended marking respecting that DiffServ is operational in some networks for more than a decade.

            I think, an approach to maintain DSCP 45 on an end-to-end basis is likely to fail without SLAs at interconnection. That's why I oppose to that. And as I said, the motivation to have this DSCP to support NQB on outdated WiFi boxes to me is not what standards should be written for. 

        [GW] But, we've heard the opposite from other network operators, who feel that 45 end-to-end is simplest.  And, we've heard the view that IP precedence is deprecated and is not what standards should be written for.  Also, similar to what I indicated in my response to David, I don't know what you mean by "outdated WiFi boxes".  We're talking about nearly every WiFi device on the planet and nearly all of the ones that are available for purchase today.  That's a deployed base that is probably two orders of magnitude larger than the DT network (and growing).  If we had to pick one or the other, I would go with interoperation with Wi-Fi rather than interoperation with DT.   

        [GW] I think we all need to agree that there is a lot of history with different established practices in place for DSCP usage, and we need to be willing to be flexible. No one is arguing from a position of architectural purity here (well, perhaps Gorry is to some degree), so I think it is a matter of coming up with recommendations that give us the best chance of having the widest support with the least effort and confusion.   







            Which scenarios do apply?
            a) Access provider supports NQB at Access Gateway: 
                a1) fixed & mobile networks: the Access Gateway is likely a QoS policy point, (Multi-Field) classification and re-marking are operational.
                a2) I'm not sure about broadband network Access Gateway policy functions.. could these support NQB 
                       without being QoS policy point? If yes, is that prevalent?     -I try to be careful, no blaming intended-
            b) Access provider supports QoS at Access Gateway, but doesn't want to support NQB: then the Gateway is likely a policy point and re-marking is to be expected (in a negative sense could well be DSCP 000 000).
            c) Access provider doesn't support QoS at Access Gateway, but wants at least outdated WiFi gear to benefit from NQB. Then DSCP 45 may make sense.
            d) Access provider really doesn't care about QoS at any location. Then DSCP 45 may make sense.

            In cases b), c) and d), the Access Gateway is forwarding NQB like default (and NQB inherits default performance). Than all the effort is at best only about the WiFi AP. To me that's not justifying an end-to-end marking scheme likely conflicting with providers operating a1). As Greg has mentioned, the home network gateway may deal with the issue (and that should become part of the draft).

            Regards, Ruediger

            <snip>