Re: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!

Sebastian Moeller <moeller0@gmx.de> Thu, 12 September 2019 08:41 UTC

Return-Path: <moeller0@gmx.de>
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 C711F1208BF for <tsvwg@ietfa.amsl.com>; Thu, 12 Sep 2019 01:41:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 g_ZiFffDUTCG for <tsvwg@ietfa.amsl.com>; Thu, 12 Sep 2019 01:41:14 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 560E612006B for <tsvwg@ietf.org>; Thu, 12 Sep 2019 01:41:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1568277665; bh=2SteAWWUP0QhTPIuKKwB5oniRhzgmWS2Jg7rKxfh6ec=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=M+kDF0gI5EoP4TH2RP548OPdD/j01KGc+Wh3UOYPEWl3+tbfxPjtmZ5m683J+rGhT Xc/rQZ5yIpJtdh0vtb2yKdi4jTPRx/n9yzAXssyVbP1qdcCZvnvaswfUXwCaKhqukZ +4why9p/k+qEwIR/X/PK4pvD427qIx3PycEKkOH4=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.11.12.32] ([134.76.241.253]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MNbkv-1hjxOM1FPP-00P9y4; Thu, 12 Sep 2019 10:41:05 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <LEJPR01MB1178C642457E9018459983999CB00@LEJPR01MB1178.DEUPRD01.PROD.OUTLOOK.DE>
Date: Thu, 12 Sep 2019 10:41:02 +0200
Cc: "<g.white@cablelabs.com>" <g.white@CableLabs.com>, tsvwg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9924D4FB-F5D8-49FE-8EC4-33A778F8ECFA@gmx.de>
References: <CE03DB3D7B45C245BCA0D24327794936306BBE54@MX307CL04.corp.emc.com> <AA4DBFC5-8D8F-4F43-80E4-BB9BA7F53486@cablelabs.com> <LEJPR01MB1178B6C102455F1F9886D49A9CBB0@LEJPR01MB1178.DEUPRD01.PROD.OUTLOOK.DE> <F351D86E-DCE4-45CD-9B08-2E0C11090BF1@cablelabs.com> <LEJPR01MB11789EE6D8B7C732393BD1439CB70@LEJPR01MB1178.DEUPRD01.PROD.OUTLOOK.DE> <B11AB47E-7E35-4599-A85B-DB0EF883E2B2@cablelabs.com> <LEJPR01MB1178D2DCD24874E8AE47202D9CB10@LEJPR01MB1178.DEUPRD01.PROD.OUTLOOK.DE> <864587C3-0A18-41A3-BFA7-00BD9CE56717@cablelabs.com> <LEJPR01MB1178C642457E9018459983999CB00@LEJPR01MB1178.DEUPRD01.PROD.OUTLOOK.DE>
To: Ruediger.Geib@telekom.de
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:lAqvP9m4SI+yjbc0LJsCrP+j29qsuOZq2vzIWrelUIEBpfgDMF3 i2xe2TzhEstXXLM4kie1/l4kSGWbnXS9HgQmBwc6qFW6VbC3KgPB0Rw86WMoLh0VS+nih6l mkG02821eh7dyovLZuqeLW9c89dXUYDJcuTPmWkRDsmHxpRG+BdJe1vSlRBwy2gYTqN/nlf /5b8mkiCVnNZLTeqQ4waQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:roxKOIVnBCE=:3xcKY1GwBUPm/zDaTnnRHh 0i002tGDXj8ijGaWBjGQmTAa3bJo3My6WZYNvs2RdOJwkbAtMnGy+Cj19Hh4lLG743fq2w7rr GOHc3e6OuF5TykVEbsAMy9Ao6/BDNOVepGPxdgm8pth9ROqgmuqrFV7+luyDfL3zxJFOMrl92 aSHVOHWRk549TZPpr7H/khb55T7GPXZ+by84dev4lwKp66t4Ip/B9iv6QTOsSWPdnHcZ0gYfU x6uQn7zw53JJJehZ/KWK5+H1xwqG4HUiTZQoD9mmQtlHsXawoiC3/Gx2Le0H65eMz8hZnjpsU I2jdS8b4j/FF97c+VwV8GYItyJyYZ4I202kcaO2iu0Zcu4plH0WYifCX1aBrMvZqYjLfnn6jq ziJl3VTfIjnJrch/pSg96+lhLobgr5AN5BVmnART1q46P2/fme6NgsBA7ulpTCsORH9sUfAZU AbT/+sH8Ce/7s74p2sKUF4ewPXco74G7meM3hluN5YuVxfI6VRcm1PPnbAS71Lj7rUOPDQ5Ig 2BVDbv58lF5G1nPMSxd1j5LQ0hlfU/KtT57YOwpT7Gq8JGjpadSV6uwgTBU4pwLIFGg2tg8ab /DFPfTQXu+DFnLVmqlgvAbeDXmlF1BFGD9dePhy/FJDOnCYaXRB4tWgrGhbsIR7p2pZ9uoJ+D xH22fiZHrYG3sBDsUrFKMLqVhgELHh33tX5NTblXEYWG/RrNrIXgys5bpmYb7C9aYukOJl7QW 10oOx/YTJmRFd9x6PTIjSQ/hSohxqNU60mMdsMwPjUTzvh0gVRosmReaeqRJQleenGMCHQcvL RF/VxJtSS7RgDfBC5JvFr8B9wZEoYCyB99T/HWoap+SJtjISpFmzQiFBG+mPGt4JzLGC7SDTL 1nWtZXi0AvKZVGdIYEvRatr6lmFur+M9QaI/EFWklNBMbUo3SFC1LW3fO0DAxIdoV3Jgs4bov LQNiiqGv00MKlq07rQbGrZ6sZNWglHHpJYYhmedIMIn3Q05ux5CP+0VXy38iBwHDIxfVMBOII 7/s/cWVOiikdrw+HhTgzznynDB5En8gYfWsUvHITAamz3+usE/UgFOa0o75kf+nS96VuYnSXt 80EcGSS11ukMxfveH21A4VYEYQ2WnjkpErWt47V+lFtC+XWaFY5Q6T7K2WYQUI478BhrIwu7c uvpoAu+8SXhBWSPjxu4kyHOhlpJG+OXKch96CDYSCRTcwD6whcgoDMfLTBvx3ysxnY23E=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/nqdSsVlIrugDWhay3pmBOG7p1tc>
Subject: Re: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!
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: Thu, 12 Sep 2019 08:41:19 -0000

Dear Ruediger,

this time to the list as well ;)


