“The point of SCS is to allow STA to configure the DL traffic to correct UP. I am surprised that we want suddenly change the basic operation of the SCS protocol and say that any TID is OK for DL streams. This seems like violation of the
QoS and the basic SCS protocol.”
Hi Jarkko,
Whats the violation ? Isnt this just baseline behavior after AP rejects an SCS Request ?
Regards,
Dibakar
From: Jarkko Kneckt <jkneckt@xxxxxxxxx>
Sent: Tuesday, April 23, 2024 4:38 PM
To: Das, Dibakar <dibakar.das@xxxxxxxxx>
Cc: 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 Dibakar,
Thank you for your response and agreeing on taking UL to the 802.11bn.
We should take the DL changes also the 802.11bn.
The point of SCS is to allow STA to configure the DL traffic to correct UP. I am surprised that we want suddenly change the basic operation of the SCS protocol and say that any TID is OK for DL streams. This seems like violation of the
QoS and the basic SCS protocol.
AP can reject SCS stream, if it does not have resources to classify the traffic or if it cannot meet the latency and other QoS Characteristics element parameters. This should be enough.
- The UP should be specific to application and UP should not be possible to freely change. 802.11be has adopted this principle for SCS and there is no need to change it.
In general, there is nothing positive to relax the QoS characteristics and offer poor QoS for the clients.
Clients favor APs that serve traffic within the requested QoS characteristics.
@Dibakar, when are you planning to present this submission?
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.
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.
PS. SCS and MSCS protocols are different.
Text for MSCS protocol is not relevant for SCS.
Here is the basic principle of the SCS:
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.
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 for the good discussion on CID 22024 yesterday.
|
|
|
|
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.
|
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.
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
|