Re: [tsvwg] draft-ietf-tsvwg-nqb, more questions

Sebastian Moeller <moeller0@gmx.de> Thu, 14 November 2019 08:34 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 6B8C31200D5 for <tsvwg@ietfa.amsl.com>; Thu, 14 Nov 2019 00:34:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Level:
X-Spam-Status: No, score=-2.349 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 SXUOuxH68bI3 for <tsvwg@ietfa.amsl.com>; Thu, 14 Nov 2019 00:34:49 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 92E5712012A for <tsvwg@ietf.org>; Thu, 14 Nov 2019 00:34:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573720481; bh=tIVaqvynV7U4My2ppWCnyuqJwGD8z/TUJkLJWmY9pj4=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=kZapyewEw/isu9BprjwFXp8NeBhvHDBNx9HTllHHPRmka6FslgW/6gDMhPZ5s+gz2 15XQRCiJasewInrq7ttjcD/87WEh1xMt2UcvpzMQH7gt5mA9xSp2dwRgHJTq9NZxUn ci7jn5+CDssZyNcbyKVY3oj2Lz+N3l+X+G/0d1MM=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.11.12.33] ([134.76.241.253]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N79u8-1hoVXX0ThU-017RTv; Thu, 14 Nov 2019 09:29:27 +0100
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: <F987CC3A-7042-48EE-BB1D-248FFDC61C50@cablelabs.com>
Date: Thu, 14 Nov 2019 09:29:25 +0100
Cc: "Black, David" <David.Black@dell.com>, tsvwg IETF list <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9A34C2BC-AC12-4D98-907F-E3BD416A4DD3@gmx.de>
References: <90ED003C-CC25-4ED4-90D8-BA572E39D852@gmx.de> <AC0FF00A-9AA7-4582-8F96-1E4E27AEB8D8@cablelabs.com> <20DE8A61-AD71-4C60-A90E-1CCB22E3C6BE@gmx.de> <FA5AC140-F5AA-410B-8067-1B042868049A@cablelabs.com> <CCE580A4-4075-4E2D-9392-DB35389F289B@gmx.de> <28A4C4A8-91C6-4C3F-8563-F862A7247833@cablelabs.com> <084B4D20-5A54-45EE-9519-469BC860C088@gmx.de> <D6C969B0-1F24-434F-9C5C-376BB6C61F8B@cablelabs.com> <E005A81D-6A48-4CF6-A262-BE3F891D5714@gmx.de> <E9A88675-15A2-4D00-AB17-B1F5AD39EB89@cablelabs.com> <MN2PR19MB4045880399E027F159164051837B0@MN2PR19MB4045.namprd19.prod.outlook.com> <449D8EE5-0EA0-4B6C-8C66-4456D238044C@gmx.de> <MN2PR19MB4045EEFDB1F3CE84DC0ECF77837B0@MN2PR19MB4045.namprd19.prod.outlook.com> <1D6C2D8A-4707-4A6F-A107-62A17C9996CC@cablelabs.com> <0134F754-07CD-4DE0-BC2A-172A6FBE4720@gmx.de> <MN2PR19MB4045EB91494913880EC6B75E83740@MN2PR19MB4045.namprd19.prod.outlook.com> <66E05DAD-3BE7-4655-8F37-1E9E919A09FE@cablelabs.com> <MN2PR19MB4045FB6A74A00217D35C719B83770@MN2PR19MB4045.namprd19.prod.outlook.com> <B38EC9E3-00EE-46A3-AF60-FB0BCA531D2D@cablelabs.com> <MN2PR19MB4045C1523C58DD86388D433D83710@MN2PR19MB4045.namprd19.prod.outlook.com> <F987CC3A-7042-48EE-BB1D-248FFDC61C50@cablelabs.com>
To: Greg White <g.white@CableLabs.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:1p8G9yIrOUXBVpzq00Kg78H5aIzVTZwGhZUKRlkjf+tK2SfqJpM A/otaz5j6hVtTfoa/IX3gOG97Lm0DxnokSJ840KfDbP2vTQjakGDjZ+54nN9F+3oNMLCNO1 Pet6hVp1egkivXckP7ERuKUnYGkyd5G94nRKcPTNf59MdobhNkSHIxeKgiKV/1AkfA4qOdM iO/6bYxJnK9L9H4qKC/vA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:2o5f1yMd4/M=:hGc91GYQKuTmGB0EU0JFRr v6W44ixgXMMG9MVN7ybxeqU/RAHoqbMib9kRDfsegowUkPL98ulLGam/vku5rk+1mxikICvfc cnvntx7hybl1qn7DgKDd2J6tO6I6xvGS8ZNLe66KLvWBXpx7s0a9AFq1myvY46CFrwOmrtNFE 3vCpocmVz32QBtHzo/xyrpiBts7CDuHwMRwsiSEaGXsoF9kLVbJqN9S1FKPN6GoxvxTpj5okb PXhuM5nRdZrxv6i9r6MhpVXlifKTSqtZ8HA/Gm2/HMq7MfuAkHmCZUf6slLOjk+9iSxV0Fju+ mFNHWNHy/bOQE3U9ZHY6WveG6U6wrPIu4Pi7KcJ1g3Jo9ViwpQr9US64APFoAtRUHnHx2AkXr LTaiWfK4wZmXrLN58Ko+ZzCZcTgpCchwT4I4HgLBTR+RPz4NfAmTVceJj9jM8d1mrWa35TVsS p01VlbQ+DbVkB1kReiNQywfaVOeVGDnIaDdx4YZwKfoBBPMAHzhMnlJ+lRwnJ7q2vBBmyvcKC /zNRLwmO4k1GOYvKBtAuPBFpT1DsKiBaMLJXganPdW4y0G5PytTggap6OiucmyF19CA7ctsn6 UYnSMqn7WSIGYbj911pqaa6HNcUiFFNVl47F6FSfndHaI8241Yb/1oGgc7ljhs3TNDRsW8r9o SqSr1sJOlMO4aqaagPAg7a/EWq3gveHu7Nky/N+Q3UCN34ZA3Xduf+NQRf5C9G5rmoqsA8Xfg AJO5u1SFZx/6hfH/WeGmSXFCFNauN52bwKvQtXMNLUPwJHK516mL3ZUq2lD8gkPeBQXGucwA/ twLaRTMZMID+oHBn/2GYZj7wNJAa6pOFTurcaaeS3zFlf+M05weHwgOOjGMLSqqZsiEPYgQhL WP2zkxObrADjmu0Rb3S2pcPb6Y1Vv2mgPFZsoxxj4n/Dju10Un5PKSmiJWUDaSXiwRmGpzV2P H7JF9tFNnabfp2eJXoVzuhx0PCkPfea1kROgV7gJ5LFmjj5zl+ynMjkUY+jQ2ZaaemEjSKJUJ 7l57DNCoA2C6c+E1viKezN8xLso081SIu6dSnbQLevESyX4T8h6Cm3rHh6KxR1uqPUUmvhujx jYwXRWQHH19Fw0iD1DsbneQ7t7EK6cf6xuZ5BTE3KhYaeqx8shSDGCN55fv7h6ZKHTsztOO9y coj4eyktTKS3zhuINY1JeUR/1QmVW5ZDb/+oNSr0VAK+FZffx6LlcV0F1qgr9PPceTUbj/bVV eSNlGGD4qoBl6jsfkLe7DIkmtqThsDHQsFCxCFI+I3auZSmO/Oix0VOy7+to=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/3jBjjBNTWPYujP6EUe25AzXk7BA>
Subject: Re: [tsvwg] draft-ietf-tsvwg-nqb, more questions
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, 14 Nov 2019 08:34:54 -0000

Hi Greg,

more below.

> On Nov 14, 2019, at 07:09, Greg White <g.white@CableLabs.com> wrote:
> 
> Thanks David, see [GW] inline.
> 
> 
> 
> On 11/13/19, 9:12 PM, "Black, David" <David.Black@dell.com> wrote:
> 
>    Hi Greg,
> 
>    The use of "controlled" instead of "rate limited" in the proposed text seems fine to me.  However, I think there's still have a problem in ensuring that the operator has functionality available to meet that "operator MUST ensure" requirement in that text.   I do understand this ... 
> 
>> Also, if I were an ISP, I would want to observe that a problem actually exists
>> before I start investing in remedies.   This requirement is predicated on a belief
>> of Sebastian's that may or may not come true in reality.
> 
>    ... but what's the operator supposed to do in the time period between when the customer calls to complain and when the new equipment can be ordered, delivered and installed?  I would agree with your view that a blanket "MUST" requirement on all equipment that supports the NQB PHB is probably overkill, but I suspect that an operator who does not want to invest in remedies until the problem is observed also does not want to invest in rolling trucks if the problem is observed ;-).
> 
> [GW] An operator could monitor traffic volumes using standard counters to understand the likelihood of a problem occurring, and then presumably (though not assuredly) have a bit of lead time to work on remedies if need be.

	[SM] That is not how wifi, or variable bit rate links work in general... The ISP counters will not tell whether meaningful starvation by NQB traffic actually exists downstream. I agree that an ISP should do this to avoid flooding by NQB traffic though, as that is almost guaranteed to lead to my scenario of concern.

>    One simple (perhaps too simple?) approach would be to require that if the NQB PHB is supported on equipment that could be connected to the sort of WiFi network described, then any interface that could be connected to such a WiFi network MUST be configurable (by the operator) to remark all NQB traffic to Default (zero DSCP), as zero is a known-to-be-safe NQB PHB rate in this scenario.  For a cable network, I think the "could be connected" provision would exempt all head-end equipment, which should reduce the impact.  But (as noted) this approach may be too simple - what would you suggest?
> 
> [GW] Actually, that functionality exists today in cable equipment, so my constituents shouldn't have a problem with it being a requirement here.
>  I suppose ISPs (or their equipment suppliers) that don't deploy cable equipment would need to weigh in if they find this to be objectionable.  

	[SM] Are you really proposing to make the functionality of user operated wifi networks conditional on ISPs wishes here? An ISP can always just opt to ignore an RFC (and sure no RFC should require something impossible/improbable) but we are not really talking about major investments here (DSCP resetting equipment needs to be at the edge anyway, if only to bleach DSCPs coming from the customer). End-users how ever can not be expected to even know about the details required to mitigate potential NQB side-effects (DSCP re-mapping on ingress, re-mapping of DSCP to AC in the AP, changing EDCA parameters).
	I note that all of this will help very little, if the part of the RFC that talks about making NQB safe to traverse the internet un-bleached, in that case there is no ISP that would be responsible for controlling the NQB rate (not bleaching DSCPs but simply ignoring them is AFAICT a permissable option for handling diffserve markimgs).

IMHO the upshot of this should be to 

a)  propose a DSCP for the NQB PHB that maps into AC_BE

