Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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 |