> On Sep 12, 2019, at 08:54, Ruediger.Geib@telekom.de wrote:
> 
> Greg,
>  
> that’s not what I said. You’ll most likely see remarking to default PHB and forwarding as default PHB, unless there’s an SLA in place, if your desire is to mark NQB by a DSCP 101xxx. To preserve a DSCP clearly indicating NQB at interconnection without an SLA in place, I suggest a DSCP 000xx1.

[SM] +1; using 000xx1 will also effortlessly solve the wifi WMM issue with APs that do not explicitly support NQB (in essence all existing APs). But I believe Greg is also trying to put in a requirement that ASs should not re-mark NQB to something else (which in principle I support, at least a few of the dscp bits should be reliably e2e).

Best Regards
	Sebastian


>  
> RFC 8100 contains more information on the background (motivation of the above and how to deal with the issues arising).
> https://datatracker.ietf.org/doc/rfc8100/
>  
> Regards,
>  
> Ruediger
>  
>  
>  
> Von: Greg White <g.white@CableLabs.com> 
> Gesendet: Mittwoch, 11. September 2019 19:14
> An: Geib, Rüdiger <Ruediger.Geib@telekom.de>
> Cc: tsvwg@ietf.org
> Betreff: Re: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!
>  
> Agreed.  I think the most likely implementation in backbones is to allow NQB marking to survive the interconnection, but treat the traffic identically to default traffic until it reaches the edge (access network).
>  
> -Greg
>  
> From: "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de>
> Date: Wednesday, September 11, 2019 at 6:30 AM
> To: Greg White <g.white@CableLabs.com>
> Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
> Subject: AW: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!
>  
> Hi Greg,
>  
> backbone routers handle bulk traffic to the extent that I can tell. Finer grained traffic treatment may be found at network edges terminating consumer access. That is to say: a peer or a customer should agree which DSCPs are exchanged at interconnection or expect re-marking.
>  
> And to add (as that has been discussed too): don’t expect per flow treatment at a congested backbone link. That’s to say, that I don’t expect NQB support by a backbone router in the same way, as by an edge router. The next generation interfaces are n*100 Gbit/s and I’m not sure how these perform trying to identify the “least NQB like flow” in the case of congestion.
>  
> Regards, Ruediger
>  
> Von: Greg White <g.white@CableLabs.com> 
> Gesendet: Dienstag, 10. September 2019 20:30
> An: Geib, Rüdiger <Ruediger.Geib@telekom.de>
> Cc: tsvwg@ietf.org
> Betreff: Re: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!
>  
> Hi Ruediger,
>  
> Yes, my focus (both from the perspective of the systems that I work on, and from the perspective of where I think NQB differentiation is most valuable) is on last mile and WiFi.  In terms of interconnection, there could be multiple ways to handle this.  My view is that the endpoint application has the best a priori knowledge of its sending behavior, so it is good to leverage that (and either validate it or not, depending on what is most appropriate for the situation).   This would argue for networks to adopt a policy of not bleaching the NQB value on traffic arriving from interconnections, and utilizing queue protection if necessary to validate NQB behavior.   That said, there are other ways that network operators can identify NQB traffic without solely relying on endpoint marking (and DSCP preservation across interconnects).  I know some operators are investigating such techniques.  
>  
> -Greg
>  
> From: "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de>
> Date: Monday, September 9, 2019 at 12:57 AM
> To: Greg White <g.white@CableLabs.com>
> Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
> Subject: AW: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!
>  
> Hi Greg,
>  
> to me that reads as if you are mainly interested in a specified NQB DSCP for the last mile. A packet received at interconnection with a DSCP which hasn’t been agreed between sending and receiving domain will be re-written (speaking for the part of the network I work with). 
>  
> That’s ok, as DiffServ involves policy management anyway.
>  
> Regards,
>  
> Ruediger
>  
> Von: Greg White <g.white@CableLabs.com> 
> Gesendet: Freitag, 6. September 2019 19:18
> An: Geib, Rüdiger <Ruediger.Geib@telekom.de>
> Cc: tsvwg@ietf.org
> Betreff: Re: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!
>  
> Hi Ruediger,
>  
> Many networks can (and do) configure the DSCP to PHB mappings and policies in accordance with their own intended usage.  In particular, DOCSIS links and LTE links (likely others as well) can be configured in a manner that complies with the PHB definition.  In other cases, it may be either necessary or sufficient (or both) to support NQB traffic without fully complying with the PHB (of course this isn’t new with NQB).
>  
> One of the high level goals is to ensure that the benefits of differentiating NQB traffic are not lost when that traffic traverses a WiFi link (since in many of the target use cases it does).  WiFi gear will likely not support all of the aspects of the PHB definition (at least current equipment will not).  We are essentially limited to 4 queues (BK, BE, VI, VO) and their associated CSMA parameters.  An additional constraint that we’re faced with is that in many cases the mapping from DSCP to AC is essentially fixed – it is either operationally hard or impossible to change.
>  
> Of the WiFi APs that we’ve tested (a sample of current generation .11ac devices, covering several chipsets) 100% of them use the “default mapping” of DSCP to AC as follows.
>  
> DSCP
> WMM Access Category
> 001xxx, 010xxx
> Background (AC_BK)
> 000xxx, 011xxx
> Best Effort (AC_BE)
> 10xxxx
> Video (AC_VI)
> 11xxxx
> Voice (AC_VO)
>  
> Living within this constraint, and trying to make the best of it, we’ve selected as a default DSCP the 0b101010 value, which would get mapped into the Video Access Category (along with CS4, AF41, AF42, AF43, CS5, VA, EF).  This would ensure that, in large part, NQB traffic is handled in a separate queue from the queue-building bulk data traffic (the vast majority of which uses AC_BE or AC_BK).
>  
> I would not expect that it would be important for NQB marked traffic to be differentiated in core network switches or routers, which in many cases do not provide deep (10’s to 100’s of ms) buffers.  So, in these switches NQB would likely be treated the same as Default (or whichever local use codepoint is used for best effort).
>  
> A characteristic of the NQB PHB as implemented in DOCSIS is that it provides low latency, low latency variation, and low loss for an NQB marked flow as long as the flow is “well behaved”.  If an NQB-marked flow is not well behaved then it experiences greater latency variation, greater loss, and potential re-ordering.   A well behaved flow is one that does not materially cause queue build-up in the network, i.e. its instantaneous rate does not materially exceed the instantaneous available bandwidth of the path.
>  
> In managed networks, or in cases where SLAs are provided, it seems to me that an operator should determine whether traffic that is already in a defined service class would benefit from being further differentiated based on QB vs NQB behavior (like, as you suggested using various AF marks), or whether certain existing service classes can be grouped into QB vs NQB meta-classes, depending on the technology limitations at each hop (MPLS, Ethernet, WiFi, LTE, DOCSIS, etc).  The result of this determination could require the use of non-default (i.e. non-standard) marking of NQB traffic in some cases.
>  
> -Greg
>  
>  
>  
> From: "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de>
> Date: Thursday, September 5, 2019 at 2:03 AM
> To: Greg White <g.white@CableLabs.com>
> Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
> Subject: AW: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!
>  
> Hi Greg,
>  
> the policy of the company I work for is: EF marked traffic received on a peering interface is remarked. DiffServ traffic destined to a retail access is subject to admission control, if that traffic is not expected to experience congestion. 
>  
> The latter might change with high-speed access links. If the users and the above traffic have a hard time congesting these access links, the admission control requirement may not be strictly required. 
>  
> If NQB traffic is supposed to be sent to third parties without an SLA at peering links being in place, proper selection of the DSCP matters. Without a deeper thought, a DSCP 000xx1 may be a proper choice in that case. Without an SLA being in place, the forwarding to be expected is default forwarding. If NQB is supposed to define a default-like behavior for a serious traffic share, it should be marked by a DSCP in the range 000 xxx at interconnection.
>  
> If an SLA is expected to be in place at peerings, any traffic without admission control should face a higher packet drop probability if destined to a retail access, than admission controlled traffic. If I assume the admission controlled traffic to be marked AFx1, NQB traffic in the same queue should be marked AFx2 (or AFx3). I’m open to discuss queue depths and expected traffic properties for a suitable AF class. RFC 8100 proposes to specify DSCPs only at interconnection. That may be a starting point, should SLAs on NQB at peerings be within commercial scope (that’s a non-technical issue, of course).
>  
> The choice of a DSCP for traffic which is created and terminated within a single domain doesn’t need to specified – here the PHB specification is important and the behavior of that traffic in the presence of traffic from other PHBs. I’d again opt for AFx2 or AFx3 (hoping that the NQB PHB specification allows for a useful implementation suiting AFx1 and NQB traffic in the same queue, expecting both to expect no congestion, AFx1 traffic to be admission controlled if present and NQB having features to reduce bandwidth if congestion is imminent).
>  
> I’m not sure what is expected from a backbone network supporting NQB (and other DiffServ PHBs). MPLS supports 8 traffic classes or codepoints, respectively. This coding space includes the codepoints required for ECN (codepoints, not bits).
>  
> I appreciate more standard DSCPs based on a clear and consented definition of the corresponding PHBs. Default marking, LE, EF and Network Management are good examples.
>  
> My take – sorry if I misunderstood some of your design aims, should that be the case.
>  
> Regards,
>  
> Ruediger
>  
> Von: tsvwg <tsvwg-bounces@ietf.org> Im Auftrag von Greg White
> Gesendet: Donnerstag, 5. September 2019 01:02
> An: Black, David <David.Black@dell.com>om>; tsvwg@ietf.org
> Betreff: Re: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!
>  
> Thanks David.
>  
> On your item 3, could you clarify what you mean?   RFC 8325 does not discuss a “non queue building” service class, and so I don’t see a technical inconsistency between the NQB draft and RFC8325.  There has been some discussion on the list as to whether IETF should recommend that NQB be mapped to UP_6/AC_VO or UP_5/AC_VI, but in at least one of those cases where it was suggested to change the draft, the rationale for doing so was based on an incorrect assumption that NQB-marked traffic would by definition include capacity-seeking flows (e.g. L4S).  As I stated on list, I don’t have a problem with changing it to UP_5/AC_VI if that is the consensus.  But, the reason for mapping NQB to UP_6/AC_VO is so that both RFC8325 and “default mapping” 802.11 devices map EF, VA and NQB together to the same UP/AC, and so that both types of devices map these traffic types one AC level “higher” than elastic traffic sources (e.g. AF3x).  I’d like to see a more reasoned argument as to why NQB should be grouped with AF3x traffic as opposed to EF & VA before making a change.
>  
> -Greg
>  
>  
>  
> From: tsvwg <tsvwg-bounces@ietf.org> on behalf of David Black <David.Black@dell.com>
> Date: Friday, August 30, 2019 at 9:41 AM
> To: "tsvwg@ietf.org" <tsvwg@ietf.org>
> Subject: [tsvwg] TSVWG: WG adoption of draft-white-tsvwg-nqb!
>  
> In the Montreal TSVWG meeting, there was a strong sense of the room that the TSVWG WG should adopt draft-white-tsvwg-nqb as a starting point for work on an NQB PHB.   The WG call for adoption on this list has been open for over a week, since August 21, and having seen only one objection on the list to adoption of the draft (from Dave Taht), the WG chairs (Gorry, Wes and David) have concluded that the WG rough consensus is to adopt this draft.  It’s important to emphasize that the draft is adopted as a *starting point* for TSVWG work, i.e., the current draft content does not represent the rough consensus of the WG.  Significant work will be required to produce an actual PHB spec that is suitable for implementation – see the recent RFC 8622 on the LE PHB (https://datatracker.ietf.org/doc/rfc8622/) for an example of what a PHB spec looks like.
>  
> There are a few items that will need attention before the initial -00 WG version of the NQB draft is submitted – these are to avoid confusion about what the WG intends to do:
> 1)      The draft needs to be clear that the use of the 0x2A DSCP value as the default for this PHB is a *suggestion by the authors that is subject to change*.  Whether to use that DSCP or a different one is a WG decision; the plan is to discuss and select the default DSCP value starting (and hopefully concluding) in September.
> 2)      The criticisms on this list of the “queue protection” requirement in the draft are largely accurate.   The draft needs at least an Editor’s Note that this material will be revised, as while the DOCSIS mechanism is an example of how to do queue protection, it is not appropriate to require implementation of that mechanism.   A plausible plan that I have discussed with the authors is to write a set of functional/behavioral requirements for NQB “traffic protection” that can be satisfied by a “queue protection” mechanism such as the DOCSIS mechanism, or by a suitably configured FQ AQM implementation.
> 3)      RFC 8325 reflects the IETF consensus on how to map between Diffserv and WiFi QoS, hence the 8.3 section of the NQB draft needs to be modified to be consistent with RFC 8325.
> 4)      Similarly, the 8.2 section of the NQB draft needs to be modified to reflect the conclusion of discussion on this topic in Montreal.
> Those 4 changes are necessary in the -00 WG version of the NQB draft.
>  
> In addition, related to item 2), my expectation (which is open to further discussion) that “traffic protection” will be a “MUST” requirement, perhaps with some well-specified exceptions (including explanations of why the exceptions are ok).   This is because “traffic protection” (e.g., “queue protection” or a suitably configured FQ AQM) appears to be necessary in general to keep queue-building traffic out of the NQB traffic aggregate, as allowing such traffic degrades the properties of the NQB PHB.
>  
> Thanks, --David (TSVWG co-chair, will be shepherd for NQB draft).
> ----------------------------------------------------------------
> 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
> ----------------------------------------------------------------