b) instruct edge network operators to re-map NQB to a DSCP that maps into AC_VI, IFF it is safe to do so (either because the downstream has is known to handle NQB properly, or NQB traffic is controlled)

I base this on the principle of least surprise and the fact that as we agree NQB can, under certain conditions, have adverse affects on wifi networks.


> I'm not as familiar with OLT and BRAS capabilities.  Unless I hear objections, I will go ahead and add that requirement.
> 
> 
> 
>    Thanks, --David
> 
>> -----Original Message-----
>> From: Greg White <g.white@CableLabs.com>
>> Sent: Wednesday, November 13, 2019 7:51 PM
>> To: Black, David
>> Cc: tsvwg IETF list
>> Subject: Re: [tsvwg] draft-ietf-tsvwg-nqb, more questions
>> 
>> 
>> [EXTERNAL EMAIL]
>> 
>> Ok, how about:
>> 
>> In situations where a network operator is introducing aggregate traffic into
>> network outside of their control (e.g. a user's home network) that is known or
>> presumed to be utilizing non-NQB-aware, WMM-enabled WiFi, and where the
>> receiving network does not have the ability to re-mark traffic or adjust the
>> mapping of NQB traffic to WMM Access Category, the operator MUST
>> ensure that the rate of NQB traffic is controlled so as to prevent it from
>> monopolizing airtime to the detriment of QB traffic.
>> 
>> 
>> I wrote "controlled" instead of "limited" since "rate limited" to me gives the
>> impression of a traditional rate limiter (such as token bucket), whereas in this
>> case I think it is good to leave options open for more sophisticated solutions.
>> For example, if the operator can identify a category of "non-sparse" flows that
>> have marked themselves as NQB, while the remaining sparse NQB traffic (in
>> aggregate) amounts to only 2 Mbps, then simply detecting the non-sparse flows
>> and re-marking them as Default would be sufficient.
>> 
>> I understand your interest in ensuring that there are tools available to do this,
>> but since this rate control function is only needed in certain scenarios, and even
>> in those scenarios could be implemented in equipment other than the devices
>> that implement the PHB (perhaps even in software written by the ISP
>> themselves) I don’t think it works to add it as a mandatory requirement on NQB
>> PHB equipment.
>> 
>> Also, if I were an ISP, I would want to observe that a problem actually exists
>> before I start investing in remedies.   This requirement is predicated on a belief
>> of Sebastian's that may or may not come true in reality.
>> 
>> -Greg
>> 
>> 
>> 
>> On 11/11/19, 10:39 PM, "Black, David" <David.Black@dell.com> wrote:
>> 
>>    Inline ...
>> 
>>    Thanks, --David
>> 
>>> -----Original Message-----
>>> From: Greg White <g.white@CableLabs.com>
>>> Sent: Monday, November 11, 2019 8:16 PM
>>> To: Black, David; Sebastian Moeller
>>> Cc: tsvwg IETF list
>>> Subject: Re: [tsvwg] draft-ietf-tsvwg-nqb, more questions
>>> 
>>> 
>>> [EXTERNAL EMAIL]
>>> 
>>> Ok, I see your point.   The context for the MUST needs to be a bit more
>> specific.
>>> The MUST would only apply in the case that the "network operator" in
>> question
>>> is introducing aggregate traffic into "someone else's" WiFi network, where
>> that
>>> someone else doesn’t have the ability to support the NQB PHB (either via
>> new
>>> software in their AP, or via EDCA parameter changes) and doesn't have the
>>> ability to apply the RFC2474 or RFC2475 functions (re-mark NQB or treat it
>> as
>>> default).
>> 
>>    [David>] Yes, that needs to be explained at about that level of detail.
>>> 
>>> In terms of equipment requirements, it seems to me that this could be
>>> implemented as part of the "traffic protection" mechanism in an upstream
>>> device, or it could be implemented further back in the operator's network in
>>> either flow-aware or flow-blind ways. Because of this, and also because the
>>> MUST is only true in certain deployment contexts, I'm not sure that it is
>> correct
>>> to mandate that a particular device (let alone a device that itself supports
>> the
>>> NQB PHB) be burdened with specific mandatory requirements here.  I think it
>> is
>>> sufficient to require that the operator handle this situation appropriately.
>> 
>>    [David>] Need to ensure that the tools are available to the operator who
>> wants to do that.  The "MUST implement" requirement is about ensuring that
>> the operator has the tools available.
>>> 
>>> 
>>> How about the following for the new text:
>>> 
>>> WMM systems, by default, are configured to provide statistically prioritized
>>> channel access for the four Access Categories, with "Voice" being given
>> highest
>>> priority, followed by "Video", "Best Effort" and "Background".  Since
>>> prioritization of NQB traffic over QB traffic is contrary to the requirements
>> of
>>> the NQB PHB and could erode the principle of incentive alignment, care
>> needs to
>>> be taken in introducing NQB-marked traffic into such networks.  One remedy
>> is
>>> to configure the EDCA parameters for the Video Access Category to match
>>> those of the Best Effort Access Category, thus giving the two queues
>> statistically
>>> equal access to the channel.  Another remedy is to limit the amount of
>> traffic
>>> that is allowed to be marked as NQB, such as to ensure that it does not
>>> monopolize airtime to the detriment of QB traffic.
>>> 
>>> In situations where a network operator is introducing aggregate traffic into
>>> network outside of their control (e.g. a user's home network) that is known
>> or
>>> presumed to be utilizing non-NQB-aware, WMM-enabled WiFi, and where
>> the
>>> receiving network does not have the ability to re-mark traffic or adjust the
>>> mapping of NQB traffic to WMM Access Category, the operator MUST
>> employ a
>>> remedy to ensure that QB traffic is not disadvantaged.
>> 
>>    [David>] The problem is that this "MUST" is almost meaningless, because "a
>> remedy" and "not disadvantaged" are indistinct terms.  The latter can be
>> explained elsewhere, as it's part of the PHB behavior, and referenced from here.
>> For the former, I think rate limiting needs to be mentioned here, and in order to
>> ensure that this tool is available to operators, a "MUST implement" requirement
>> to rate limit outbound NQB traffic on any port that may exit a Diffserv domain
>> or region appears to be in order..
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 11/11/19, 4:53 PM, "Black, David" <David.Black@dell.com> wrote:
>>> 
>>>    At the bottom ...
>>> 
>>>    Thanks, --David
>>> 
>>>> -----Original Message-----
>>>> From: Sebastian Moeller <moeller0@gmx.de>
>>>> Sent: Saturday, November 9, 2019 4:07 PM
>>>> To: Greg White
>>>> Cc: Black, David; tsvwg IETF list
>>>> Subject: Re: [tsvwg] draft-ietf-tsvwg-nqb, more questions
>>>> 
>>>> 
>>>> [EXTERNAL EMAIL]
>>>> 
>>>> Hi Greg,
>>>> 
>>>> one more thought below.
>>>> 
>>>>> On Nov 9, 2019, at 20:02, Greg White <g.white@CableLabs.com>
>> wrote:
>>>>> 
>>>>> David,
>>>>> 
>>>>> Thanks for these suggestions.  I agree that rate limiting aggregate
>> NQB
>>> traffic
>>>> could be an approach to address the concern.
>>>>> 
>>>>> It seems to me that this concern exists only for existing residential WiFi
>>>> networks, which do not support the NQB PHB, are known to treat 0x2A
>> as
>>> higher
>>>> priority than the 0x1* and 0x0* DSCPs, and are unlikely to have other
>> means
>>> of
>>>> re-marking traffic before it hits the WiFi link.  For interconnections with
>>> another
>>>> AS, the recommendations in Section 2.3.4.2 of RFC 2475 and Section 4.1
>> of
>>> RFC
>>>> 2474 (unrecognized DSCPs) should be sufficient.
>>>>> 
>>>>> On that basis, I think that any such text would be placed in the section
>> on
>>>> existing WiFi (which, in retrospect, I should not have put in the PHB "Use
>>> Cases"
>>>> section of the draft, but rather as a separate "Interoperability ..."
>> section, to
>>>> avoid confusion).
>>>>> 
>>>>> Also, I think the remedies available in this situation include more than
>> just
>>> rate
>>>> limiting (and other remedies may be preferred in some cases), so I would
>> not
>>>> want to make it a MUST that rate limiting be employed.
>>>>> 
>>>>> I've taken a stab at some text below.
>>>>> 
>>>>> 
>>>>> 
>>>>> 8. Interoperability with WiFi Networks
>>>>> 
>>>>>  WiFi networking equipment compliant with 802.11e generally
>> supports
>>>>>  either four or eight transmit queues and four sets of associated EDCA
>>>>>  parameters (corresponding to the four WiFi Multimedia Access
>>>>>  Categories) that are used to enable differentiated media access
>>>>>  characteristics.  Implementations typically utilize the IP DSCP field
>>>>>  to select a transmit queue, but should be considered as Non-
>>>>>  Differentiated Services-Compliant Nodes as described in Section 4 of
>>>>>  [RFC2475].  As a result this document discusses interoperability with
>>>>>  WiFi networks, as opposed to PHB compliance.
>>>>> 
>>>>>  As discussed in [RFC8325], most existing implementations use a
>>>>>  default DSCP to User Priority mapping that utilizes the most
>>>>>  significant three bits of the DiffServ Field to select "User
>>>>>  Priority" which is then mapped to the four WMM Access Categories.
>> In
>>>>>  order to increase the likelihood that NQB traffic is provided a
>>>>>  separate queue from QB traffic in existing WiFi equipment, the 0x2A
>>>>>  codepoint is preferred for NQB.  This would map NQB to UP_5 which
>> is
>>>>>  in the "Video" Access Category.
>>>>> 
>>>>>  Systems that utilize [RFC8325], SHOULD map the NQB codepoint to
>> UP_5
>>>>>  in the "Video" Access Category.
>>>>> 
>>>>>  WMM systems, by default, are configured to provide statistically
>>> prioritized
>>>> channel access for the four Access Categories, with "Voice" being given
>>> highest
>>>> priority, followed by "Video", "Best Effort" and "Background".  Since
>>>> prioritization of NQB traffic over QB traffic is contrary to the
>> requirements
>>> of
>>>> the NQB PHB and could erode the principle of incentive alignment, care
>>> needs to
>>>> be taken in introducing NQB-marked traffic into such networks.  One
>> remedy
>>> is
>>>> to configure the EDCA parameters for the Video Access Category to
>> match
>>>> those of the Best Effort Access Category, thus giving the two queues
>>> statistically
>>>> equal access to the channel.  Another remedy is to limit the amount of
>>> traffic
>>>> that is allowed to be marked as NQB, such as to ensure that it does not
>>>> monopolize airtime to the detriment of QB traffic.   In situations where a
>>>> network operator is introducing aggregate traffic into a network that is
>>> known
>>>> or presumed to be utilizing WMM-enabled WiFi, the operator MUST
>> employ
>>> a
>>>> remedy to ensure that QB traffic is not disadvantaged.
>>>> 
>>>> 	[SM] To be actionable this should be "the operator MUST employ one of
>>>> the enumerated remedies to ensure that QB traffic is not
>> disadvantaged" if
>>>> other remedies appear the RFC should be amended or replaced.
>>>> 
>>>> Best Regards
>>>> 	Sebastian
>>>> 
>>>    [David>] This text is "digging in the right place" but could use some
>> additional
>>> editing.
>>> 
>>>    The mention of EDCA parameters implies that "the operator" is the
>> operator
>>> of the WiFi network, so that implied context carries over to the next
>> sentence
>>> about limiting traffic that is marked as NQB.  That leaves the final sentence
>> in an
>>> odd position because it's about the situation where "the operator" is not the
>>> operator of the WiFi network, but rather of an adjacent network.  I suggest
>>> moving the final sentence into a separate paragraph, adding that context,
>> and
>>> adding the example that we've been discussing, e.g., imposing a suitable
>> rate
>>> limit on NQB traffic introduced into the WiFi network.   Turning to the
>>> equipment providers, what's the corresponding "MUST implement"
>> requirement
>>> for that equipment - i.e., what has to be implemented in the edge network
>>> element in order to ensure that the operator can control NQB traffic, e.g.,
>> via
>>> rate limiting?
>>> 
>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 11/8/19, 4:43 PM, "Black, David" <David.Black@dell.com> wrote:
>>>>> 
>>>>>   Looks like progress - more inline ...
>>>>> 
>>>>>   Thanks, --David
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Sebastian Moeller <moeller0@gmx.de>
>>>>>> Sent: Friday, November 8, 2019 6:23 PM
>>>>>> To: Black, David
>>>>>> Cc: Greg White; tsvwg IETF list
>>>>>> Subject: Re: [tsvwg] draft-ietf-tsvwg-nqb, more questions
>>>>>> 
>>>>>> 
>>>>>> [EXTERNAL EMAIL]
>>>>>> 
>>>>>> Hi David,
>>>>>> 
>>>>>> 
>>>>>>> On Nov 8, 2019, at 20:56, Black, David <David.Black@dell.com>
>> wrote:
>>>>>>> 
>>>>>>> Hi Greg,
>>>>>>> 
>>>>>>> Backing up a few messages, I might have found a way out of this
>>> debate.
>>>>>> Sebastian wrote:
>>>>>>> 
>>>>>>>>  	[SM] Sorry with source, I was not talking about individual
>>> senders,
>>>>>>>> but about the "NQB/L4S complex" that I expect to cause a lot of
>> NQB
>>>> marked
>>>>>>>> traffic to appear on the ingress side of home users once it gets off
>> the
>>>>>>>> ground.
>>>>>>> 
>>>>>>> That specific situation appears to be straightforward to address
>> because
>>>>>> the edge of the ISP network that supports Diffserv is involved.
>>> Specifically,
>>>>>> the specification of the NQB PHB ought to include text to the effect
>> that
>>>>>> outbound NQB-marked traffic MUST be rate limited at the egress
>> from
>>> the
>>>>>> Diffserv domain/region if the downstream (receiving) network is not
>>> known
>>>>>> to support NQB (this is not the precise language, but should convey
>> the
>>>>>> concept).
>>>>>> 
>>>>>> 	[SM] I like this idea, I just wonder how that is going to work in
>> the
>>>>>> light of highly variable transmit rates on wifi links? IMHO AP &
>> stations
>>> are in
>>>>>> a better position to meaningfully rate limit than any upstream
>> element.
>>>>> 
>>>>>   [David>] Apply a generous "fudge factor" so that the NQB rate limit
>> is
>>> well
>>>> short of any rate that could cause trouble.  My initial sense is that this
>> NQB
>>> rate
>>>> limit limit is a safety limit that does not have an optimization goal, so the
>>> rate
>>>> can be set well short of transmission rates that have a reasonable
>> possibility
>>> of
>>>> causing trouble.  As part of, this, I'm hoping that there's limited
>> downside to
>>>> remarking more NQB traffic to Default (best effort) than necessary in
>> this
>>>> situation.  I understand that the WiFi AP/station would be a more
>> effective
>>>> location for this sort of functionality, but in this situation, we are able
>>> specify
>>>> the functionality of the immediate upstream ISP element, but not the
>> well-
>>> worn
>>>> WiFi AP that the user bought on eBay last week.
>>>>> 
>>>>>   I would leave configuration of NQB rate limits to network operators.
>>> Also, in
>>>> extremis, zero is always a safe NQB egress rate ;-), so would it help to
>>> require
>>>> that the NQB egress rate be configurable to zero?
>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> In the reverse direction rate limiting NQB traffic on ingress (or
>> outright
>>>>>> bleaching it to best effort if the subscriber should not be using NQB in
>> the
>>>>>> first place) seems like a good idea, and may rise to the level of a
>> MUST
>>>>>> requirement if the NQB-supporting  network that the traffic is
>> entering
>>> does
>>>>>> not implement traffic protection for the NQB "queue" at each
>> network
>>> node.
>>>>>> With a little creativity, the necessary rate limiting might be able to
>> take
>>>>>> advantage of an NQB queue protection mechanism if one is present
>> at
>>> the
>>>>>> Diffserv edge.
>>>>>>> 
>>>>>>> The individual sender situation appears to be of less concern, as at
>> least
>>> in
>>>>>> this case it looks like an instance of:
>>>>>>> 
>>>>>>> 	If you point the gun at your own foot and pull the trigger, do
>>> not ask
>>>>>> where the hole in your foot came from.
>>>>>>> 
>>>>>>> As, at least for the home user, the result is only to damage her own
>> WiFi
>>>>>> network, particularly if the ISP ingress node protects its network from
>> the
>>>>>> user sending too much NQB-marked traffic.
>>>>>>> 
>>>>>>> Thanks, --David
>>>>>>> 
>>>>>>>> -----Original Message-----
>>>>>>>> From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Greg White
>>>>>>>> Sent: Thursday, November 7, 2019 7:45 PM
>>>>>>>> To: Sebastian Moeller
>>>>>>>> Cc: tsvwg IETF list
>>>>>>>> Subject: Re: [tsvwg] draft-ietf-tsvwg-nqb, more questions
>>>>>>>> 
>>>>>>>> 
>>>>>>>> [EXTERNAL EMAIL]
>>>>>>>> 
>>>>>>>> It seems as if you are arguing from religious grounds.   There is no
>>>>>> "NQB/L4S
>>>>>>>> complex" that is nefariously seeking to saturate your home
>> network.
>>>>>>>> 
>>>>>>>> So, I will try to ask the question again.
>>>>>>>> 
>>>>>>>> If the policy that gets written into the RFC is that NQB traffic
>> should
>>> not be
>>>>>>>> high data rate traffic, then this achieves your objective?  If we
>> include
>>> a
>>>>>>>> paragraph like that which exists in RFC 8325 that explains why, in
>> the
>>> case
>>>>>> of
>>>>>>>> WiFi networks, it should not be high data rate traffic, would that
>> be
>>>>>>>> sufficient?
>>>>>>>> 
>>>>>>>> -Greg
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 11/7/19, 5:09 PM, "Sebastian Moeller" <moeller0@gmx.de>
>> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Nov 8, 2019, at 00:20, Greg White <g.white@CableLabs.com>
>>> wrote:
>>>>>>>>> 
>>>>>>>>> You've still missed the point.
>>>>>>>>> 
>>>>>>>>> 	[SM] It will keep one expected major source of DSCP marked
>>> traffic
>>>>>>>> on a sane(r) policy.
>>>>>>>>> 
>>>>>>>>> No. It won't.
>>>>>>>>> 
>>>>>>>>> What will keep that source on a sane policy is that they have an
>>> interest
>>>>>>>> in having a sane policy.  This IETF draft does not create that
>> interest,
>>> nor
>>>>>>>> would it prevent them from running amok.
>>>>>>>>> 
>>>>>>>>> -Greg
>>>>>>>> 
>>>>>>>>  	[SM] Sorry with source, I was not talking about individual
>>> senders,
>>>>>>>> but about the "NQB/L4S complex" that I expect to cause a lot of
>> NQB
>>>>>> marked
>>>>>>>> traffic to appear on the ingress side of home users ionce it gets off
>> the
>>>>>>>> ground. And my point is very much to give my best arguments to
>> make
>>>>>> sure
>>>>>>>> you do not end up writing a bad policy into an RFC. What ever you
>> do
>>> in
>>>>>> the
>>>>>>>> real world is outside of the scope of the IETF, but taking that as an
>>>>>> argument
>>>>>>>> in favor of bad engineering is simply a bad argument.
>>>>>>>>  	And regarding your interpretation of individual senders, it is
>>> clear that
>>>>>>>> remote senders have a snowballs chance in hell to react timely to
>> the
>>>>>>>> variable bitrates on a wifi segment, hence the wifi elements AP
>> (and
>>>>>> ideally
>>>>>>>> STAs) will need to enforce sanity and make sure tp avoid
>> starvation.
>>> This is
>>>>>>>> not a new requirement, but the status quo is that most traffic is
>> AC_BE,
>>> so
>>>>>>>> the lack of enforcement was sort of tolerable; but either NQB
>> withers
>>>>>> away
>>>>>>>> and will not be used (and all of this discussion does not matter) or
>> it
>>> will be
>>>>>>>> used and then you better make sure that NQB will not be found out
>> as
>>> a
>>>>>>>> reason why non-NQB on-line gaming starts to suck. But really
>> looking
>>> at
>>>>>> the
>>>>>>>> AC stats from my laptop:
>>>>>>>> 
>>>>>>>>  laptop:~ user$ sudo netstat -I en0 -qq
>>>>>>>>  en0:
>>>>>>>>       [ sched:  FQ_CODEL  qlength:    0/128 ]
>>>>>>>>       [ pkts:          0  bytes:          0  dropped pkts:    185 bytes:  55724 ]
>>>>>>>>  =====================================================
>>>>>>>>       [ pri: VO (1)	srv_cl: 0x400180	quantum: 600
>>> 	drr_max: 8 ]
>>>>>>>>       [ queued pkts: 0	bytes: 0 ]
>>>>>>>>       [ dequeued pkts: 171322	bytes: 15967234 ]
>>>>>>>>       [ budget: 0	target qdelay: 10.00 msec	update
>>>>>> interval:100.00 msec ]
>>>>>>>>       [ flow control: 0	feedback: 0	stalls: 0	failed: 0 ]
>>>>>>>>       [ drop overflow: 0	early: 0	memfail: 0	duprexmt:0 ]
>>>>>>>>       [ flows total: 0	new: 0	old: 0 ]
>>>>>>>>       [ throttle on: 0	off: 0	drop: 0 ]
>>>>>>>>  =====================================================
>>>>>>>>       [ pri: VI (2)	srv_cl: 0x380100	quantum: 3000
>> 	drr_max: 6 ]
>>>>>>>>       [ queued pkts: 0	bytes: 0 ]
>>>>>>>>       [ dequeued pkts: 1081254	bytes: 95307849 ]
>>>>>>>>       [ budget: 0	target qdelay: 10.00 msec	update
>>>>>> interval:100.00 msec ]
>>>>>>>>       [ flow control: 0	feedback: 0	stalls: 0	failed: 0 ]
>>>>>>>>       [ drop overflow: 0	early: 0	memfail: 0	duprexmt:0 ]
>>>>>>>>       [ flows total: 0	new: 0	old: 0 ]
>>>>>>>>       [ throttle on: 0	off: 0	drop: 0 ]
>>>>>>>>  =====================================================
>>>>>>>>       [ pri: BE (7)	srv_cl: 0x0	quantum: 1500	drr_max: 4 ]
>>>>>>>>       [ queued pkts: 0	bytes: 0 ]
>>>>>>>>       [ dequeued pkts: 41792980	bytes: 10120070005 ]
>>>>>>>>       [ budget: 0	target qdelay: 10.00 msec	update
>>>>>> interval:100.00 msec ]
>>>>>>>>       [ flow control: 9	feedback: 9	stalls: 8	failed: 0 ]
>>>>>>>>       [ drop overflow: 0	early: 5	memfail: 0	duprexmt:0 ]
>>>>>>>>       [ flows total: 0	new: 0	old: 0 ]
>>>>>>>>       [ throttle on: 0	off: 0	drop: 0 ]
>>>>>>>>  =====================================================
>>>>>>>>       [ pri: BK (8)	srv_cl: 0x100080	quantum: 1500
>> 	drr_max: 2 ]
>>>>>>>>       [ queued pkts: 0	bytes: 0 ]
>>>>>>>>       [ dequeued pkts: 4392109	bytes: 1258595132 ]
>>>>>>>>       [ budget: 0	target qdelay: 10.00 msec	update
>>>>>> interval:100.00 msec ]
>>>>>>>>       [ flow control: 2	feedback: 2	stalls: 2	failed: 0 ]
>>>>>>>>       [ drop overflow: 0	early: 0	memfail: 0	duprexmt:0 ]
>>>>>>>>       [ flows total: 0	new: 0	old: 0 ]
>>>>>>>>       [ throttle on: 0	off: 0	drop: 0 ]
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>  and my OpenWrt router:
>>>>>>>> 
>>>>>>>>  root@router:~# cat
>> /sys/kernel/debug/ieee80211/phy1/ath9k/xmit
>>>>>>>>                              BE         BK        VI        VO
>>>>>>>> 
>>>>>>>>  MPDUs Queued:             4933        120       595     47628
>>>>>>>>  MPDUs Completed:          2765        331      1045    110627
>>>>>>>>  MPDUs XRetried:           2792         30       381       216
>>>>>>>>  Aggregates:            4053416     109096     11152         0
>>>>>>>>  AMPDUs Queued HW:            0          0         0         0
>>>>>>>>  AMPDUs Completed:     29761018     931822    280598         0
>>>>>>>>  AMPDUs Retried:         484203      23327      4543         0
>>>>>>>>  AMPDUs XRetried:          8606        149       754         0
>>>>>>>>  TXERR Filtered:             97          7        32        37
>>>>>>>>  FIFO Underrun:               0          0         0         0
>>>>>>>>  TXOP Exceeded:               0          0         0         0
>>>>>>>>  TXTIMER Expiry:              0          0         0         0
>>>>>>>>  DESC CFG Error:              0          0         0         0
>>>>>>>>  DATA Underrun:               0          0         0         0
>>>>>>>>  DELIM Underrun:              0          0         0         0
>>>>>>>>  TX-Pkts-All:          29775181     932332    282778    110843
>>>>>>>>  TX-Bytes-All:        672115293 1008162267 199579558  20417055
>>>>>>>>  HW-put-tx-buf:               8          8         8         8
>>>>>>>>  HW-tx-start:          21266021     570626    256944    110799
>>>>>>>>  HW-tx-proc-desc:      21266026     570629    257004    110839
>>>>>>>>  TX-Failed:                   0          0         0         0
>>>>>>>> 
>>>>>>>> 
>>>>>>>>  Summary packet numbers:
>>>>>>>>  AC	Laptop
>>>>>>>>  BE:		 41792980	29775181
>>>>>>>>  BK:		   4392109	    932332
>>>>>>>>  VI:		   1081254	    282778
>>>>>>>>  VO:		     171322	    110843
>>>>>>>>  Total:	 47437665	31101134
>>>>>>>> 
>>>>>>>> 
>>>>>>>>  So my status quo is that all four AC are used with the fraction of
>>>>>>>> AC_VI+AC_VO at
>>>>>>>>  100*(1081254+ 171322)/47437665 = 2.6 % (laptop)
>>>>>>>>  100*(282778 + 110843)/31101134 = 1.3 % (router)
>>>>>>>> 
>>>>>>>>  This is with relative high streaming media usage.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>  Best Regards
>>>>>>>>  	Sebastian
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 11/7/19, 4:12 PM, "Sebastian Moeller" <moeller0@gmx.de>
>>> wrote:
>>>>>>>>> 
>>>>>>>>> Hi Greg,
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On Nov 7, 2019, at 23:44, Greg White
>> <g.white@CableLabs.com>
>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> Sebastian,
>>>>>>>>>> 
>>>>>>>>>> I agree that this isn't rocket science.  In the existing WiFi systems
>>> that
>>>>>>>> we're discussing, there are 16 DSCPs that get mapped to AC_VI,
>> and 16
>>>>>>>> DSCPs that get mapped to AC_VO.   No one polices any of them in
>>>>>> residential
>>>>>>>> WiFi networks!  There is nothing that prevents anyone from writing
>> an
>>>>>>>> application today that sends bulk traffic marked as CS7 (a value
>> that
>>> the
>>>>>> IETF
>>>>>>>> considers to be reserved).
>>>>>>>>> 
>>>>>>>>> 	[SM] Sure, but thanks to ISP often bleaching DSCPs there
>>> currently is
>>>>>>>> very little in and outgoing traffic that actually maps to anything but
>>> AC_BE,
>>>>>>>> you propose to change that in a major way, with your attempt at
>>> making
>>>>>> NQB
>>>>>>>> end to end (with one end potentially being in a close data center
>> with
>>> an
>>>>>> SLA
>>>>>>>> allowing for NQB survival). Just because no one has massively
>> abused
>>> this
>>>>>> so
>>>>>>>> far, is NOT a justification to do so now.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> I believe that the reason that RFC 8325 simply wrings its hands
>> over
>>> this
>>>>>>>> issue, as opposed to solving it, is that A) it is a *really* hard
>> problem to
>>>>>> solve
>>>>>>>> in an unmanaged network, and B) while it is certainly a problem in
>>> theory,
>>>>>>>> there is no evidence that it is a real problem in practice.
>>>>>>>>> 
>>>>>>>>> 	[SM] The problem is that there is simply no data, and
>>> interpreting this
>>>>>>>> as there is no problem is neither solid science nor engineering. If
>> you
>>> have
>>>>>>>> measurements showing that this is no problem with the expected
>>> traffic
>>>>>>>> rates with the NQB marking, please feel free to post them to the
>> list or
>>> as
>>>>>>>> PM.
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Blocking the IETF from assigning NQB the 0x2A value does
>>> *nothing* to
>>>>>>>> prevent an application from using 0x2A (or any of the other 31
>> code
>>> points
>>>>>>>> that you are concerned about) for *any* purpose that the
>> application
>>>>>>>> developer sees fit, it does *nothing* to prevent a network
>> operator
>>> from
>>>>>>>> using 0x2A for NQB traffic, and it does *nothing* to help solve the
>>> main
>>>>>> issue
>>>>>>>> that you are concerned about.
>>>>>>>>> 
>>>>>>>>> 	[SM] It will keep one expected major source of DSCP marked
>>> traffic
>>>>>>>> on a sane(r) policy. Most users and applications do not bother
>> paying
>>> with
>>>>>>>> dscps so the current amount of abuse is limited (and if I configure
>> my
>>>>>> internal
>>>>>>>> skype and ssh applications to even use AC_VO I can control their
>>> activity
>>>>>> and
>>>>>>>> usage much better than I can traffic rushing in from the internet).
>> Sure
>>> I
>>>>>> can
>>>>>>>> re-map 0x2A to a sane value on ingress to my network, but that is
>> not
>>>>>> going
>>>>>>>> to help that much if my neighbors do not do this, and their APs
>> start
>>>>>> hogging
>>>>>>>> all tx_ops on the shared channel.
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> If you want to solve this problem, my suggestion is that you start
>> a
>>> new
>>>>>>>> draft proposing a technology that will holistically protect WiFi
>>> networks
>>>>>> from
>>>>>>>> all potential DSCP abuses.
>>>>>>>>> 
>>>>>>>>> 	[SM] First rule of holes, put the shovel away when you find
>>> yourself
>>>>>>>> inside one. Here, I am not concerned so much in fixing all wifi AC
>> abuse
>>>>>> and
>>>>>>>> more in giving my best to avoid this unfortunate and undesirable
>>>>>> condition
>>>>>>>> getting worse.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Sebastian
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Greg
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On 11/7/19, 3:00 PM, "Sebastian Moeller" <moeller0@gmx.de>
>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> Greg,
>>>>>>>>>> 
>>>>>>>>>>> On Nov 7, 2019, at 22:11, Greg White
>> <g.white@CableLabs.com>
>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Sebastian,
>>>>>>>>>>> 
>>>>>>>>>>> In the interest of moving this forward and not going in circles,
>>>>>>>>>> 
>>>>>>>>>> 	[SM] My impression is not that we going in circles, it is a rather
>>> slow
>>>>>>>> road to understanding and accepting the properties and limitations
>> of
>>>>>> wifi's
>>>>>>>> unfortunate prioritization scheme in conjunction with your
>> intended
>>> use
>>>>>> of
>>>>>>>> the NQB dscp. Me shutting up, would not change the underlaying
>> facts
>>>>>> that
>>>>>>>> need to be considered here if the issue is to be solved.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> I think you summarized your position as: "To be explicit, I do
>> not
>>>>>> object
>>>>>>>> on principle to using AC_VI or even AC_VO as long as this does not
>> eat
>>>>>>>> significantly into the tx_ops for AC_BE, the current draft improves
>> in
>>> that
>>>>>>>> direction. Would it be possible to make this point even stronger?"
>>>>>>>>>>> 
>>>>>>>>>>> In my view, as long as the applications that we're
>> recommending to
>>> be
>>>>>>>> marked NQB are no more bandwidth intensive than video
>> conferencing
>>>>>> (the
>>>>>>>> applications that the IETF already recommends be marked with a
>> DSCP
>>>>>> that
>>>>>>>> maps to AC_VI), then we have achieved what is needed.  Do you
>>> agree?
>>>>>>>>>> 
>>>>>>>>>> 	To state the obvious, "no more bandwidth intensive than video
>>>>>>>> conferencing" is virtually meaningless as it will give very little
>> guidance
>>> on
>>>>>>>> acceptable either single flow nor aggregate NQB traffic share or
>>> absolute
>>>>>>>> bandwidth (yes rfc8325 is also pretty silent on this, but "look mum,
>> the
>>>>>> other
>>>>>>>> guys are doing it too" is not the best of defenses IMHO). I realize
>> that
>>> this
>>>>>> is
>>>>>>>> an issue for you as you explicitly target NQB as requiring no
>>> prioritization
>>>>>> or
>>>>>>>> rate-limiting, I get that; but I believe that on wifi since you
>> effectively
>>>>>>>> propose to use a prioritization system you really really should
>> require
>>>>>> rate-
>>>>>>>> limiting.
>>>>>>>>>> 
>>>>>>>>>> rfc8325, section 8.2:
>>>>>>>>>> "The wireless LAN presents a unique DoS attack vector, as
>> endpoint
>>>>>>>>>>   devices contend for the shared media on a completely
>> egalitarian
>>>>>>>>>>   basis with the network (as represented by the AP).  This means
>> that
>>>>>>>>>>   any wireless client could potentially monopolize the air by
>> sending
>>>>>>>>>>   packets marked to preferred UP values (i.e., UP values 4-7) in
>> the
>>>>>>>>>>   upstream direction.  Similarly, airtime could be monopolized if
>>>>>>>>>>   excessive amounts of downstream traffic were
>> marked/mapped to
>>>>>>>> these
>>>>>>>>>>   same preferred UP values.  As such, the ability to mark/map to
>>> these
>>>>>>>>>>   preferred UP values (of UP 4-7) should be controlled.
>>>>>>>>>> 
>>>>>>>>>>   If such marking/mapping were not controlled, then, for
>> example, a
>>>>>>>>>>   malicious user could cause WLAN DoS by flooding traffic
>> marked
>>> CS7
>>>>>>>>>>   DSCP downstream.  This codepoint would map by default (as
>>>>>>>> described
>>>>>>>>>>   in Section 2.3) to UP 7 and would be assigned to the Voice
>> Access
>>>>>>>>>>   Category (AC_VO).  Such a flood could cause Denial-of-Service
>> to
>>> not
>>>>>>>>>>   only wireless voice applications, but also to all other traffic
>>>>>>>>>>   classes.  Similarly, an uninformed application developer may
>>> request
>>>>>>>>>>   all traffic from his/her application be marked CS7 or CS6,
>> thinking
>>>>>>>>>>   this would achieve the best overall servicing of their
>> application
>>>>>>>>>>   traffic, while not realizing that such a marking (if honored by
>> the
>>>>>>>>>>   client operating system) could cause not only WLAN DoS, but
>> also
>>> IP
>>>>>>>>>>   network instability, as the traffic marked CS7 or CS6 finds its
>> way
>>>>>>>>>>   into queues intended for servicing (relatively low-bandwidth)
>>>>>>>> network
>>>>>>>>>>   control protocols, potentially starving legitimate network
>> control
>>>>>>>>>>   protocols in the process."
>>>>>>>>>> 
>>>>>>>>>> To me this clearly indicates that the achievable wifi rate betwnn
>> AP
>>> and
>>>>>>>> each station needs to be taken into account when considering
>> which
>>>>>> fraction
>>>>>>>> of > AC_BE traffic is acceptable. So very much incompatible with
>> your
>>> goal
>>>>>> of
>>>>>>>> having endpoints set the NQB dscp based on their own best
>>> assessment
>>>>>> of
>>>>>>>> traffic type without some sanitization at the AP level (only the AP
>> will
>>>>>> have a
>>>>>>>> reasonable chance of predicting immediate achievable rates with
>> some
>>>>>>>> confidence, neither endpoints nor intermediate low latency queue
>>>>>> enabled
>>>>>>>> AQMs have sufficient knowledge to judge what traffic rate is
>>> acceptable
>>>>>> for
>>>>>>>> AC_VI). I consider it to be quite unfortunate that rfc8325 has no
>>>>>> references
>>>>>>>> to research on real-world data on the consequences of actually
>>> following
>>>>>>>> through with its recommendations, nor that it has robust
>>>>>> recommendations
>>>>>>>> of recommended maximal fractions of the achievable rate each AC
>>> should
>>>>>> be
>>>>>>>> constrained to.
>>>>>>>>>> 
>>>>>>>>>> All of this is not really rocket science, and the obvious solution,
>>>>>>>> following both the principle of least surprise and a "first, do no
>> harm"
>>>>>> maxim
>>>>>>>> is to select the NQB dscp such that the unfortunate default DSCP to
>> AC
>>>>>>>> mappings keep NQB marked traffic in the AC_BE queue, UNLESS
>> the AP
>>> is
>>>>>>>> NQB-aware in which case the AP should be mandated to at least
>>> reliably
>>>>>>>> avoid starvation of ACs.
>>>>>>>>>> The amount of back and forth seems to indicate that this is not
>> an
>>>>>>>> outcome you consider desirable.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Sebastian
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> -Greg
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On 11/5/19, 1:58 AM, "Sebastian Moeller"
>> <moeller0@gmx.de>
>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Hi Greg,
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> On Nov 5, 2019, at 01:28, Greg White
>> <g.white@CableLabs.com>
>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Hi Sebastian,
>>>>>>>>>>>> 
>>>>>>>>>>>> Interoperability with existing WiFi equipment is an important
>>> aspect,
>>>>>>>> since WiFi latency can be considerable. By default, many existing
>> APs
>>> only
>>>>>>>> support 4 priority queues, and thus it is not possible to meet all of
>> the
>>>>>>>> requirements of the NQB PHB (at least in this default
>> configuration).
>>>>>>>>>>> 
>>>>>>>>>>> 	[SM] I agree the question is how to deal with that
>> "impedance
>>>>>>>> mismatch".
>>>>>>>>>>> 
>>>>>>>>>>>> Nonetheless, it is possible to utilize two of the four queues in
>>> order
>>>>>>>> to meet some of the requirements, and thus provide some of the
>>>>>> benefits of
>>>>>>>> the NQB PHB.
>>>>>>>>>>> 
>>>>>>>>>>> 	[SM] Unless you opt for selecting AC_BK for the NQB
>> traffic, for
>>>> most
>>>>>>>> users the value of NQB will be mostly in the priority boost on wifi
>> and
>>> the
>>>>>>>> resulting air-time access advantage (which results in both lower
>>> latency
>>>>>> and
>>>>>>>> potentially higher bandwidth).
>>>>>>>>>>> 
>>>>>>>>>>>> With proper configuration and/or policies, this can be done
>>> safely.
>>>>>>>>>>> 
>>>>>>>>>>> 	[SM] Sure, I am concerned about the status quo wich
>> does not
>>>> entail
>>>>>>>> "proper configuration and/or policies", and hence I believe the
>> NQB
>>>>>> special
>>>>>>>> treatment on WIFI should be opt-in and not "opt-out" (in quotes as
>>> most
>>>>>>>> endusers will not be able to opt-out). For thid reaon I believe that
>> the
>>>>>>>> proposal to use a code point that by default is mapped to AC_BK is
>> the
>>>>>> only
>>>>>>>> correct solution (as a bonus it seems that such a code point also
>> has a
>>>>>> better
>>>>>>>> chance to survive transit over the internet). NQB-aware APs then
>>> simply
>>>>>>>> treat that NQB-codepoint however they want. If for example a
>> priority
>>>>>> boost
>>>>>>>> is desired such an AP can easily implement the required rate-
>> limiting so
>>>>>> that
>>>>>>>> AC_BE traffic does not get starved out. In short, I fully agree that
>>> special
>>>>>>>> treatment requires "proper configuration and/or policies" and the
>>>>>> desirable
>>>>>>>> strategy if that can not guaranteed should be "do no harm".
>>>>>>>>>>> 
>>>>>>>>>>>> The final SHOULD is intended to address your concern about
>>>>>>>> prioritization (since it results in segregation without prioritization).
>>>>>>>>>>> 
>>>>>>>>>>> 	[SM] Ah, in that case the AP needs to be be NQB aware
>> anyway,
>>>>>>>> would it then not be better to use an appropriate scheduler/AQM
>> in
>>> front
>>>>>> of
>>>>>>>> the AC_BE queue and keep all traffic in the same priority class? The
>>>>>>>> disadvantage of setting AC_VI to the same EDCA values as AC_BE
>> is
>>> then
>>>>>> that
>>>>>>>> applicatons that expect an airtime access boost from using AC_VI
>> will
>>> not
>>>>>> get
>>>>>>>> it any more (not necessarily a deal-breaker but certainly
>> unexpected
>>>>>> enough
>>>>>>>> to merit clear communication of that side-effect).
>>>>>>>>>>> 
>>>>>>>>>>>> Absent this requirement (or the ability to comply with it
>>>>>>>> operationally), the operator would need to consider (and perhaps
>> limit)
>>>>>>>> which applications are allowed to be marked as NQB.  This aspect
>> isn't
>>>>>>>> discussed in the draft, but I will add it based on your input.
>>>>>>>>>>> 
>>>>>>>>>>> 	[SM] Great! I would guess the safest would be to have
>> the NQB-
>>>>>>>> aware scheduler in an AP apply some (proportional) rate-limiting if
>>> NQB
>>>>>>>> traffic is getting preferential air-time access.
>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Network operators understand the value of segregating NQB
>>> traffic
>>>>>>>> on WiFi links, and will almost certainly select a DSCP in practice
>> that
>>>>>> achieves
>>>>>>>> that goal.
>>>>>>>>>>> 
>>>>>>>>>>> 	[SM] That is exactly part of my concern with the default
>>>> mapping to
>>>>>>>> AC_VI approach, I expect that very quickly a lot of traffic will utilize
>> the
>>>>>> AC_VI
>>>>>>>> queue potentially starving normal AC_BE traffic in the process.
>>>>>>>>>>> 
>>>>>>>>>>>> Assigning a different DSCP in this draft would do nothing to
>>> prevent
>>>>>>>> them from doing so.
>>>>>>>>>>> 
>>>>>>>>>>> 	[SM] Sure, but is that really a good justification for
>> proposing a
>>>> DSCP
>>>>>>>> with known side-effects? As far as I am concerned an RFC should
>>> propose
>>>>>>>> sane defaults and hope for the best.
>>>>>>>>>>> 
>>>>>>>>>>>> Instead, what we need to do is clearly articulate how to make
>>> best
>>>>>>>> use of the existing WiFi tools, and how to avoid conflicts.
>>>>>>>>>>> 
>>>>>>>>>>> 	[SM] I believe the last two are mutually exclusive...
>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> In existing RFCs, the IETF already recommends that video
>>>>>>>> conferencing applications mark their traffic as either AF4x or CS4,
>> all of
>>>>>> which
>>>>>>>> get mapped to AC_VI.  The remaining language in the NQB draft
>>> describes
>>>>>>>> sparser flows than these.
>>>>>>>>>>> 
>>>>>>>>>>> 	[SM] as an implementer I read "relatively low data
>> rates",
>>>> without
>>>>>>>> further guidance I have very little intuition what to use as
>> reference.
>>>>>> Could
>>>>>>>> this be made more explicit? This is orthogonal to the question
>> whether
>>>>>> such
>>>>>>>> a limit should be enforced in any way, here the question really is
>> about
>>>>>>>> getting a feel what is considered acceptable for NQB treatment.
>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Based on your comments, I attempted to remove all text that
>>> could
>>>>>>>> be interpreted as recommending that high-data-rate traffic be
>> marked
>>>>>> NQB.
>>>>>>>>>>> 
>>>>>>>>>>> 	[SM] Thanks, as long as the aggregate NQB traffic is
>> relative
>>>> sparse
>>>>>>>> compared to the available WiFi bandwidth (or the number of
>> tx_ops)
>>>>>> most of
>>>>>>>> my WiFi concerns get less and less relevant. To be explicit, I do not
>>> object
>>>>>> on
>>>>>>>> principle to using AC_VI or even AC_VO as long as this does not eat
>>>>>>>> significantly into the tx_ops for AC_BE, the current draft improves
>> in
>>> that
>>>>>>>> direction. Would it be possible to make this point even stronger?
>>>>>>>>>>> 
>>>>>>>>>>>> It appears that I missed one instance (in the Introduction it
>> gives
>>>>>>>> "interactive voice and video" as an example). Aside from this
>> (which I
>>> can
>>>>>>>> correct), I think the draft currently recommends that NQB only be
>> used
>>>>>> for
>>>>>>>> sparse traffic.  That said, the section where this guidance is
>> intended to
>>> be
>>>>>>>> given is still lacking in specificity, and poses some open questions
>> that
>>> may
>>>>>>>> need to be addressed in a subsequent revision.
>>>>>>>>>>> 
>>>>>>>>>>> 	[SM] Sounds great. Now this then cycles back to one of
>> the
>>>> other
>>>>>>>> open topics, "enforcement". Ideally NQB-aware APs should
>> monitor
>>> both
>>>>>>>> queues and re-assign flows between them based on flow-behavior
>> in
>>>>>>>> relation to time-variant bandwidth experienced by that flow.
>>>>>>>>>>> 
>>>>>>>>>>> Best Regards
>>>>>>>>>>> 	Sebastian
>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>> Greg
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On 11/4/19, 3:25 PM, "tsvwg on behalf of Sebastian Moeller"
>>>>>> <tsvwg-
>>>>>>>> bounces@ietf.org on behalf of moeller0@gmx.de> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Regarding https://datatracker.ietf.org/doc/draft-ietf-tsvwg-
>>>>>>>> nqb/?include_text=1
>>>>>>>>>>>> 
>>>>>>>>>>>> 7.3.  WiFi Networks
>>>>>>>>>>>> 
>>>>>>>>>>>> WiFi networking equipment compliant with 802.11e generally
>>>>>>>> supports
>>>>>>>>>>>> either four or eight transmit queues and four sets of
>> associated
>>>>>>>> EDCA
>>>>>>>>>>>> parameters (corresponding to the four WiFi Multimedia
>> Access
>>>>>>>>>>>> Categories) that are used to enable differentiated media
>> access
>>>>>>>>>>>> characteristics.  Implementations typically utilize the IP DSCP
>> field
>>>>>>>>>>>> to select a transmit queue, but should be considered as Non-
>>>>>>>>>>>> Differentiated Services-Compliant Nodes as described in
>> Section
>>> 4
>>>>>>>> of
>>>>>>>>>>>> [RFC2475].  As a result this document discusses
>> interoperability
>>> with
>>>>>>>>>>>> WiFi networks, as opposed to PHB compliance.
>>>>>>>>>>>> 
>>>>>>>>>>>> As discussed in [RFC8325], most existing implementations use
>> a
>>>>>>>>>>>> default DSCP to User Priority mapping that utilizes the most
>>>>>>>>>>>> significant three bits of the DiffServ Field to select "User
>>>>>>>>>>>> Priority" which is then mapped to the four WMM Access
>>>>>> Categories.
>>>>>>>> In
>>>>>>>>>>>> order to increase the likelihood that NQB traffic is provided a
>>>>>>>>>>>> separate queue from QB traffic in existing WiFi equipment,
>> the
>>>>>>>> 0x2A
>>>>>>>>>>>> codepoint is preferred for NQB.  This would map NQB to
>> UP_5
>>>>>>>> which is
>>>>>>>>>>>> in the "Video" Access Category.
>>>>>>>>>>>> 
>>>>>>>>>>>> Systems that utilize [RFC8325], SHOULD map the NQB
>> codepoint
>>> to
>>>>>>>> UP_5
>>>>>>>>>>>> in the "Video" Access Category.
>>>>>>>>>>>> 
>>>>>>>>>>>> In order to preserve the incentives principle, WiFi systems
>>> SHOULD
>>>>>>>>>>>> configure the EDCA parameters for the Video Access
>> Category to
>>>>>>>> match
>>>>>>>>>>>> those of the Best Effort Access Category.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> [SM] This last section is puzzling: if the wifi system configures
>>> AC_VI
>>>>>>>> with EDCA parameters that match the AC_BE parameters, AC_VI
>>> ceases
>>>>>> to
>>>>>>>> be different from AC_BE, in that case picking a codepoint that
>>>>>> automatically
>>>>>>>> maps to CS0 and hence to AC_BE  seems much safer, simpler and
>>> straight
>>>>>>>> forward to me.
>>>>>>>>>>>> Especially since essentially none of the millions deployed WiFi
>> APs
>>>>>> out
>>>>>>>> there will a) have this configured like proposed already and b) none
>> of
>>> the
>>>>>>>> consumer APs I know actually allow to easily adjust EDCA
>> parameters
>>> at
>>>>>> all. I
>>>>>>>> guess I must be missing something and would be delighted to be
>> shown
>>>>>> why
>>>>>>>> the proposed text is the right thing.
>>>>>>>>>>>> My take on this still is, if NQB traffic is sufficiently sparse using
>>> AC_VI
>>>>>>>> can be justified, but without any rate limits this has the potential of
>>> being
>>>>>>>> quite unfair to concurrent APs on the same channel (as well as the
>>>>>>>> neighboring channels that overlap with the selected).
>>>>>>>>>>>> I do not want to sound alarmist, but given the number of
>> cable-
>>> ISP
>>>>>>>> WiFi-APs (as indicated by a SSID containing the ISPs name) in my
>> city, I
>>>>>>>> believe making sure that those APs will not basically start hogging
>> most
>>>>>>>> airtime seems the prudent thing to do. If there are sufficient
>> backstops
>>> in
>>>>>>>> place (like rate limiting or automatic down-marking if the traffic is
>> not
>>>>>> sparse
>>>>>>>> enough) to avoid the described situation, I am all for it.
>>>>>>>>>>>> 
>>>>>>>>>>>> The text probably should also openly discuss that in
>> WiFi/WMM
>>> the
>>>>>>>> four available queues by design have different priorities, and by
>> moving
>>>>>> NQB
>>>>>>>> out of the default AC_BE while leaving QB flows in there, this
>>> effectively
>>>>>> runs
>>>>>>>> against  the following text in the draft: "The NQB queue SHOULD
>> be
>>> given
>>>>>>>> equal priority compared to queue-building traffic of equivalent
>>>>>> importance."
>>>>>>>> (leaving alone the question how an AP or a station is supposed to
>>>>>> measure
>>>>>>>> importance)
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Sebastian
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>> 
>>> 
>> 
>> 
> 
> 
>