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

Sebastian Moeller <moeller0@gmx.de> Thu, 07 November 2019 23:25 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 B198E1200B1 for <tsvwg@ietfa.amsl.com>; Thu, 7 Nov 2019 15:25:10 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 qD4PIyLOxrCu for <tsvwg@ietfa.amsl.com>; Thu, 7 Nov 2019 15:25:07 -0800 (PST)
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 07A1C12002F for <tsvwg@ietf.org>; Thu, 7 Nov 2019 15:25:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1573169097; bh=YHrzMOhf7YHqLABK4QSxM6pNFpbTqk4WbwbYwnVQWT8=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=YObU7fjH+cr9cobCjKTpa0a1Pb6XYWMXx/jn130fQ5YX28pEQ6Foe6xdFN2rFVEVV /AAQ5EdAG3irMAfRL3EnM7RRY+QfSa+h12HRaNQvOhrfdJwN9lm0i8qGSuVUjji58L 7w3+AyQbKaHKsrCRnBOCWpvlCezYLQXxBaXLIbs8=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([77.6.79.205]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MVvL5-1iJGE0265d-00Rq18; Fri, 08 Nov 2019 00:24:57 +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: Fri, 8 Nov 2019 00:24:55 +0100
Cc: Greg White <g.white@CableLabs.com>, tsvwg IETF list <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B245975C-5173-4C1D-881A-9C1077BB448E@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:gKGypG6jknsxxxw+KVQIhX5Sg3Gq7mwdpkjENQNDycNw10ukUVp 1yXfEUh2nDr3S1HZ710fCQoC97cWXdOC9I/cdwTRprhqdyvheazH0QGPOUOMBiAWp4SZT5P 1Qn+QAisvKPqfVzJK23raht2IeBGLmSejEDwEcWZKginK2mdwPdDZjajNCBOFtyIc6XW6Pq 6Yhz5m+xV45UyQIYtUjbw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:kT+8e2mhG/Q=:bEJNoZs+G1UkdXu0aIUBr2 XZxPpBReSz4kOCMgPt8Xp3lnaVr9LBvZcoTP6GNGtwYnktS39hV/UDzPs8Ft190j2m31nQM2n aHbd706QfG8uYzT/cKl5qFfEncgbgRIJi4hMkKCXxGtWvicY2ZlebMTp/7tDVvevhhdsXESly vBFruX08vDgbsGddrPmV3DW1Q2/iYZZhFJE//gd2OcwTPGwRR5n4vk3pPdRvd1R7wrdGmH50z jTLu5Ban5t/NHicz3ZolXGQGK2VbgxgmwXInXyt1Gbfrb1uXOUtxwt4htdfhnhiAHswVhgmuG bVkmMzhzuSPrnFmqWHSDFGzr2Q2KQC6gSmGnGlBL5dB157l5N/ViftRkxz59VMSFNPfD8eYPG dYznu14kiUIRCEusXgH482WQvudHpYgSBOMn8eqMgzfqib4RcRERLlTRbL38Tl3sc4J52MIy5 /jgkFORv+r3lHRFVPZuPYOYRa2Px9DeedrSwM9jMkj6Z+40QZ5b2QCyMLVFcvmJzPgm7S7MQH N9mDB6kvAwpgfPG7ku103ZG4/ymcK1zzGY0vzPIaEq0UVpoZMqTx1seexq2NF3X4OHsMKaAZ4 Q488Rqc2lt7IYbtXe18ShGHSCjlWG2/twkjwkbQXUtcjzZcNKjjodlfSwMALhmaOw7qayU1A4 KrDKDXtVJVFK1IxT+utwUP1q2ul5CB7wnhNqebZ3zsJwt6Duj2ttZXIqIdZDdoWTRoYcSV3B4 1FjccgKWTSZhNbWtrFyaIFtSBUNHRqJ8ew5PDkTjiwsIZvt184/IGnRX+jApMHD+F2rTg6RbE EHPepYdoqhr8XpTns0aXOKDvyIiX2xzA5l7lFWz0q4nW5zPbXoHnMy/6FlqJ00vLBb6n5DVvZ 0UephSkOnUfwfBIVpP+oAxZ4UggAu7Eklip+CkW2Kv98YdI0WM3yCD46hyx6wRkbjug5kJcD7 iozqDG+NskBwQUsMMnsNiRCz6tsfR9nw8EIfnksiqxrZb7p9zwKUP6roQsLfGEKEI4qJGGM4Q XsMrn/pTbsn0lux9rg2ToBHxpVccsJhsXyhyG2+2BpWwg4a4ce/DIGGi1eRQklATxIBzlRKVB AsSWbPbmPalQFvgN5v8FOqxtKOINaJswUWMW2gCFRwV8B1GqTOCFqlLQEA7JroCxYVPgDd0SH h5/To2zYbW9cyPpj1cAKGH57tmcCDJLeaQ5zBbV81pvr3mu/HyTNsQ1J7wEAiZQTrYuuPTiTq wDbr9iDrhyibVTsQREofxkbrgfyGzuXcjndl9JAwcTvuig2X1FROQaEYfdbxFKIIwaacYqjfc vh4+21pPNmEJ72/hsHPY7AoUsr6T9w/rDt5hZyUUDq1caDYiCu9i7nH7nHcab1m6vS6gJKjUz HAmaR1J1p2Wayg7Z1ciiv0Uew8xk/DMjl5VNCA5pCq33BllIh37kgeLPv7GJptje++7fe1uSj bZm0qHYDRS5W5KF4ejdw6Dh9ZmzgCwA3nxuw+492UzsrwxSgeJiF2XfwJwDCY/z7bgbrbpYt8 Ybg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/TTt-4iJ13_T2dgmiRWLdlxmkjeY>
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 23:25:11 -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.

	[SM] Here is an attempt at doing this for the last paragraph in the wifi section:

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. 

Not doing this risks that sufficiently high rate NQB traffic completely starves out normal traffic in the AC_BE queue. Doing this on the other hand will violate the traffic prioritization that rfc8325-compliant applications might expect from using dscp's that normally map into the AC_VI priority queue.


Question, does it really make sense to refer to rfc8325 and then to recommend to basically invalidate that RFC's assumptions?


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