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

Greg White <g.white@CableLabs.com> Fri, 06 May 2022 21:50 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 948F4C15E408 for <tsvwg@ietfa.amsl.com>; Fri, 6 May 2022 14:50:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 aY5HGlC1S60h for <tsvwg@ietfa.amsl.com>; Fri, 6 May 2022 14:50:50 -0700 (PDT)
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on20711.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5b::711]) (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 C2CD4C1595E2 for <tsvwg@ietf.org>; Fri, 6 May 2022 14:50:50 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CZNe+30RAIE8ZNhsCyZCpuX+pnw0xMBrKs/J+w6tBwhXPt+PnjJjgkMDlwvd/ohRnNRTUePOR/1/8BtRL2Q4zZjzs2Ym+bemsnAhG3PR4dufA0qySlulu4kFtVkT+3xyFaYAFP5ALoDAemvKsUQHAxyeh0emwML1nqBXVZef3PHFxUAjeNEePRVX7QvLqsMnWq5/NM3va6YCAsNUDWutZO1jN0VnPG6s5un8FYLAQ2+pq2lHTRyLv8IoY4bbHyrwCLwc34jD/v0nB9n1+8iczl8x6/R34VeHb1afPp43wgRx24Zt3H+N3T8+FQRYehVLIgTpJvZT4bCxRUY7qCzyAg==
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=Fcrky7lFK0bi5FZRAeIQBHpw+4jqyBhC1geDCGSVtNY=; b=NuQmjjxaxG4vJgoJNCMCP5ROWVptQtSNgTDeuz9+xtpdNT2xiT0rycPibjCq8q0TXnBJ6nqGpnv4b/Saiee/xHMEW2TKCVpl4ZB7tU3CHNxoeOzG7Os7mJiI33T5yMeG+zFYQIXISdPNoC/5l4W3bFFsSqsgbRPIEImSOpqUwyAX0YG+1H6P8wtHYWTo/2DYulmp4ewWtwSjB0KVAk3i52fn75nNilJJSkjvI/dHYOphXg1xcleHXGAN/CQxVl4PfqP7aqH2Edj370bCLDyuZLxStGtyol7NO3A5zLi4BvFfbaCMYt/B9LLfVRTmTnvQSgUqoNVYq1jgYoXlRGMpHw==
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=Fcrky7lFK0bi5FZRAeIQBHpw+4jqyBhC1geDCGSVtNY=; b=TK28AjP9BT9IwL5tB0nlXu47GogJFs4+22k0GuedJC44mFsUGgogUlzRh10W374xCYblXGJ6jtxuBYip7KzXtlW/dhqTukte1X1Zxmh5ZJCWX5IrhLzosjwaiIkLGZGRXRSgY8VnUnj+RK/SHqj6i9XDmYm9qrO1EDt7dd+J5xLqruXFMydTBAFxMIl8bq+ju6l3iaIZ/sCLHUQRbgYa0Vp2nvLN4fkHzqg4E4WKwMSz+s/fFL/mcTDZxaVcS6GG0OP8Q/prcTWtDowgDbWhP965+YpzIc3kaMJDBmKp99ODF8rNKipt2HRh6RDdoWLAchcCWB3T+rLUcIeBK2wj4w==
Received: from SJ0PR06MB7861.namprd06.prod.outlook.com (2603:10b6:a03:38c::19) by SN6PR06MB4861.namprd06.prod.outlook.com (2603:10b6:805:c1::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5206.25; Fri, 6 May 2022 21:50:44 +0000
Received: from SJ0PR06MB7861.namprd06.prod.outlook.com ([fe80::6d2b:ef23:97c8:bf83]) by SJ0PR06MB7861.namprd06.prod.outlook.com ([fe80::6d2b:ef23:97c8:bf83%3]) with mapi id 15.20.5206.013; Fri, 6 May 2022 21:50:44 +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: AdhfhMwo9tAhfmFsQDigQ9k2ShzGMwBJAGWAAByXCEAAEXhoAA==
Date: Fri, 06 May 2022 21:50:44 +0000
Message-ID: <DD59BEB2-622D-4BA9-842A-528F8DF7DF28@cablelabs.com>
References: <FRYSPRMB0001B90EB3C7E841618754079CC39@FRYSPRMB0001.DEUP281.PROD.OUTLOOK.COM> <BE74F267-CE34-450F-B66C-77C83A4856C0@cablelabs.com> <FRYSPRMB00011A7D6F642A7D4D0BEE4A9CC59@FRYSPRMB0001.DEUP281.PROD.OUTLOOK.COM>
In-Reply-To: <FRYSPRMB00011A7D6F642A7D4D0BEE4A9CC59@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: 44b03cef-78e6-471f-dd4d-08da2faa78fc
x-ms-traffictypediagnostic: SN6PR06MB4861:EE_
x-microsoft-antispam-prvs: <SN6PR06MB4861AAAB0E1232E0CC991930EEC59@SN6PR06MB4861.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: SSAmibVpMLTsGrbvmjvjLxRxeker8uid+A0gcBWBGo6X+2LxmMU3/QoTgTQ07GnI1i6o0skAJaFzDP3j9nZp1jz07EKwDAEV7m9j3PW0+qs4vheOidDcnf4bEc4LtbZo8Ii4hMdi4q/g6Ank3yKqJaRBzwTZKA43v/A5+MjPvsqEkmq/GQdn/RrSfL6CZpK949SPklLclEc5e3SRWRVmTI5loAEWWFgwfGy3rB0n1Vz3KS/EEnQQj1U8VVOHAJLPrVzIxoEchqSIpz5VVLtO69v92bVU8IiTJ/i40O2vIwR4pxdfW0y6lUqh1zHLRiNWAph710k8OzSWkGUZcdd2LIT+8J8+wYGKs65mayCxtznof+cMkTYu+PhUU0o4heIFamTGU8n9+81MTKPhYZ9/7O5/nowRZRbjjyToF4fMpUmQdz8h+NBFggl3Zwgrlg4lbbO/3QTaj+oHkiSWV7PS6ozm7iJol2JMZ5nsULsZw/aaqgIGcZ/9X4ympQk2aDF6lVxNzsEQ7KzpR4YOUjMhlWKdHhT0/7ZT8NzTED45oflzc8a81/ZxzqiZ1XhJAGXONEh2rJ2uzmgdHmxAu+znMZa+/SxF/Yp1fQAbpqlhWi7G+KAEIJO+h/IrhD6eOboc7FRu5GIfnitKH1sPtQzx09YgkSu41u+NwpA3keG4bLWrKFwrobb7IeAI+VvaxpHqfD+KuBHsTRovh3+yXCD/Z77LWz7eQWDaUarz3CvCBhGSKzOKgWIrVci01G516B0SVXCvTI3frdn1nJjAqxI2cpEHP8uDBKHu+HCM/i1h6CPIAzcTyefycVc80cixQ80u97LY2scseKXBNJ0bXj3R7ZuuB1539GblYiq93kTA9G0=
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)(508600001)(5660300002)(83380400001)(6486002)(66446008)(966005)(36756003)(66476007)(71200400001)(64756008)(8936002)(316002)(6916009)(66556008)(8676002)(4326008)(66946007)(91956017)(76116006)(26005)(6512007)(33656002)(2616005)(66574015)(186003)(53546011)(6506007)(38070700005)(38100700002)(86362001)(122000001)(2906002)(45980500001)(85282002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 890q8E/Yo+82A9JO+DulmGHz0+7tcDB4cNCO5V3P+6OEm67sPl6KXJ7nn6LrxVvD7d/yIM2gZqjSONXKguRPd7Tt26k9x8tW/l9QoPuP+wAnLD2OTO/WI5sY52pGRYlcEZBuTg+6lP2ROv8bBVg1H0sTZrMnqqQt2LpPO9rAvXWZ5s/RyDwMA6I8tAAkXY/kIKLKswJHPGwB7reatrN4u3pCHRu4TwtqYnGHVFUuSg3+zNonmylR4F9bOEWIgWQBHJxN644EJPhbO903re5IKN5/6x10S0CqBx37UyinQESs/ajJgFrkCLpCV4OMgkUN+8kYQubNc4l7+PZ+gM5U46/0c76/ni85giwxvlo/qIszi6BVgDPq2qi5Pb4PYfb4PKW6qy4zeERMyj09U8zxb1DUWayyA1JP/o/TRuPQVr9M2tyaF57J/ltPpgWbKZ797uhd9yIK8gfFyWXtpl+9j+o7xGxK/jCBvXVQxXXMEJiE2mNnHNZWSQPA8FRNOvKvNBjHyOyZ06BpnXX/jPiqc7nCrbm3+Hv2xopPPqP5yGR/oi3o0DHR59hp8mFPxGK/UoPtv2OhgNcpkVuGnfANFZz/m8+hv/CcW6Ad0HubYsR/x1kkaXIfMjhVgrHRJWt2gmJcsXEKjY4e2RqZCXXrd/UF2yvwXB4roOBmAMQ4YxlrkNfObiDoZkZ6d0Mj6oUmUJV5PBEVRS7wxgniNwEs4+JHB/jFAvjO5EW2x/kney9woVThFWihjo2UuQsKDJ5rWtxoALaX3PHJZzUUlOJZkPk4Hc1t/6j2mQLZrNRPJ3ePqdLjTwymWbKlF+g8T82wPZIW/DY4xMXnUonR+qidcfjmVuEU7hR6F3dtmE1/nJcHJAe3vrG0Kck953JHMkT3HkcpwPbWoaHy0knPb0gXdUUHKA+JJEvemKa2xq1WbHQDbccohjWt19o9pf7p2D1VlMPBgakUof8WtQavOma5zJpfpXFPkp/+hWd9TwAQcfY9SZnro0sQqAl2vWnyvT/9NbrzdTxhixKAQhfwETJttxArRIgf+ZGOK5g5sfpUdh4Vcz3cMrMsqV5mPunQiGHO5udNbGeQEnAbzDTezRG6pEoWcf/xiaa5Lw1nz7C2T0BEEpx4riGVC1QCF5jTBFN0+eFrWVfOfYTwhyMUtxjT9UwPRsrPSJI0xEposFBkC6L0VfMWS8pea0+SUdqiY9gV6CPXRZrvYS3iyP1Z7s11pyoCD/OxqQdlXgIF/YicWnC+gkejT7p1E4OO+Tea/tW/ti3NrW+hdTvVSv3GVVwDtFeKaGGtUXVHrRLvFvBYwsv7EW+9ZIauLWeRkmEF1UePwFmxnGza766C1jWAQgvyMBrQsYpTzpNMeVa/5sv7YezMbtPROok7gWP5Davibw5z0js3lOBzKTBp77GCXvGOgmeFiRK6wDa6O1r2PdH0O9UFuS0G6Bd/gsBGY5Qd+hYUrsEvV08Z+aJc5qxtkhyJ21LHFDlUvMaUaSPz8NX+7RZYaE9KiWa8y3PgkQd1bv8bhTdoF6SiVX2Fh1CcvjnbIhpY0m4opiFEp8HFENg6z6tnlakP4RpMs2perEg9/Lk/kFgfnvREqjKaNj3bEGRUuzQ3CoM3Hja/RuPUoCP/niOSvr/Hz02ucZVZ2BATrFy5vZILtXV+XRkysCFe38a3FpKD0zVnlBzu/7R8VduOWTqqjm7/vgRW0eWJxTOSSqZHEeiv+EEmzqGTH7oBVk1r1eHbCuxAaphc2cf4oO8fS/Y=
Content-Type: text/plain; charset="utf-8"
Content-ID: <4A35D667046CF74BA75365D4A985EA51@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: 44b03cef-78e6-471f-dd4d-08da2faa78fc
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2022 21:50:44.6490 (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: jh9eySQzuoR3wGRMvsMsrOAT6i2ZLoBecmCtKRGTrKduLM/vvzJU0gXRbcMplHzY/c5dS9ufJAjy+WvN2/9H1g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR06MB4861
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/z_99zBR-ZOo-5rIi9GeL4muoj0U>
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: Fri, 06 May 2022 21:50:54 -0000

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>