Re: [tsvwg] NQB - which DSCP to recommend?

Markku Kojo <kojo@cs.helsinki.fi> Mon, 18 November 2019 18:05 UTC

Return-Path: <kojo@cs.helsinki.fi>
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 D207B12099E for <tsvwg@ietfa.amsl.com>; Mon, 18 Nov 2019 10:05:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi
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 CAw87U04FVvd for <tsvwg@ietfa.amsl.com>; Mon, 18 Nov 2019 10:05:11 -0800 (PST)
Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F0D2120987 for <tsvwg@ietf.org>; Mon, 18 Nov 2019 10:05:10 -0800 (PST)
X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Mon, 18 Nov 2019 20:05:00 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; s=dkim20130528; bh=vNCOpIt9ptiYOns9f Gc18ohRsbHC5UQxKZ4benxlrN8=; b=IMj5kgfdNQsYFoEO44AQ64BGUL5fjY2Ko ahZk6h8643PR6hRJ82DG/bD4AOI7GDCpLOYEFLOnirHyeO7lEsgX5iGN90v0g+wD wBWIe/AAG5wvrWJvZsu/QTYKBwWs4VYe6lSPfkgv7E/XIOOfAq5Z0ZdC/HrHy3ol IO3HyQVAWY=
Received: from hp8x-60 ([101.100.166.3]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Mon, 18 Nov 2019 20:04:57 +0200 id 00000000005A0040.000000005DD2DD4A.00007918
Date: Mon, 18 Nov 2019 20:04:54 +0200
From: Markku Kojo <kojo@cs.helsinki.fi>
To: Greg White <g.white@cablelabs.com>
cc: "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de>, "moeller0@gmx.de" <moeller0@gmx.de>, "David.Black@dell.com" <David.Black@dell.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
In-Reply-To: <A9E69EC8-1F4C-4A75-A0AF-7E51545703F9@cablelabs.com>
Message-ID: <alpine.DEB.2.21.1911181944320.15545@hp8x-60.cs.helsinki.fi>
References: <MN2PR19MB404507EBF1C41E72A7930F0F83700@MN2PR19MB4045.namprd19.prod.outlook.com> <F1E4C0CC-EBA1-48B4-AA57-01D179521AEF@gmx.de> <LEXPR01MB118358214565EA8E73B929539C700@LEXPR01MB1183.DEUPRD01.PROD.OUTLOOK.DE> <A9E69EC8-1F4C-4A75-A0AF-7E51545703F9@cablelabs.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=_script-31032-1574100300-0001-2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/3mXVTIrz2STFa4tazmKcs9Q_nbE>
Subject: Re: [tsvwg] NQB - which DSCP to recommend?
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: Mon, 18 Nov 2019 18:05:14 -0000

Hi Greg,

I'm not commenting about which DSCP to select but would like to understand 
a somewhat related issue. I well understand that the NQB DSCP is 
intended for non-congestion-controlled traffic. However, what is the 
intended treatment if a NQB packet also has ECT(0) or ECT(1) set for some 
reason. The draft is quite clear what happens if the traffic turns out 
being QB, but how about if it does not? Does it happily get the same AQM 
treatment as NQB traffic with not-ECT set but also with the same ECN 
marking behavior as BE traffic with ECT(1) set?

Thanks,

/Markku

On Sat, 16 Nov 2019, Greg White wrote:

> TSVWG-ers,
>
> We are proposing this PHB and a standardized DSCP that maps to AC_VI because we believe that it will provide a real benefit to residential broadband end-users worldwide (and our experimental usage to date has shown this to be true).   I believe the risk of unsuspecting users suffering as a result is entirely overblown.  I think the only thing that we agree on in that regard is that if the WiFi link is the bottleneck and if massive amounts of NQB marked traffic are delivered to the home network, it is possible to impact Default traffic.  But to have this occur in practice assumes that ISPs don't care about their customers, and are perfectly happy creating situations that result in trouble calls and/or truck rolls.  No ISP that I am aware of is interested in making their customers angry and adding to their operations costs.
>
> Regardless of which DSCP the IETF selects, an ISP uninterested in providing the benefits of NQB to their customers (or one that is oblivious to NQB) can simply leave existing bleaching in place.
>
> If Sebastian's proposal is adopted, let's examine how this might play out.
>
> An ISP interested in providing the benefits of NQB to their customers would presumably want to map 0x06 to AC_VI or AC_VO, so that the benefits are not lost when the traffic crosses a WiFi link. They could do this in ISP-provided gateways (either implementing a DSCP remapping, or using QOS_MAP), the upshot being that users of non-ISP-provided gateways fail to get the benefit of NQB.  Yes, they would be protected from the remote possibility of harm, but at a cost.   Another possible outcome is that an ISP remaps all NQB traffic to (e.g.) 0x2A in their core network, and this 0x06 value is only used across interconnects.  Since work would be needed on PE routers to turn off ingress bleaching of the NQB codepoint anyway, that seems like it might be the easiest place to map it to 0x2A.  Another possible outcome is that NQB applications ignore the IETF DSCP recommendation, and end up using a de facto DSCP in its place (possibly 0x2A), one that gets the benefit of segregated queuing provided by AC_VI (or AC_VO) across a broader user base, without creating remapping requirements for ISPs.  This would almost certainly be the case for uplink NQB traffic.
>
> The latter two possibilities would result in NQB traffic arriving in all of the ISP's customers' home WiFi networks such that it maps to AC_VI or AC_VO anyway.  In cable access equipment, per-user bleaching of NQB traffic is straightforward, whereas per-user per-DSCP re-mapping isn't, so this approach would allow the ISP the ability to selectively enable/disable NQB marking on a per-user basis if need be.
>
> The first option strikes me as being less likely anyway, since it involves new feature development on home routers.  Many ISPs do not write their own home router implementations.
>
> In all cases the ISP needs to ensure that supporting NQB on downlink traffic benefits their customers in the end.  This involves some type of control/policing of the NQB marking. This could be via traffic protection implemented on PHB compliant links, or it could be via other policies implemented in other network elements.
>
> It seems to me that Sebastian's proposal simply creates a barrier to deployment and/or a degradation of the relevance of the IETF recommended DSCP, but no real protections.
>
> In my view, the sought after protections come instead from giving ISPs guidance on avoiding the potential for harm in WiFi networks that use existing equipment, as well as recommendations for upgrades to WiFi equipment to enable full PHB support (including traffic protection).  I am comfortable with David's suggestion to mandate that NQB PHB equipment that provides residential broadband service be capable of bleaching NQB to Default.
>
> I stand by the original proposal to assign 0x2A.
>
> Greg
>
>
>
> On 11/15/19, 2:27 AM, "tsvwg on behalf of Ruediger.Geib@telekom.de" <tsvwg-bounces@ietf.org on behalf of Ruediger.Geib@telekom.de> wrote:
>
>    Hi Sebastian, hi David
>
>    I agree with your analysis. I don't object your proposed DSCP. Should there be a desire to circumvent the situation you describe, 000111 (or another spare 000dd1 DSCP) might be an option. As said, proposed only for the case that your suggestion doesn't reach consensus.
>
>    Regards,
>
>    Ruediger
>
>    -----Ursprüngliche Nachricht-----
>    Von: tsvwg <tsvwg-bounces@ietf.org> Im Auftrag von Sebastian Moeller
>    Gesendet: Freitag, 15. November 2019 09:35
>    An: Black, David <David.Black@dell.com>
>    Cc: tsvwg@ietf.org
>    Betreff: Re: [tsvwg] NQB - which DSCP to recommend?
>
>    Hi David,
>
>
>    > On Nov 15, 2019, at 01:58, Black, David <David.Black@dell.com> wrote:
>    >
>    > Lurking in the lengthy discussion about NQB and existing WiFi is a topic that needs broader WG attention, please.   Sebastian wrote:
>    >
>    > > IMHO the upshot of this should be to
>    > >
>    > > a)  propose a DSCP for the NQB PHB that maps into AC_BE
>    >
>    > The general topic is which DSCP should be the recommended DSCP for the  NQB PHB.  The NQB draft proposes 0x2A, but the WG may choose to select a different DSCP for this purpose.
>    >
>    > Ok, please discuss …
>
>    	[SM] I propose to use 0x6 (000110) as DSCP for the NQB PHB on un-charcaterized networks, and to use 0x6A (101110) if the receiving network is known to contain NQB compatible wifi elements (or that network operator requested the re-mapping) as re-mapping to 0x6A (101110) will by default get packets into the desired AC_VI.
>
>    	According to https://datatracker.ietf.org/meeting/99/materials/slides-99-tsvwg-sessb-31measurements-concerning-the-dscp-for-a-le-phb-00 partial bleaching can re-map a few common PHBs into the same DSCP (occurrence of partial bleach reported ~10%). But out of the "common" DSCPs only AF13, AF23, AF33, AF43, and EF carry 110 in their low three bits, and since all of the denote high priority (which partially indicates a request for low latency) this re-mapping does not see catastrophic and it certainly does carry the same cause priority inversion concerns that were relevant in selecting the LE PHB DSCP (https://tools.ietf.org/html/rfc8622).
>
>    	I believe this to be a viable path forward that a) protects unsuspecting wifi networks from unintended side-effects of inceasing the use of AC_VI, yet b) allows ISPs to roll-out APs/wifi-routers equipped to handle NQB in the desired fashion. (By using a construct like hostapd's qos_map NQB-aware APs should even be able to instruct stations to map 0x6 into AC_VI if that should be desired).
>
>
>    Best Regards
>    	Sebastian
>
>
>    >
>    > Thanks, --David
>    > ----------------------------------------------------------------
>    > David L. Black, Senior Distinguished Engineer Dell EMC, 176 South St.,
>    > Hopkinton, MA  01748
>    > +1 (774) 350-9323 New    Mobile: +1 (978) 394-7754
>    > David.Black@dell.com
>    > ----------------------------------------------------------------
>
>
>
>