I agree with Dibakar that there is no violation of SCS protocol here. AP can reject the SCS Request as per baseline, and in baseline SCS, STA would interpret that rejection as TID not being acceptable for DL traffic classification. In11be, we have added QoS Characteristics, and the only way to signal that SCS Request is rejected because of TID not being acceptable is by explicitly suggesting a TID in the response.
@Jarkko - In all your arguments, you are missing that enterprise APs can and do have QoS policies on how flows are provided QoS treatment. The purpose of those policies are to provide improved QoS experiences to the end users, specifically for the business critical application for that particular deployment. E.g. a guest device in an enterprise deployment asking for mapping DL flow to TID 7 may not be allowed by the AP policy. Similarly, if a device is asking to map a business critical video conferencing app to TID 0 (because app developer has not marked the traffic correctly), then AP would suggest to map that to TID 5. So, AP policy could suggest TIDs either up or down. APs already have these policies. SCS feature in 11be should enable AP to continue to apply its policy to best serve all the QoS traffic.
RE>> your comment - "The STA should be able to continue using SCS to classify DL TIDs correctly without requirement to use incorrect TID for the DL traffic."
-- You are assuming that the TID provided by the AP is an incorrect TID. I would challenge that. APs which provide wrong TIDs leading to bad QoS won't be favored in the parket, so there is no reason why an AP would provide an incorrect TID. In fact, AP when recommending a different TID, would suggest a TID such that it improves overall QoS experience for end users.
RE>> your comment
"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. "
Here you are saying AP should be restricted to only rejecting the SCS request if it does not have resources to classify or meet the QoS parameters. This is not what SCS protocol defines even in baseline. Baseline SCS has a policy related status code 129 which AP can use to terminate an SCS stream, due to higher layer policy. So AP policy consideration is part of baseline SCS already. It is not a new consideration in 11be SCS. In 11be too, an AP can terminate as SCS stream with the following policy code, so your interpretation of only two conditions when an AP can reject is not accurate per baseline SCS and 11be SCS.
Re>> "In general, there is nothing positive to relax the QoS characteristics and offer poor QoS for the clients. "
-- again, when applying AP policy, the goal is to provide improved QoS for end users and not the other way. So, I challenge all such statements from you that enabling AP to suggest a TID will result in poor QoS to the clients.
Regarding MSCS vs SCS - yes the two are different protocols, still the protocol principles are relevant across the two. My point was that in the MSCS protocol we allow AP to reject and make a suggestion for what UPs are acceptable per AP's policy. We should enable AP to be able to apply its policy for SCS as well and suggest a different TID to provide overall improved QoS. There is nothing positive in restricting AP's behavior in this regard when it is using SCS.
To make progress, I am ok with Dibakar's proposed approach of making this change for DL and revisiting UL in 11bn.
Thanks,
Binita