| Hi, Boyce:
Fixing at one or a subset of TIDs as latency sensitive traffic is not 802.11 best fit / scope IMHO. 802.11 has provided a broad set of tools (TCLAS, TSPEC, Intra-Access Category Priority element, QoS Map element etc.) to allow 802.11 serve upper layer’s traffic in a flexible/configurable way.
But let’s go back to the current draft discussion and see if we can reach common ground to make progress.
In searching of better word to best reflect various feedback I received, or in failing to do so within limited detail level and time, I removed the paragraph about “data frame exchanges …” and leave the blank (TBD) for next run of comment resolution.
Will upload a new revision shortly for review.
Thanks. Chunyu
Hi Jarkko, Thanks for sharing your thoughts. I think this is a really good topic to discuss. A tightly related issue is how low latency traffics are mapped to TIDs. There are two options. Option1, we define the rules explicitly in spec. for example, 11be choose one or a set of TIDs to be low latency TIDs. So AP would know which TID is for low latency traffic. Option2, each non-AP maps low latency traffic to any TID according to its own preference(I think that is Chunyu’s preferred option so she put a TID bitmap in the rTWT request IE). In this case, the AP does not know which TID is for low latency traffic beforehand. So the mapping rules are needed for each rTWT request. Actually, there are a lot of similar issues that has more than one options. Maybe we should try to summarize them and run SPs in the group first, so we can reach consensus on background knowledge. Regards Boyce Hi Chunyu, all, thank you for the new version. The current wording on TIDs to prioritize during the rTWT SP is very strict and causes unnecessary limitations. I want to open a discussion on the UL and DL TID use with retracted TWT. Would you help me understand the following points? 1) Would AP be the one that determine the TID/rTWT mapping for both UL and DL? - If so, I don’t see the point for AP to signal the TID/rTWT mapping for DL, because it is up to AP to determine when to send which TIDs for DL.
2) If 1) is true, the TID/rTWT mapping is essentially only effective to UL. - Fo UL, if MU-EDCA is used, a non-AP STA would always wait for UL-OFDMA trigger from AP. So it is still up to AP to decide when to trigger which TIDs for UL. Therefore, I don’t see why an AP need to signal the TID/rTWT mapping for triggered based UL.
3) If both 1) and 2) are true, the TID/rTWT mapping is only effective to EDCA UL. - Again, if MU-EDCA is used, a non-AP STA can use EDCA for UL only if it is not triggered for a very long time. For this case, there is obviously something wrong at the AP side, so there is no point for the non-AP STA to continue following AP’s instruction.
In general, I feel that 11ax already provides good tools to enable AP to have better control of medium access and prioritize low latency traffic for both UL and DL. If an AP can do its job right, it does not need to add any new rules to rTWT medium access. If an AP can not do a good job, adding these new rules would make the situation worse.
Hi, all: A new revision r7 is uploaded to the server: Main change(s) to previous rev: some further polishing of text in Table 9-299a. Please review and share your comments. Chunyu
From: Chunyu Hu <chunyuhu07@xxxxxxxxx>
Sent: Monday, May 10, 2021 8:53 PM
To: Rubayet Shafin/Next-G Mobile /SRA/Engineer/Samsung Electronics <r.shafin@xxxxxxxxxxx>
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] [STDS-802-11-TGBE] Request feedback for TBD/CR in the Restricted TWT setup subclause More details such as additional cases to cover are to be developed in D1.0 (not R2 per se). Sure, I am okay with deferring this issue to R2. Regarding the text you quoted: this sentence reads to me that this is only in the parlance of what kind of data frames can be exchanged during rTWT SP. To be more explicit, I think it would be better to add a sentence like this: “Restricted TWT scheduling AP’s and restricted TWT scheduled STAs’ behaviors, in the context of ensuring proper channel utilization and fairness among the members of restricted TWT SP, are subject to the rules described in 35.7 (Restricted TWT)”. From: Chunyu Hu <chunyuhu07@xxxxxxxxx>
Sent: Monday, May 10, 2021 6:03 PM
To: Rubayet Shafin/Next-G Mobile /SRA/Engineer/Samsung Electronics <r.shafin@xxxxxxxxxxx>
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] [STDS-802-11-TGBE] Request feedback for TBD/CR in the Restricted TWT setup subclause Thanks for providing this summary. It's pretty good spelling out some key factors that people are debating on/offline. While some flexibility is needed and people are willing to have those flexibilities, the details would require a lot of time to settle on. I want to have a phrase general enough to clearly indicate more details are TBD (but without "TBD" :)). What do you think of the following text: "Data frame exchanges during a restricted TWT SP between the TWT scheduling AP and restricted TWT scheduled STAs are restricted to those frame exchanges that deliver latency sensitive traffic described in 35.7.2 (Restricted TWT agreement setup), subject to the rules described in 35.7 (Restricted TWT)." Hi Chunyu, Thank you for the updated text. I think the document, in its current form, leaves room to raise channel under-utilization and fairness issues. I briefly mentioned this tradeoff during last conference call and summarizing the problem here again: Channel Under-utilization issue: During restricted TWT SP, it is possible that a scheduled STA, member of the restricted TWT schedule, finishes transmitting latency-sensitive traffic earlier than the restricted TWT SP end time. This leaves underutilized restricted TWT SP for that STA (if DL buffer for latency-sensitive traffic is also empty for that STA). Rise of fairness issue: Channel under-utilization due to under-utilized restricted TWT SP can be reduced by allowing latency-tolerant traffic in addition to latency-sensitive traffic for transmission during rTWT SP. - Once the scheduled STA is done transmitting latency-sensitive traffic during rTWT SP, and if there is still time remaining in the SP, the scheduled STA can choose to transmit its latency-tolerant packets (if any) during remaining of the SP.
- This will improve the channel utilization for the STA
However, it creates fairness issue-- - Regarding contention among the scheduled STAs, if one scheduled STA starts transmitting latency-tolerant traffic during the restricted TWT SP, it is not fair for other scheduled STAs that are still transmitting latency-sensitive traffic during the SP.
- Also, an STA with ill intention may abuse this functionality by setting up TWT parameters such that there is always additional time left in the restricted TWT SP after transmitting latency-sensitive packets.
So there is clearly a tradeoff between these two, and a balance needs to be ensured. I think a fair and balanced outcome would be like this—if an rTWT scheduled STA is done with transmitting latency-sensitive traffic earlier than rTWT SP end time, and if downlink buffer for the STA is also empty, then the scheduling AP can terminate the rTWT SP for that particular scheduled STA. This way that STA can transmit latency-tolerant traffic (if any) by competing with other STAs that are not members of the rTWT SP, and hence improve its channel utilization. This would also be fair for other rTWT member STAs since they still maintain priority for latency-sensitive traffic during remaining period of the rTWT SP. I think your document needs to provide this guidance on the issue. Best Rubayet From: Chunyu Hu <chunyuhu07@xxxxxxxxx>
Sent: Monday, May 10, 2021 5:39 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] [STDS-802-11-TGBE] Request feedback for TBD/CR in the Restricted TWT setup subclause I certainly hope the assumed behavior is not the common and practical case -- it'll practically make any "reserved" field or value in MAC frame unusable. If we choose this option, b. use value 4 of the Broadcast TWT Recommendation field as the restricted TWT identifier. Because the Broadcast TWT Recommendation field contains just a recommendation, a behavior of the unknown recommendation value is not specified in the spec. This is different with type/subtype field. Some 11ax STA may not support any the Broadcast TWT Recommendation field. So, 11ax STA may misrecognize the restricted TWT as the broadcast TWT. Then, 11ax STA will try to set up the membership for the corresponding misrecognized broadcast TWT. Such a membership request is always rejected by 11be AP. I don't like to allow this abnormal case. Please review the updated revision: Highlight -- leaving the items that need more discussions to later time: 1) updated Table 9-299a text. 2) removed the p2p bit definition I am not sure whether EDCA is relevant for rTWT. I think individual TWT may be more suitable to operate with EDCA. - Can you give an example when you would operate rTWT with EDCA? If a STA wants to use EDCA in rTWT, then are you saying that other devices and OBSS can transmit EDCA on all ACs, but the STA having the rTWT is allowed to transmit traffic on high TIDs only? - What would be the benefit of using rTWT with EDCA? If AP sets up a r-TWT SP for a STA with low latency traffic and the STA uses it to txmit mostly non-low latency traffic using EDCA, that would affect AP’s ability to manage the r-TWT SP and balance QoS requirements for other STAs. Thank you for your discussion on rTWT traffic in the 802.11be call today. I think there were many comments on this text: I am proposing the following text to solve the comments: - These limitations should be applied only for rTWT traffic. Other traffic should not be limited buy the rTWT traffic limitations. - The QoS violations and traffic scheduling is totally AP’s business for rTWT traffic and other traffic. I believe APs try to schedule only high priority traffic during rTWT SPs, but the scheduling is just very hard to implement in practice. - Clarification for management and control frames delivery. We can continue to improve the text in the coming letter ballots. I have different opinion. However I agree with Patrice’s view in another mail. The rTWT SP should be only used for RTA traffic to keep fairness for every STA, which also make sure that RTA traffic can be guaranteed to be transmitted with priority. The question raised by Patrice, how to avoid abuses of the rTWT SP, I guess this can be made by test cases. BR, Xiangxin Unisoc Technologies Co., Ltd. +86 21 20360600 3324 my name was mentioned, so let me clarify. Yes, Chunyu has done good work on rTWT proposal. The current wording is better, but the allowed traffic in rTWT could be written more clearly. The submission is currently missing this principle: 1. High TID traffic should be transmitted first in rTWT SP. 2. If rTWT SP has time remaining after all high TID traffic is transmitted, then STA and AP could send lower priority traffic in the remainder of the rTWT SP. I would be very happy 😊 if these sentences could be added. I agree that rTWT rules need not be complete in 1.0. We can continue to improve them. I understand you intention. I think it is fine to narrow down the discussion of technical details and focus on what can be done before D1.0 timeline. Since there are some explicit scenarios that have been proposed(Delayed response, Broadcast, data rate fluctuation), you should at least leave some room for next step improvement. Thanks for the comments and on/offline discussions. My understanding of the scenario you described is that it seems to be an extended or enhanced usage of the restricted TWT, and is not precluded by the basic setup procedure described in the proposed text. Extending the setup procedure in a broadcast fashion needs more discussion probably. In spirit of converging on the current draft text scope within the D1.0 timeline and making process, I hope to have your agreement and support that we discuss further enhancement at a later time in form of CIDs or technical contributions. My thinking is that a STA is allowed to negotiate membership 1:1, but sometimes the signaling overhead is a problem(at least two negotiation signaling MMPDUs for each traffic/STA), especially the network is congested. Since bTWT can announce available TWTs in broadcast manner, we can further allow an AP to announce allocation results to multiple traffics/STAs as well(i.e. unicast rTWT requests by non-AP, broadcast rTWT response by AP). It’s useful in a scenario as follows -latency-sensitive traffics arrive when network quality is good (i.e. no need to allocate rTWTs resources) -STAs send QoS requirements(e.g. TWT request without asking for response, TSPEC can be piggybacked) to the AP. By that, The AP can know how many STAs have latency-sensitive traffic and their QoS requirement. -when network quality is getting worse -The AP can allocate rTWTs for multiple STAs with one TWT IE (no need to wait for rTWT request). Of course, one basic assumption is that, the AP should not allocate rTWT resources if network quality is good enough. The reason is 1, The channel access time is fragmented. Channel usage is less efficient. 2, Latency-sensitive traffic can be sent outside rTWT period, and most of rTWTs will be left unused. Why do you say “signaling overhead of negotiating rTWTs can be reduced by the broadcast feature." ? A STA still negotiates membership in the Broadcast TWT 1:1, right ? From: Yangbo (Boyce, 2012 NT Lab) <yangbo59@xxxxxxxxxx>
Sent: Wednesday, April 28, 2021 2:32 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] [STDS-802-11-TGBE] Request feedback for TBD/CR in the Restricted TWT setup subclause Thanks for the response and updated document. I see your point, unicast. But one important reason why we choose bTWT as a baseline is that the signaling overhead of negotiating rTWTs can be reduced by the broadcast feature. I think we should make full use of that. So I suggest to add AID subfields in Broadcast TWT Parameter Set field, so that an AP can allocate resources for multiple STAs. I also add some comments in your updated doc, please find it in attached. Re. your second question, the rTWT is not limited to SU. Each STA can set up an agreement on a schedule with AP. This doesn't prevent AP or STA to use the same schedule for multiple agreements {e.g. AP with STA-A, AP with STA-B}. With the MU tx/rx capabilities, sharing a SP can certainly boost the spectrum/network efficiency and is supported by this signaling. What the draft text describes is that the rTWT Parameter Set field with the Restricted TWT Traffic Info field included is meant for the STA (either non-AP or AP STA) to share their traffic info during the agreement establishment and hence it's a frame exchange between themselves ... hence unicast. Hope that's clear. On your comment of TSPEC or its variant/lite version understand, yes, I think it'll be good to use it during or before the rTWT setup to provide traffic characteristics and qos requirements. To-be-done subclause 35.7.2.2 should cover it. 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? 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. 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. 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. 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). 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. 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. 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. Thank you for initiating the review on this document. In addition to Rojan’s comments, please in the attached document my comments on this subject. Thanks for preparing the CR. Please see attached for my comments. Will you review and provide your feedback to this draft text that resolves some TBD/CID?
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
|