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

Sebastian Moeller <moeller0@gmx.de> Thu, 05 September 2019 08:26 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 82C631200A1 for <tsvwg@ietfa.amsl.com>; Thu, 5 Sep 2019 01:26:19 -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 ANZr83D4JF0s for <tsvwg@ietfa.amsl.com>; Thu, 5 Sep 2019 01:26:18 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 7D418120058 for <tsvwg@ietf.org>; Thu, 5 Sep 2019 01:26:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1567671968; bh=fdKP8bkELaHqYUK0daCmzj4tfwsIljTaD+MYatWTqPo=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=fte+nvx1Ltyd2rBvcn6QSwPisl0aje4bL1kdm93IcolHdKcHY2wHTRFOGViy2gSos 0cP+Szi4a7ewOm06AghEqcNHyYINTMWM/8XBOZ1aUQlkqnXvj0MLCx+Rs2NkfRws4r jKiA1bW5wUz6QzVJnmZE8xp3AXcpo68J0Yx5wpYM=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.11.12.32] ([134.76.241.253]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MWk7n-1he0ZQ35AJ-00XwHS; Thu, 05 Sep 2019 10:26:07 +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: <AA4DBFC5-8D8F-4F43-80E4-BB9BA7F53486@cablelabs.com>
Date: Thu, 5 Sep 2019 10:26:05 +0200
Cc: "Black, David" <David.Black@dell.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6EC5E3CB-5687-46E4-9A1F-02E4F60DC379@gmx.de>
References: <CE03DB3D7B45C245BCA0D24327794936306BBE54@MX307CL04.corp.emc.com> <AA4DBFC5-8D8F-4F43-80E4-BB9BA7F53486@cablelabs.com>
To: Greg White <g.white@CableLabs.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:n/ZhVN8uOB2Qu3+qy4e/4lDMc1g7SNjO606SJ+HrI5R6uldJru3 U8M2Mk338GXj37Sc+t28XjzKoTmygLAAzsifve5468q0au36OLcEg06pQt3Das2Mv5GCLE2 L00oqd6yojyweKWYl3ZftZMQd+b/ezNa/B4c1cnp77yxvmnBN9Lh0cl8vr+3CLGXYUR8gvf ktOx/0sg1peo3WxNXZcEg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:BPdLzZHINEQ=:KhKdocP4jaZUjAzgKB7DTC NZvwS2XeHcamB8iCD7hNRXcrgyiymJbTNaCBv+M5OwppDpKR8qpUJ0rBRuKVANI21hIGQ9/x2 s9q+1vmMDhJe5rkulUbD1ciBX2tIDuGXNY5dEw6UPTP6wxQH/1S48Fa2YeQmBLbNp/Ipgd5h1 wzpWw++nAjBJIiouFFKBeT8ZxJgRGMGlQ0Aaz5YgzaqWOWhLiKPPHDbgBO7jd1/m/smfRIQyH UuGSueyaFwBpFsM2DVLAoa6XYB/XYvUfFb4XjvnJjxs3lblngjpwsCTSZbF0urbrbkyKfmzTp 2McNPNNsOflPnYj3lnasz80SsWfuEeyDUGvdq9DJBzXOvQwNOZCBXWxdPl5NsbxZAshCRNVpx 0K3KZnju2S0pvdRQHtWpw7ogcJCY376GjVnLv8EKcu+3gyaYLpI7aMr3vJz52XaU0NKnDdB0L b1ZbgspPL40tc7i2H13nZjsIf81ouMfoQJg9XCmAJsOvI14FoXzdCNEZLxy9H469x7Mh9VSaS FUY5Atz6wn7Shw0rTpz2jg4FbqJtWJJSaIgkGBV44N6TlYh9KS6X9nNgHYZXSqxX64z78HGnH CtInttu9wPgKS5KOXb63OEIkYRpI3fmHBFxB1feCPLtAAHqCju5HXW507ai51aap5IM9Ksng/ eiqJoj4XxiktkFres3NLnj1qYOT1WK9/zMcNhpnpgFRv+Fq0n3aRZ32G3/Bqk0mut0f9v0fH+ GhuS1lXHxuPHssS5+NsFS+/XFi9FJLLIi6q+Jr+Gi/ZVEmYScNfXMb2vMcUoVRXSsC1FnFtbg ZzhtnyomhoJiE/OJdniUEjTJNPnelbpBLGArN5/+sdpmLZzZX6tnu8xWFL5MRnyuNmr77TZoG ow+xehhFosaFM7sb+NAfQtsnLincj3gGhEW6iVWdpMZVi/m3jEC5vm6qBLS0vV+QkP05dS8wt MoaL0D0kvxD7WHfYo7t88y3wzi2QF10VxicS604XttE8MRWy/+jBSAzW3kmYCgfXttleF8OvW sjNHJ7AFxpsR7YATxvNzE/jRO/jEO9DOQsYhLKyACvEtnDEuCLeYg8CtFzgzAm6wZc4lpzamr //x6MS0Ta93JRLXTR76D8v1mFIiprRsxp0CUEtfE3ApdEOYBTrJuNclEa9OdAjsgcf+kL1DpJ 7u+nCUA03FZvx085ajwHqaOmHQGYgEjSXe9DkdpICJ/NBLmevGI9C2++NTMnAC3LQWoHngu9g 9SBQ+lMkhm3hT7MhJ
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/cpGgC6KxQpJqJOOCJ5jMBzxhJdk>
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, 05 Sep 2019 08:26:19 -0000

Hi Greg,

let me chime in...

> On Sep 5, 2019, at 01:01, Greg White <g.white@CableLabs.com> wrote:
> 
> 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.


Have a look at figure 1 on page 19-20 RFC 8325 (https://tools.ietf.org/html/rfc8325#page-19):

+-------------------------------------------------------------------+
  | IETF Diffserv | PHB  |Reference |         IEEE 802.11              |
  | Service Class |      |   RFC    |User Priority|  Access Category   |
  |===============+======+==========+=============+====================|
  |               |      |          |     7       |    AC_VO (Voice)   |
  |Network Control| CS7  | 
RFC 2474
 |            OR                    |
  |(reserved for  |      |          |     0       | AC_BE (Best Effort)|
  | future use)   |      |          |See Security Considerations-Sec.8 |
  +---------------+------+----------+-------------+--------------------+
  |               |      |          |     7       |    AC_VO (Voice)   |
  |Network Control| CS6  | 
RFC 2474
 |            OR                    |
  |               |      |          |     0       | AC_BE (Best Effort)|
  |               |      |          |    See Security Considerations   |
  +---------------+------+----------+-------------+--------------------+
  |   Telephony   |  EF  | 
RFC 3246
 |     6       |    AC_VO (Voice)   |
  +---------------+------+----------+-------------+--------------------+
  |  VOICE-ADMIT  |  VA  | 
RFC 5865
 |     6       |    AC_VO (Voice)   |
  |               |      |          |             |                    |
  +---------------+------+----------+-------------+--------------------+
  |   Signaling   | CS5  | 
RFC 2474
 |     5       |    AC_VI (Video)   |
  +---------------+------+----------+-------------+--------------------+
  |   Multimedia  | AF41 |          |             |                    |
  | Conferencing  | AF42 | 
RFC 2597
 |     4       |    AC_VI (Video)   |
  |               | AF43 |          |             |                    |
  +---------------+------+----------+-------------+--------------------+
  |   Real-Time   | CS4  | 
RFC 2474
 |     4       |    AC_VI (Video)   |
  |  Interactive  |      |          |             |                    |
  +---------------+------+----------+-------------+--------------------+
  |  Multimedia   | AF31 |          |             |                    |
  |  Streaming    | AF32 | 
RFC 2597
 |     4       |    AC_VI (Video)   |
  |               | AF33 |          |             |                    |
  +---------------+------+----------+-------------+--------------------+
  |Broadcast Video| CS3  | 
RFC 2474
 |     4       |    AC_VI (Video)   |
  +---------------+------+----------+-------------+--------------------+
  |    Low-       | AF21 |          |             |                    |
  |    Latency    | AF22 | 
RFC 2597
 |     3       | AC_BE (Best Effort)|
  |    Data       | AF23 |          |             |                    |
  +---------------+------+----------+-------------+--------------------+
  |     OAM       | CS2  | 
RFC 2474
 |     0       | AC_BE (Best Effort)|
  +---------------+------+----------+-------------+--------------------+
  |    High-      | AF11 |          |             |                    |
  |  Throughput   | AF12 | 
RFC 2597
 |     0       | AC_BE (Best Effort)|
  |    Data       | AF13 |          |             |                    |
  +---------------+------+----------+-------------+--------------------+
  |   Standard    | DF   | 
RFC 2474
 |     0       | AC_BE (Best Effort)|
  +---------------+------+----------+-------------+--------------------+
  | Low-Priority  | CS1  | 
RFC 3662
 |     1       | AC_BK (Background) |
  |     Data      |      |          |             |                    |
  +--------------------------------------------------------------------+

  Note: All unused codepoints are RECOMMENDED to be mapped to UP 0
  (See Security Considerations below)

       Figure 1: Summary of Mapping Recommendations from Downstream
                       DSCP to IEEE 802.11 UP and AC


draft-white-tsvwg-nqb defines the following characteristics for flows to qualify for NQB:

"There are many applications that send traffic at relatively low data rates and/or in a fairly smooth and consistent manner such that they are highly unlikely to exceed the available capacity of the network path between source and sink."
[...]
"These Non-queue-building (NQB) flows are typically UDP flows that send traffic at a lower data rate and don't seek the capacity of the link (examples: online games, voice chat, DNS lookups)"

To me this does not rule out relatively high bandwidth applications like (paced) video delivery over UDP.

Anyway the issue I see is that NQB lumps quite a few different traffic types into one category, and when mapping to AC's it seems prudent to not only look at the best case, but also at the average and worst cases as well.

So with video streams as valid NQB flows (@Greg if you believe streaming video not to qualify for NQB then the draft should mention that explicitly) the highest AC defensible according to figure 1 above is AC_VI. So can we please reduce the discussion to the only open question, does NQB qualify for AC_VI or AC_BE?

I argue that NQB will be used for "low latency data" flows, whether the current draft acknowledges that or not (in the end NQB has all the right trimmings for being the "L4S" dscp and I consider it highly unlikely that it will not be used as a cheap entry into the fast lane). And in that case, I believe the aggregate that is marked by NQB should only be marked AC_BE. 
Especially considering that in the egress direction stations will send NQB-marked packets and hence potentially hog air-time slots if using AC_VI/VO, before the queue protection of the router has any possibility to keep things in check.


	Sebastian

>  
> -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
> ----------------------------------------------------------------
>