Hi Dibakar and all,
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.
Regards
Boyce
发件人: Das, Dibakar [mailto:dibakar.das@xxxxxxxxx]
发送时间: 2021年4月28日
21:23
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE] [STDS-802-11-TGBE] Request feedback for TBD/CR in the Restricted TWT setup subclause
Hi Boyce,
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 ?
Regards,
Dibakar
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
Hi Chunyu,
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.
Regards
Boyce
发件人: Chunyu Hu [mailto:chunyuhu07@xxxxxxxxx]
发送时间: 2021年4月27日
23:31
收件人: Yangbo (Boyce, 2012 NT Lab) <yangbo59@xxxxxxxxxx>
抄送:
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE] [STDS-802-11-TGBE] Request feedback for TBD/CR in the Restricted TWT setup subclause
Hi, Boyce:
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.
Thanks.
Chunyu
On Tue, Apr 27, 2021 at 5:42 AM Yangbo (Boyce, 2012 NT Lab) <yangbo59@xxxxxxxxxx> wrote:
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
发件人: Frank Hsu (徐建芳) [mailto:frank.hsu@xxxxxxxxxxxx]
发送时间: 2021年4月27日 14:55
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] [STDS-802-11-TGBE] Request feedback for TBD/CR in the Restricted TWT setup subclause
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.
From: Chunyu Hu [mailto:chunyuhu07@xxxxxxxxx]
Sent: Tuesday, April 27, 2021 12:40 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [STDS-802-11-TGBE] Request feedback for TBD/CR in the Restricted TWT setup subclause
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.
Thanks.
Chunyu
On Mon, Apr 26, 2021 at 7:16 PM Yangbo (Boyce, 2012 NT Lab) <yangbo59@xxxxxxxxxx> wrote:
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
发件人: Chunyu Hu [mailto:chunyuhu07@xxxxxxxxx]
发送时间: 2021年4月27日 6:13
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] [STDS-802-11-TGBE] Request feedback for TBD/CR in the Restricted TWT setup subclause
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.
Thanks.
Chunyu
On Mon, Apr 26, 2021 at 12:02 PM Chunyu Hu <chunyuhu07@xxxxxxxxx> wrote:
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.
Thanks.
Chunyu
On Mon, Apr 26, 2021 at 11:12 AM Jarkko Kneckt <00000d5619618f4f-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
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?
Cheers,
Jarkko
On Apr 26, 2021, at 01:34, Frank Hsu (徐建芳) <frank.hsu@xxxxxxxxxxxx> wrote:
Hi, Chunyu,
Thanks for the updated contribution. I add my comments after Boyce’s doc.
BRs,
Frank
From: Yangbo (Boyce, 2012 NT Lab) [mailto:yangbo59@xxxxxxxxxx]
Sent: Monday, April 26, 2021 11:45 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Request feedback for TBD/CR in the Restricted TWT setup subclause
Hi Chunyu,
Thank for the updated contribution. I have some further comments, please find them in the attached.
Regards
Boyce
发件人: 顾祥新 (Xiangxin Gu) [mailto:Xiangxin.Gu@xxxxxxxxxx]
发送时间: 2021年4月25日 17:28
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] Request feedback for TBD/CR in the Restricted TWT setup subclause
Hi Chunyu,
Thank you for the perfect contribution!
I added my comments in the attached file.
BR,
Xiangxin
Unisoc Technologies Co., Ltd.
+86 21 20360600 3324
From: Rubayet Shafin <r.shafin@xxxxxxxxxxx>
Sent: Saturday, April 24, 2021 2:42 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Request feedback for TBD/CR in the Restricted TWT setup subclause
Hi Chunyu,
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!
Best
Rubayet
From: Chunyu Hu <chunyuhu07@xxxxxxxxx>
Sent: Friday, April 23, 2021 7:50 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Request feedback for TBD/CR in the Restricted TWT setup subclause
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.
Thanks!
Chunyu
On Wed, Apr 21, 2021 at 2:04 AM BARON Stephane <Stephane.BARON@xxxxxxxxxxxx> wrote:
Hi Chunyu,
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.
Best regards.
Stéphane.
From: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>
Sent: mercredi 21 avril 2021 05:53
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Request feedback for TBD/CR in the Restricted TWT setup subclause
Hi Chunyu,
Thanks for preparing the CR. Please see attached for my comments.
Regards,
Rojan
From: Chunyu Hu <chunyuhu07@xxxxxxxxx>
Sent: Wednesday, April 21, 2021 10:48 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] Request feedback for TBD/CR in the Restricted TWT setup subclause
Hi, all:
Will you review and provide your feedback to this draft text that resolves some TBD/CID?
Appreciate your input.
Thanks.
Chunyu
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
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
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