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