WiFi QoS Mappings

[rartych]

When looking at API documentation I have discovered that RFC 8325 provides QoS mapping between 802.11 UP (User Priority) and DSCP (Differentiated Services Code Point) - https://mrncciew.com/2021/09/14/rfc-8325-wifi-qos-mappings/

If the API is limited to WiFi downstream the then there are only 4 different service classes (Voice, Video, Best Effort & Background).
In the simple API these classes can be selected directly, but probably the API can be extended then the mapping to DSCP values according to RFC4594 needs to be used.

Can we reference RFC 8325 in the documentation as the standard reference for WiFi downstream ?

[jpengar]

The proposed API is based on controlling the QoS behaviour of the target home device's IP traffic using DSCP. The original design was challenged because it was desired to have a more developer-friendly approach that avoids network-specific terminology/acronyms (#23 | #25).

As a result of this challenge, a new API design was proposed to expose service classes (much more friendly) instead of directly exposing the DSCP values, which developers may not be familiar with... The design follows the guidelines of RFC4594 and defines a service class mapping to the DSCP value that conforms to the RFC definitions (and it is properly documented in the API specification file). The defined service classes also cover the user stories defined in this project.

So the current design is not related to RFC8325 or IEEE 802.11, so I don't fully understand why we should refer to RFC 8325 in the documentation as the standard reference for WiFi downstream, given the current API design already agreed.

[rartych]

I won't be present during next call. As I am not technical expert in this area I proposed this question. If current implementations follow RFC8325 then it may be useful to indicate this in the documentation, then all implementation can treat the requests in the same way - and give uniform behavior across telcos implementing this API.
If there are other, proprietary technical solutions that can be used for QoD in WiFi downstream, then we can close the issue.

[jpengar]

I won't be present during next call. As I am not technical expert in this area I proposed this question. If current implementations follow RFC8325 then it may be useful to indicate this in the documentation, then all implementation can treat the requests in the same way - and give uniform behavior across telcos implementing this API. If there are other, proprietary technical solutions that can be used for QoD in WiFi downstream, then we can close the issue.

As mentioned above, the proposal is to use Differentiated Services (a.k.a DiffServ). And RFC4594 has been used as configuration guideline. Basically, to provide a developer-friendly mapping of the standard DSCP values to a service class. The API definition is agnostic to the telco operator's internal implementation, as long as it uses the DSCP value to set the desired QoS behaviour. So, I think we could close this issue.

[jpengar]

@rartych In light of the above comments, do you agree to close this issue?

[jpengar]

@rartych In view of the above and the fact that there are no further objections, this issue is closed. When you come back, it could be discussed further if it applies.