Hi Chunyu,
Perhaps I’m not understanding your end-to-end connection question correctly, but I assume that TIDs are used to differentiate traffic streams in the .11 MAC. Higher layer protocols would have to be used to ensure QoS end to end, but that
would be outside the scope of .11.
Furthermore, the new TIDs proposal would only apply to .11be. The new TIDs would enable further classification and prioritization over .11be. If the same flow is transmitted over 11ax, it would have to use whatever classification is available
in .11ax.
I understand there may be more complex E2E QoS issues, but the scope of the proposal was to enable better QoS over .11be.
Thanks
Dave
From: Chunyu Hu <chunyuhu07@xxxxxxxxx>
Sent: Sunday, June 28, 2020 1:37 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Clarifications on QoS management contribution (418r3)
Dave, how do you envision an end-to-end connection that has some segments of ethernet and multiple
segments of wifi links (some are 11ax, some are 11be e.g.) handles the new TIDs proposal?
Sharing my thoughts on the AC/queue:
[Thomas] >> - I suggest we focus on exactly *how* the MAC is expected to treat these packets, and
then later figure out the best way to indicate that treatment.
>> [CG] Based on my response above on defining new access policies, it might not be sufficient to
define MAC mechanism to classify packets per non-AP MLD, but manage QoS across a subset of non-AP MLDs.
[Chunyu:] I also see it's necessary to figure out an effective mechanism in MAC to serve these packets with latency requirements; and see what exact is missing /best filtering mechanism to identify these packets (or traffic streams or applications
or even an operation mode/state). This can avoid redundancy and better address scalability (not just yet another AC or queue -- keep in mind time based multiplexing is yet another way.)
Hi Thomas,
Thanks for sharing your insights again! Please see my response in
green font in
line below.
Thanks,
Chitto
Thanks for the feedback and good discussion. A couple of follow-up comments as follows:
- Yes agree there are multiple 802.11 mechanisms that influence how the upper layers set the metadata parameters
in MA-UNITDATA.request when they send an MSDU to the MAC for transmission. One of those is based on DSCP mapping; others include rules based on TCLAS classifiers (e.g. matching fields in IP header, or MAC addresses, VLAN tags, etc) that do not consider DSCP
[CG] Agreed;
- The “priority” parameter in the MA-UNITDATA.request determines the TID/UP, however there are other parameters
in that primitive (e.g. Drop Eligibility) which can determine other aspects of how the MAC treats the packet. It is quite possible to add new metadata parameters, and/or extend interpretation of existing parameters, to indicate how a packet should be treated
–
[CG] In my opinion, we would need new metadata parameters, as you have suggested for packet description and classification. In addition, as I have mentioned
in my previous email, “In addition, the classification of MSDUs could be device-centric (between a non-AP MLD and AP MLD) or valid for the entire network (advertised by the AP MLD advertises
for a specific stream),” we might have to define new access policies for network-centric QoS management. For example, in an enterprise scenario (conference room/hall) with multiple VR HMDs, it might be efficient to broadcast (network-centric)
QoS policies for a subset of devices (acting as non-AP MLDs) within a BSS, as opposed to individual packet-level classification or individual QoS negotiation frame exchanges.
we are not only limited to using TID values, and indeed based on the description it seems to me they are not the
right tool for this purpose (especially if they are hard-coded to ACs).
[CG] Hard-coding TIDs to ACs is not within the scope of our contribution. Addition of TIDs 8-15 to the AC-VO was used for illustration purpose.
- I suggest we focus on exactly *how* the MAC is expected to treat these packets, and then later figure out the
best way to indicate that treatment.
[CG] Based on my response above on defining new access policies, it might not be sufficient to define
MAC mechanism to classify packets per non-AP MLD, but manage QoS across a subset of non-AP MLDs.
It sounds like your intention is not to introduce additional ACs, but potentially to add more transmit queues.
I think the impact of HOL blocking depends on the queuing discipline across the stack, not just the number of EDCA queues (e.g. AP implementations handle airtime fairness across multiple STAs, and prioritize certain traffic for those STAs, without the standard
defining separate EDCA queues for each). Integration of queue management with (MU) scheduling disciplines and/or other TDMA-related features (e.g. TWT) sounds like another objective, again this seems to be something that requires more sophisticated negotiation
and indication than simply mapping to one of 8 TID values.
[CG] Designing queue management seems to be a promising direction, but 802.11 specification might allow limited opportunity due to its inherent coupling
with implementation-specific algorithm design.
On June 27, 2020 at 4:01:58 PM, Ghosh, Chittabrata (chittabrata.ghosh@xxxxxxxxx)
wrote:
Hi Thomas,
Thank you for your detailed comments. Let me chip in here and Dave can fill in his thoughts;
The 802.11 specification allows a packet entering from a network at the host to be filtered based on pre-defined
DSCP-UP mapping (in QoS Map element) and further queued based on UP-to-AC/TID mapping. As illustrated in this contribution, new applications with strict latency and jitter requirements (over traditional VO/VI delivery requirements) need special filtering or
marking as opposed to the conventional applications mapped to the 8 UP values (0-7), that are in turn classified into one of the four ACs. If distinct filtering is not defined, adverse scenarios might evolve, wherein single/multiple VO/VI packet(s) might be
queued in front of a packet with low latency requirement. This mode of queuing might result in unacceptable head-of-line (HOL) delay, leading to negative user experience. Moreover, as Dave mentioned below, 2 TIDs per AC might be insufficient to cater to the
granular needs of key performance indicators of packets classified within same type of application.
For differentiated QoS management of new applications with granular requirements of latency or jitter (over conventional
VO/VI requirements), in this proposal, we propose a tiered (tier represents the processing of an MSDU either at the host, or at MAC interface, or in a transmit queue) approach as you have identified rightly as “concepts” in your email. In essence, filtering
(mostly in-device and not OTA) of MSDUs at the host might be identified by stream indices, as you mentioned, in Tier 1, followed by classification and characterization in Tier 2 (using QoS negotiation and traffic classification with TIDs 8-15), and dedicated/negotiated
service periods for non-AP MLDs in order to cater to latency and jitter requirements. In addition, the classification of MSDUs could be device-centric (between a non-AP MLD and AP MLD) or valid for the entire network (advertised by the AP MLD advertises for
a specific stream).
Please let us know if you have additional comments.
Thanks,
Chitto
>> I hope there is a clear definition to indicate which TIDs map to which ACs
If that is the intention, I’d like to see some more explanation why it is needed.
In baseline, TID subfield values 0 thru 7 indicate the UP, and there are only 8 UPs .
TID subfield values 8 thru 15 indicate TSIDs, and each TS can be assigned any UP/AC depending on the negotiation
of that TS (e.g. using ADDTS Request, SCS Request, etc).
What would be the purpose of hard-code assigning more TID subfield values to the same set of UPs/ACs? If anything,
that would seem a regression compare to the current support for dynamic negotiation of UP/AC for those TID values.
It seems there are a few different concepts here, which can be considered separately:
- some index of a stream that is used as reference for stream management, e.g. setup, teardown, QoS assignment
etc. With ADDTS mechanism this is a (effectively 3-bit) TSID, but (for example) with SCS it is a 1-octet SCSID
- some classifier of packets that constitute a given stream, e.g. (partial) IP-tuple defined in a TCLAS element
- some (ancillary) information, e.g. TSPEC-style, about the traffic characteristics of packets classified in a
given stream
In general, the stream index does not need to be signaled over-the-air, since both peers know the classifier (for
example in SCS, the TID subfield contains the UP the stream is using).
Further, generally the receiver doesn’t care much about what stream or AC the packet was sent in anyway (if anything,
its upstream QoS treatment would depend on marking in the MSDU payload such as DSCP), and in cases where QoS is negotiated it can figure it out because it knows the classifier.
It may well be that, to support 11be use cases, we need to define new classifier types, traffic characteristic
parameters, signaling/negotiation, queues, etc. However I would like to see system-level description of gaps and potential solutions, before we commit to arbitrary changes to interpretation of existing signaling.
On June 27, 2020 at 6:48:18 AM, Yang, Zhijie (NSB - CN/Shanghai) (zhijie.yang@xxxxxxxxxxxxxxx)
wrote:
Hi Dave,
Thanks for your explanation. For your SP, I hope there is a clear definition to indicate which TIDs map to which
ACs, e.g. TID(8,9,10,11) àAC_VI, TID(12,13,14,15)àAC_VO.
On the other hand, I’m afraid the true result may be not as good as expected if reuse current ACs, especially in
mixture streams scenario on AP side.
The new stream(LLRS ) may cause higher latency issue on current stream if it occupies too much TXOP. And AC_VO
is allocated with a smaller HW buffer for low latency and low traffic purpose, it’s not suitable for huge traffic transmission, such as AR/VR stream. In my opinion, there are many limitations on current ACs so it is not suitable for LLRS stream. Therefore,
I prefer to define a new ACs mechanism for them.
Thanks
Best Regards
Jay Yang
Hi Jay Yang,
Thanks for the questions. Please see my responses in line.
Best,
Dave
Hi Dave,
It’s good to re-use TID8-15 for the new coming flow in the further. I have some question on your presentation.
-
How do you consider the EDCA ACs on TID8-15? Do you want to reuse current AC mechanisms(BE,BK,VI,VO) or create a new AC mechanisms(BE,BK,VI,VO,LLRS1,LLRS2…)? For the latter option, how many ACs
do you want to create to map TID8-15? And what’s the new AC parameter and rules?
[DC] As we indicated in the SP and shown in the example in slide 12, the traffic streams using TIDs 8 – 15 can be mapped to the existing ACs. The new QoS parameters associated to these TIDs can
be used to prioritize the data when mapped to some of the existing ACs. The topic of creating new AC is beyond the scope of this contribution, it could be considered in the future, but we’re trying to focus on the basic changes required in R1 at this point.
-
In Slide16,(simulation scenario1), what’s the meaning of “protected windows”?
[DC] The simulation tries to illustrate what could be done if the low latency traffic can be classified (even if it is mapped to existing AC_VO). By knowing the traffic requirements of the low
latency streams, the AP could define periods of time during which the low latency traffic is prioritized. The protected window in this example is a period of time that only low latency data streams are transmitted. It is just one example to illustrate what
could be done once the traffic in classified and traffic profile information is provided through the QoS mechanism.
Thanks
Best Regards
Jay Yang
All,
Since we were not able to cover all the questions during the discussion in MAC call earlier this week, we have
uploaded a revision (418r3) with a few clarifications (see new slides 9, 10, 11). We have also updated the proposed SP#1 as follows:
-
Do you support defining a QoS mechanism so that the AP MLD and non-AP MLD can:
-
Announce new QoS capabilities (for LLRS) of the MLD
-
Provide traffic stream QoS description to enable classification across the MLD
-
Use TIDs 8 - 15 to indicate a new class of QoS data streams (e.g. LLRS streams) mapped to EDCA ACs with associated QoS parameters (as defined in item 2.)
-
Note: the TID values are signaled in the QoS Control field of corresponding Data frames
-
Note: if an AP is not part of an AP MLD (legacy AP), the same mechanism would be used between the AP and a non-AP STA
Additional considerations:
-
There is a need to enable differentiation for more than 2 traffic streams per access category (limitation in the current spec). For instance, voice, gaming, AV/VR, control/automation streams
in a single device/AP will need differentiation beyond VO and VI traffic classes. See limitations in existing mechanisms in slides 9 and 10.
-
The re-use of TIDs 8 to 15 to identify traffic streams will enable the prioritization based on new metrics (e.g. latency bound, jitter, reliability) and can be dynamically mapped to ACs
-
HCCA, ADDTS, TSPEC provide QoS negotiation, but they are unlikely to be implemented as defined in the current spec. We propose a simplified QoS negotiation approach in the context of 11be that
also incorporates/leverages MLO and enables traffic stream differentiation with the typical EDCA implementations.
Hopefully, this helps address some of the questions, but we welcome any further discussion.
Thanks,
Dave
-----------------------------------------------------------
Dave Cavalcanti, PhD
Principal Engineer
Wireless Communications Research, Intel Labs
Intel Corporation
dave.cavalcanti@xxxxxxxxx
To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1
|