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

Sebastian Moeller <moeller0@gmx.de> Thu, 07 November 2019 21:04 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 CDB7E1209AD for <tsvwg@ietfa.amsl.com>; Thu, 7 Nov 2019 13:04:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.348
X-Spam-Level:
X-Spam-Status: No, score=-2.348 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, URIBL_BLOCKED=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 3hoZfWlUDlkh for <tsvwg@ietfa.amsl.com>; Thu, 7 Nov 2019 13:04:17 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 B072112096F for <tsvwg@ietf.org>; Thu, 7 Nov 2019 13:04:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573160647; bh=O55X91UAi0OjL+C7gv8ey8BGYpZUgByU+cgqUgYY1fE=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=PB7SqEOYN0/LDD2f9/PNombJAhogp9gsUg6Pug6bPkjKyCJ7aUZw21AY4kXy4ggxU /E/z1m8Gv7jPR95naVtA6JPzmpJiXzbUbX0CNdKRLJNfXPcLJI3w7j3tJSFjS0Imch yCGNsZ4ZKmdvjY10rCXuJRq1CRO9SBetkAd9EP3s=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([77.6.79.205]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MLQxX-1iC78v3YzD-00IT7q; Thu, 07 Nov 2019 22:04:07 +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: <MN2PR19MB4045169789DF1C145D4EE57983780@MN2PR19MB4045.namprd19.prod.outlook.com>
Date: Thu, 7 Nov 2019 22:04:02 +0100
Cc: Greg White <g.white@CableLabs.com>, tsvwg IETF list <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <37226E5A-B892-4988-9C2A-4719377C1E6A@gmx.de>
References: <90ED003C-CC25-4ED4-90D8-BA572E39D852@gmx.de> <AC0FF00A-9AA7-4582-8F96-1E4E27AEB8D8@cablelabs.com> <20DE8A61-AD71-4C60-A90E-1CCB22E3C6BE@gmx.de> <MN2PR19MB4045003442DB1E7643C96DD083780@MN2PR19MB4045.namprd19.prod.outlook.com> <B5BE8F47-9B0D-456E-8804-1D159875AA53@cablelabs.com> <4E3EC8B5-6A0B-46A8-A273-943FAB389E7D@gmx.de> <MN2PR19MB4045169789DF1C145D4EE57983780@MN2PR19MB4045.namprd19.prod.outlook.com>
To: "Black, David" <David.Black@dell.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:TVDsmOsnrbs4gw6kJsMbuFp4hXbqQZYNKE9kM5SSaHxWRp+oPLF Hk4IEFVSAutfWI02YQZCZ6u2On2vjb/Ya53TKjaNkPqDXhPV4cJTY7LBrreGnCji2FUb3HP ERv3ZzgBo1SzQn/iWxcT/SrQ/fehSlzkv9PMRpG5s/LKxU77fnJQpuSH9fkevsbi3BJ4MN+ xvdnGHBh4gAXE5bUb8Ebw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:cM6k/ugfDhE=:IenQMReWtoTwmW8AcJY/n5 xvi24R7cFBGuVGYtKhe46h334Lr3Rwds/kAa2jg95GpzxpCUl8QI5VJXFk6w8pyLHSuK13iHn YlQBbHzip/CIbjTMv7hn3jcHFiQxIYqkxCKvkPmgjKOnXFR4QbrCOcULHZJjQk/qJKc4bReUE tzJXJowAhSZFsqTCcVu5M+PFWKoLqqZbp+WIRvwiN7NBdpoTLflxkYfADOMuMmNXdh0JknGeW 2W9gsd6fWcqz4QyvtF8kbNaKOQWSXcJBNQRglQJr0uGxIUW+TA/aR/WD5cVV+fif44bs59gk9 YJlyXHIGWevXMm5SgtTEvio6i9DKRm7gQSolSg1t0ahVGtiWhBEToyOVI90UgpnaKydcmr5Pq PE+TZHx/WXub8QtkmtV7rXHlqJ8OKdCiSgGdre315KHoSFxI9tXrFv6NOZAo25oaCPg3cmrch cLMEBGoMn7R06uE+oZTZ4FnO0yF5TXy245fJcvsQ2hMawXXxgleTJLduxpzglSy58/pe7APkX PUp15rOJFuRQ5zpJ0JZtPz9HtE/GApndbXL9q+pXpr9wf4cpKeEe2WtQfkGcB+XH9FoS5O/F9 p4Upm5OqAwNeMSgI1RM0+b9KP3pC7hv5vzxBap+GAXF4+mw4RpilePaRxSf72DmJOx+S88QTW cHy3NYG8iB2V5Y2hI0qWsmhO0Ui3Ucq6AXPTsouP8m0I44wZFCtWg5GeYxZ3JMSarGetTcY6w JZ2Qcx2y8AYj270wOpPO9Nzv9NlNlA27qyhsLcccz1Vk5rGVEVlc5jxMl8nrLaXZYUkza4XA8 0noRRo8XM/sIV6gvIeokq65hFqZrqOitykZCz/KATlU1Erw85ZPTvX09lZv2ZoJ/NdnrtDocZ iW5c4Op4DnsDEtZC/6kIoFxZPNvHZDageOE71BRmwgtL2Y3wCKb5VIyUhCOuDiZi2kMFyE6fx zI0q5Wj7RUL3YCKAkBgGdCA2xT04F3Q22XiwcWQOpIxt85nwi1iO0cg0Q3yvNh8/twgdpr4O5 vHmZg4IthQMHyt0py8APRHbT8bkahp4yhsryUXdSyKHVADAyVlxPC6+GqNm5SdFlH57imxueS WgZ/zkQHmhR9pSe8TrCMV6Z2y710lug2OfMZPpIrBdcxQDsDpohikKtBKyp4qu6fiyUxn7KIV NRaxVGWbtUp4jKQqc/J+gwNapr9lHw+ES0+/1Pgv9UNBg5ohZCvmmBiasSSbDP69VOYvfs3k7 MI0G9XIHm1fTlGkCV/noMcqcgb5lcjY26byF1Orhlq4SadJHiTpXolJfTNrE=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/NlXu1pls5efIcihm443fXYAobKA>
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, 07 Nov 2019 21:04:22 -0000

Hi David,


> On Nov 7, 2019, at 22:00, Black, David <David.Black@dell.com> wrote:
> 
>>> BTW, just to avoid confusion, I'm reading your "strong +1" to be solely
>> about adding warnings/advice in case the "final SHOULD" is not implemented
>> (and similar, for other SHOULDs in the draft as well).   
> 
> That's correct.

	Regarding my point, what is the purpose of adding SHOULDs that for all means and purposes are impossible to see quantitatively implemented, even if the consequences are well discussed?

Sebastian


> 
> Thanks, --David
> 
>> -----Original Message-----
>> From: Sebastian Moeller <moeller0@gmx.de>
>> Sent: Thursday, November 7, 2019 3:53 PM
>> To: Greg White
>> Cc: Black, David; tsvwg IETF list
>> Subject: Re: [tsvwg] draft-ietf-tsvwg-nqb, more questions
>> 
>> 
>> [EXTERNAL EMAIL]
>> 
>> 
>> 
>>> On Nov 7, 2019, at 21:36, Greg White <g.white@CableLabs.com> wrote:
>>> 
>>> Noted, and I agree that it is important.  I'll write some appropriate warning
>> text.
>>> 
>>> BTW, just to avoid confusion, I'm reading your "strong +1" to be solely
>> about adding warnings/advice in case the "final SHOULD" is not implemented
>> (and similar, for other SHOULDs in the draft as well).   You also quoted some
>> text from Sebastian which was factually incorrect (that an AP complying with
>> the SHOULD is NQB aware).
>> 
>> 	[SM] Are you talking about:
>> 
>> "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."
>> 
>> in the context of non NQB-aware APs? How feasible di you think it will be to
>> expect all deployed APs to have the AC_VI EDCA parameters changed to
>> comply with this recommendations, especially in the light that almost no APs
>> actually offer to configure these parameters at all? Does it really make sense
>> to propose a SHOULD that is known to be almost impossible to actually
>> implement in virtually all existing APs?
>> I guess I must be misunderstanding you here, because the remedy for
>> (arguably) misusing a prioritization system can not really be "disable the
>> priority system", color me confuzed.
>> 
>> Best Regards
>> 	Sebastian
>> 
>> 
>>> I'm assuming you weren't "+1" on his conclusions from that, but correct me
>> if I'm wrong.
>>> 
>>> -Greg
>>> 
>>> 
>>> ´╗┐On 11/7/19, 1:02 PM, "Black, David" <David.Black@dell.com> wrote:
>>> 
>>>   I wanted to strongly +1 this portion of the discussion:
>>> 
>>>>> 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
>>>> applications 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.
>>> 
>>>   This is an example of a good thing to do with all uses of "SHOULD" - at
>> least warn about the risks and/or consequences of not following the
>> "SHOULD" (or "SHOULD NOT"), and (even better) provide some advice on
>> staying out of serious trouble in that case (as will be done here).
>>> 
>>>   Thanks!, --David
>>> 
>>>> -----Original Message-----
>>>> From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Sebastian Moeller
>>>> Sent: Tuesday, November 5, 2019 3:59 AM
>>>> To: Greg White
>>>> Cc: tsvwg IETF list
>>>> Subject: Re: [tsvwg] draft-ietf-tsvwg-nqb, more questions
>>>> 
>>>> 
>>>> [EXTERNAL EMAIL]
>>>> 
>>>> 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
>>>>> 
>>>>> 
>>> 
>>> 
>>> 
>