Re: [STDS-802-11-TGBE] Clarifications on QoS management contribution (41

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

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

From: Thomas Derham <00000ad2eabc2931-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Saturday, June 27, 2020 10:32 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Clarifications on QoS management contribution (418r3)

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

Thanks

Thomas

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

From: Cavalcanti, Dave <dave.cavalcanti@xxxxxxxxx>
Sent: 2020年6月27日 1:21
To: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: Clarifications on QoS management contribution (418r3)

Hi Jay Yang,

Thanks for the questions. Please see my responses in line.

Best,

Dave

From: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>
Sent: Thursday, June 25, 2020 11:32 PM
To: Cavalcanti, Dave <dave.cavalcanti@xxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: Clarifications on QoS management contribution (418r3)

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

From: Cavalcanti, Dave <dave.cavalcanti@xxxxxxxxx>
Sent: 2020年6月26日 5:19
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [Suspected Marketing Mail] [STDS-802-11-TGBE] Clarifications on QoS management contribution (418r3)

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