Re: [STDS-802-11-TGBE] Discussion on TID suggestion from AP to STA in SC

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

Hi Jarkko,

Thanks for splitting the UL and DL cases.

Focusing on the DL side, we should compare it against baseline SCS whose purpose is to inform AP about what UP the AP should use for DL packet classification. The AP in baseline SCS would also have the flexibility to reject such an SCS and the client would interpret it as AP not agreeing to the UP classification.

Now, in 11be when we added QoS Char element to the mix, for DL the STA would send QoS Char + TCLAS. If the AP rejects this request because it still doesn’t like the UP, I am not sure how it can unambiguously convey the same to STA (“did the AP reject the UP or also some other QoS Char parameter ?”) . So, in that respect its not backward compatibility with baseline SCS.

Also, I am not sure what you mean by this:

“The STA should be able to continue using SCS to classify DL TIDs correctly without requirement to use incorrect”.

Since its DL traffic what is the action STA can take if the AP doesn’t like the classification request carried in the SCS Req frame ? Is there a way for STA to force the AP to classify DL packets ?

I suggest in order to make progress add this signaling for the DL case and revisit the UL case in next gen.

Regards,

Dibakar

From: Jarkko Kneckt <00000d5619618f4f-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Tuesday, April 23, 2024 3:52 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Discussion on TID suggestion from AP to STA in SCS Response (doc 11-24-350)

Hi Binita and all, thank you for the comment and discussion.

SCS is implemented by many 802.11be STAs and APs. Changes to the SCS protocol may make existing SCS implementations obsolete.

802.11be is almost finalized. The proposed changes are very big and very late. It would be good to think big changes as part of 802.11bn.

I’ll split this SCS TID mapping rules to UL and DL.

On UL transmissions, the STA selects the TID for all UL transmissions. This principle should continue in WLAN, the STA should be able to define the UP for the UL traffic.

Any change to UL UP mapping principle is big and it is very late change to 802.11be.

On DL transmissions, the SCS was created to map DL traffic to correct TID.

A STA sends SCS Request, because AP transmits DL data by using incorrect TID.

For instance, VoIP call data is transmitted from best effort UP. Internet has erased the DSCP value from the IP header and AP is not able to classify the VoIP traffic to the correct TID.

The STA should be able to continue using SCS to classify DL TIDs correctly without requirement to use incorrect TID for the DL traffic.

Cheers,

Jarkko

PS. SCS and MSCS protocols are different.

Text for MSCS protocol is not relevant for SCS.

Here is the basic principle of the SCS:

Screenshot 2024-04-23 at 2.40.15 PM.png

On Apr 23, 2024, at 12:16 PM, Binita Gupta <bingupta.ieee@xxxxxxxxx> wrote:

Hi All,

One more point to add here from baseline.

I was looking at the MSCS feature in REVme D5.0 and i see that for MSCS AP can recommend a different set of parameters in the MSCS Descriptor element in a rejected MSCS Response, and that can include suggesting a different UP/TID to be used for a subsequent MSCS Request from the STA. There is no restriction and AP is allowed to suggest a different User Priority Bitmap or User Priority Limit in the MSCS Response. Given that this is already supported for MSCS, it is all the more reason to enable this for SCS as well.

<image.png>

<image.png>

<image.png>

<image.png>

Thanks,

Binita

On Tue, Apr 23, 2024 at 8:58 AM Binita Gupta <bingupta.ieee@xxxxxxxxx> wrote:

Hi Dibakar,

Thank you for starting this thread for this CID.

As I also commented, AP should be able to suggest a different TID in the SCS Response if the TID in the SCS Request does not align with the policy on the AP side. And instead of just rejecting it is better that AP can suggest a TID so that STA can know why the request failed and can take corrective action. I agree with you that this is informational and STA can benefit from knowing why the request was rejected.

We haven't received any member responses raising concerns on this. I hope members can align on this proposed resolution this time. This was also discussed in the last round as part of my CR doc 23/1540r5.

Others, please share your thoughts on this so we can resolve this.

Thanks,

Binita

On Thu, Apr 11, 2024 at 1:59 PM Das, Dibakar <dibakar.das@xxxxxxxxx> wrote:

Hi all,

Thanks for the good discussion on CID 22024 yesterday.

22024

35.17

658.48

In the AP suggested QoS Characteristics element in the SCS Response, the UP and TID fields may also be different from the corresponding values in the requested SCS stream, e.g. in the case when the requested UP/TID does not align with the policy on the AP.

Modify text to indicate that UP or TID fields may also differ in the SCS Response.

Revised.

Added TID to the list as well. Since UP = TID in the current spec, this also applies to change in UP.

TGbe editor: please make changes tagged by CID #22024 in 11-24/0350r0.

Please let me know your thoughts on how to resolve this.

Personally, I think since this is informational, the STA could benefit from knowing why AP rejected its request.

Regards,

Dibakar

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