Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Chunyu, 1, I agree we should not ask for fairness for different traffics with different priorities. My point is that traffics with same priority should be
treated fairly. As I mentioned previously, the fairness issue of TID level is that some non-latency-sensitive traffic (which should not be prioritized) that is mapped to the same TID has the same priority with latency sensitive traffic. If the spec adds a restriction that “if a latency-sensitive traffic is mapped to a TID, non-latency-sensitive traffic or other latency-sensitive
traffics with different QoS parameters shall not be mapped to the same TID”, the fairness issue will not be a problem. Maybe the abuse issue can also be solved.(I am not suggesting to add a restriction like that, just to make my point clear to you) 2,Another question is that The signaling in your document presented on Monday is not able to allocate resources for multiple STAs. Do you want to limit the rTWT IE to unicast
frames? I think it would be quite efficient if the AP can allocate resources for multiple STAs using one broadcast frame. Regards Boyce 发件人: Frank Hsu (徐建芳)
[mailto:frank.hsu@xxxxxxxxxxxx] 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]
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:
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 |