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

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

Let me try to answer questions raised in this thread. Please let me know if I missed any.

1) Patrice's comment on Table 9-299a which has implemented option b per SP result.
There are two parts in the added cell: one is to state what traffic is allowed, as shown in the highlighted text in yellow. The second part is to state/enumerates the specific types of packets, following the same wording style as other rows in the table. The BSR/BQR/QoS-null/... etc. are in similar nature as other rows, intended to be categorized as traffic supporting the data streaming (QoS data packets) to be transmitted in best efficient way.

The corresponding broadcast TWT SP is referred to as restricted TWT SP.

Frames transmitted during a restricted TWT SP by a TWT scheduling AP or a TWT scheduled STA are required to be limited to latency sensitive traffic and frames supporting its delivery:

—       Frame exchanges for delivery of QoS Data frames of TIDs indicated by the Restricted TWT DL/UL TID Bitmap subfield as described in Figure 9-689b (Restricted TWT Info field format), and described in subclause 35.7.2.2 (Latency sensitive traffic differentiation).

—       QoS Null frames

—      BQRs (see 26.5.6 (Bandwidth query report operation)(#Ed))

—      BSRs (see 26.5.5 (Buffer status report operation)(#Ed)). The buffer status report includes TID(s) that are indicated by a value of 1 in their corresponding bit position in the Restricted TWT DL/UL TID Bitmap subfield as described in Figure 9-689b (Restricted TWT Info field format).

—      Frames that are sent as part of a sounding feedback exchange (see 35.x (EHT sounding protocol))

—      Management frames: Action or Action No Ack frames

—      Control and control response frames

Trigger frames transmitted by the TWT scheduling AP during the broadcast TWT SP do not contain RUs for random access (see 26.5.3 (UL OFDMA-based random access (UORA))).

The highlighted part in yellow also reflected feedback received from others offline.

If the group feels the ones listed in the bulleted item are excessive and agree to remove it, I'm okay with it but hope to hear more feedback on it. Please do take a look at existing text. 

2) Jarrko's comments are probably closely related to the above.
First some easy ones -- control frames are included already. Please review the uploaded rev2 and also slightly improved version attached in this email.
Second, on use cases and traffic patterns etc., please review the latest doc 11-20/1046 which re-cap'ed consistently scenarios explained in doc 11-20/408.
In brief, the fairly periodic, bursty traffic pattern is considered as a good usage for the TWT design which not only defines periodicity, minimum wake duration (service period), but also has fairly mature mechanism defining early termination (tolerating traffic/channel condition/rate variance to reasonable extent), and power saving behavior. TWT is hence deemed as a suitable baseline mechanism to support such latency sensitive traffic as agreed by the group.
Reserving SP with margin to accommodate above dynamics is allowed already, and subject to the agreement setup. We also agree on this, as this is the baseline, and as with the understanding that network resources need to be shared and coordinated.

The proposed frame/field design covers cases and provides good coverage/flexibility IMO of common setting: UL and/or DL traffic at choice of scheduling/scheduled STAs. More rules can be clarified/described/developped/modified in either 35.7.2.2 after the basic flow is put in place.

3) Boyce has raised comment and a "broadcast" TWT setup procedure. 
This is probably an optimization and fairly new and non-trivial concept. I prefer deferring this to further discussion in later text development.

4) Frank's comment on the peer-to-peer bit in the (Restricted TWT Variant) Broadcast TWT Info field.
As responded in early doc, the peer-to-peer case as specified in TDLS is already supported and here we intend to get AP's awareness to provide any applicable protection (like channel access rule agreed).
Also, 11be has extended support of peer-to-peer communication and this indicator is defined in a similar line of thoughts. Agree that we can further refine rules and details in next step.
I'd like to collect more feedback on this.

Attached please find a local copy of updated version. Not uploaded yet.

Thanks.
Chunyu


On Wed, Apr 28, 2021 at 7:24 PM Frank Hsu (徐建芳) <frank.hsu@xxxxxxxxxxxx> wrote:

Hi, all,

 

I agree with Jarkko’s point of view. We should make the stream setup signaling in rTWT optional and I am OK to reuse legacy negotiation when necessary.

 

@Chunyu, regarding your latest document, could you run a SP to check group’s preference?

 

1.       Peer-to-peer part: there was a failed SP on Feb 4. It is better to check this part again.

 

Thanks!

 

BRs,

Frank

 

 

From: Jarkko Kneckt [mailto:00000d5619618f4f-dmarc-request@xxxxxxxxxxxxxxxxx]
Sent: Wednesday, April 28, 2021 12:24 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: 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,

 

            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 



On Apr 27, 2021, at 05:41, 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 

 

<image001.png>

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

Attachment: 11-21-0462-03-00be-pdt-mac-restricted-twt-tbds-crs-part1_v0.1.docx
Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document