| Hi,
I agree with Frank that stream setup signaling should not be mandatory in order to use RTWT. - The STA can communicate basic application delay requirements by setting the RTWT parameters. - The AP MLD may do deep-packet-inspections and check the application address information to detect the application. The AP/network may have application specific scheduling rules
Requiring TSPEC transmission with RTWT will complicate the RTWT use. If RTWT only carries traffic that has been specially signaled with TSPEC, we may not use UL RU allocations very efficiently and STA may need to have complicated schemes to fetch the DL frames.
I agree that it is good first step to improve AP scheduling capabilities by offering static information on maximum delay bounds of the application by using TSPEC, etc. This benefits non-AP MLDs scheduling in active mode and in power save mode, i.e. operating is some TWT-variant. I think more dynamic scheduling information is needed to achieve good real time scheduling performance in practice. The current Buffer Status Report (BSR) is not suitable to communicate the time when AP should trigger a STA. The STA should have means to communicate the duration in which it should get a Trigger. Submission 20/1006r3 provides more details on these scheduling tools. Download
Cheers, Jarkko
Hi Frank, The negotiation procedure is already supported in legacy TWT signaling. I think it’s fine to reuse it. Since TSPEC or TSPEC lite IE proposed in 11be is not for ADDTS/DELTS, those IEs can be piggybacked in TWT Request frames. What do you think about that? Regards Boyce Hi, Chunyu, Regarding your response quoted as below, your intention is to decouple the TIDs allowed to transmit during the rTWT SP from the QoS signaling such as TSPEC? With the QoS signaling, AP can know the latency requirements of specific TIDs so that resource, such as rTWT SP, can be arranged accordingly. If we need other TID assignment protocols to negotiate which TIDs can be used during the rTWT SP, in addition to extra overhead and complexity, QoS signaling seems unnecessary. I don’t think it is a right direction. BRs, Frank Quote: One can choose a TID or TIDs not overlapping with these existing typical TID values, and tell AP these "unique" TID(s) that identify latency sensitive traffic. Exact policy and practice is not in 802.11 scope but we provide sufficient tools to do what's needed in order to work in 802.11 MAC context. P.S. there is no upper or lower TIDs per se (in preview some wording in Jarrko's comments) in rTWT context IMO. Either the selected TID(s) are marked as latency sensitive or they are not. Hi, Boyce: It's not clear how fairness issue is related to TID. The way I see how this can work out from MAC protocol support as well as network policy from deployment view is as follows: 1) STA or AP based on whatever knowledge it can obtain or instrumented by its upper layer (out of scope of 802.11 L1-2), decide for best of their own interest, the parameters in negotiating a rTWT agreement to be established. The DL/UL TIDs selection is based on their own need of traffic management. E.g. the STA is a laptop device running a video call + browser + email + file transfer. This laptop (based on user configuration and OS support) would like to use rTWT to support the video call while other traffic go through regular EDCA/MU-EDCA (non-rTWT agreement) service. This is, of course, with the well-known constraint or assumption that, if the network has unlimited bandwidth supporting all associated STAs and traffic stream without the need to differentiated QoS treatment the laptop would have no need to differentiate the treatment for its own traffic. Now the laptop knows that if it has to prioritize its own traffic, it needs a way to tell AP what traffic streams it wants to be treated differently. We are proposing to use TID inherently to how 802.11 MAC functions. For the "fairness" argument, I think you already agreed that differentiated QoS is "unfair" but we need to define "fairness" properly (weighted fairness can be also called fair or not fair depending on one's perspective). But this debate, at this point, defeats all the purpose of defining a mechanism to support realtime application that has stringent latency requirement. For the "abuse" point, it's more a network deployment/configuration problem and what we need to do in 802.11 is to provide sufficient tools to allow the network to configure accordingly. E.g. the AP can upbound the network resource, and in the rTWT context, it's the time, allocated to each STA during the setup procedure. Take home environment as one scenario, the homeowner can set, say, 60% time as the total amount of time as upper bound to its home devices for rTWT, and ensure remaining traffic has sufficient bandwidth even one family member is taking a very bandwidth-consuming 3D video call. Take the enterprise environment as another scenario, the IT can configure the network such that each STA can request only up to a certain amount of time and also constraint the total amount of time for rTWT SPs. IT can even get pre-known knowledge, e.g. laptop's MAC address/identification, to combine certain policies (out of 802.11 scope). As one can see, there are various ways to manage the "abuse" problem, and the rTWT and even baseline TWT already supports a negotiation procedure. 2) Choosing rTWT to operate at TID level works with overall how 802.11 MAC works in many aspects: the blockack agreement is established at TID level (head of fifo problem is a key element here and I cannot agree it's not "a big deal" as it is a big deal esp. one wants to benefit from aggregation), TSPEC describes traffic at TID level, packet classification as defined in SCS procedure allows packets filtered/mapped to TID level. I don't see why not TID. What would be the alternative. The overall flow it can work IMHO is that, through the QoS management that 802.11 supports (e.g. packet classification, SCS, and/or default DSCP to UP mapping), latency sensitive traffic gets mapped to selected TID(s). On a general computing device like a laptop, one can expect a lot of traffic like the browser etc. are already mapped to certain TID(s). One can choose a TID or TIDs not overlapping with these existing typical TID values, and tell AP these "unique" TID(s) that identify latency sensitive traffic. Exact policy and practice is not in 802.11 scope but we provide sufficient tools to do what's needed in order to work in 802.11 MAC context. P.S. there is no upper or lower TIDs per se (in preview some wording in Jarrko's comments) in rTWT context IMO. Either the selected TID(s) are marked as latency sensitive or they are not. Hi Chunyu, Thanks for the response. Some problems come into my mind if TID level is used. 1, [fairness and abuse issue] If a STA maps latency-sensitive and non-latency-sensitive traffic to the same TID, the STA is allowed to use rTWTs to transmit non-latency-sensitive traffics as well, due to the fifo block issue you mentioned (although I believe this is not a problem at all, most of designs of TID queues are software-based.). This is not fair to latency-sensitive traffics in other STAs, especially when the data volume of the non-latency-sensitive traffic is huge. For example, a “smart” STA can map buffered video to the same TID with latency-sensitive traffic. So the STA’s buffered video traffic would have higher priority than other STA’s buffered video traffic. The QoS of its own latency-sensitive traffic is not affected as long as the STA is able to handle the so-called “fifo-blocking” problem which is very simple. And latency-sensitive traffics from other STAs have to compete with the non-latency-sensitive traffic. 2, [resource allocation issue] The EHT AP has to allocate a lot of resources for the STA, if the data volume of latency-sensitive traffic is small and the data volume of non-latency-sensitive traffic mapping to the same TID is large. So I don’t think we should use TID level just because of head-of-fifo blocking problem(which is not a big deal for most of devices nowadays). Regards Boyce Boyce, Frank, Thanks for sharing your comments. Please see the attached document with some responses. There have been some questions/comments on the traffic requirement etc. and questions on TIDs' role here. We agree that STA may want to share the traffic characteristics and requirements with AP or even wants to change default packet classification (mapping) to TID. Those can be done using existing or extended tool(s) (TSPEC e.g.). I believe Duncan etc. have a contribution on TSPEC variant/lite, and Dibakar etc. have a contribution on SCS change. In this set up procedure, we focus on the general rTWT set up procedure, and that it operates at TID level inline with that the blockack agreement is established at TID level. Please note that there is a subclause 35.7.2.2 traffic classification/requirements are discussed. Hi, Jarkko: Since restricted TWT is intended to service latency sensitive traffic, we need a mechanism to provide the identification for such traffic streams. TID is the right level rTWT operates at to avoid problem such as head-of-fifo blocking. So in both DL and UL, the traffic transmitted during rTWT SPs is constrained to the TID(s) that AP/STA agreed on during the rTWT setup. Hi Chunyu, the R-TWT proposal has DL TID and UL TID bitmaps. I am wondering how these are used? - In DL why would AP limit the TIDs it is allowed to transmits to the STA? - In UL can STA transmit from other TIDs than signaled here? <image001.png> Thanks for the updated contribution. I add my comments after Boyce’s doc. Thank for the updated contribution. I have some further comments, please find them in the attached. Thank you for the perfect contribution! I added my comments in the attached file. BR, Xiangxin Unisoc Technologies Co., Ltd. +86 21 20360600 3324 Thank you so much for this contribution. You have drafted an excellent spec text. In addition to Stephane’s and Rojan’s comments, please find the attached document for my comments on your draft. Have a wonderful weekend! Thanks all for your feedback. Please see the updated rev1: 11-21/462r1 on server: Stephane, Rojan, please see attached document for responses to your comments inline.
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 <11-21-0462-01-00be-pdt-mac-restricted-twt-tbds-crs-part1-Boyce-Frank.docx>
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
|