Hi Stephane,
Lets consider UL traffic. Say, we don’t have any SCSID in a TWT IE but there is just mapping of TIDs to indicate which TIDs are prioritized in an SP.
Now, when that corresponding SP arrives and the AP sends a TF to the STA soliciting UL Data, the STA prioritizes, by itself, which streams to choose packets from. If there are MSDUs belonging to a stream with low latency bound, then by
its own selfish strategy its going to prioritize that. It can also make a bad decision and prioritize streams belonging to different stream in which case its going to penalize its own QoS because of bad implementation logic.
So, since how the STA prioritizes among MSDUs that map to same TID is based on own internal, selfish logic, having an additional signaling from AP to tell the STA what to transmit should not change its outcome.
Regarding your second question below, by AP’s expectation you mean that AP sends the TF thinking the STA would send packets belonging to high priority SCS-1 but instead STA is transmitting something else. If that’s the concern, it is related
to how the AP polices whether STAs are really using the r-TWT SP for low latency or not. This is largely an implementation choice at the AP. If the AP is not constrained for resources, then sometimes the STA’s cheating is not going to matter much. Otherwise,
the AP can use internal tools, (e.g., match statistics of MSDUs transmitted in UL with the expected SCS flows) and decide to terminate that STA from the SP.
Regards,
Dibakar
From: BARON Stephane <Stephane.BARON@xxxxxxxxxxxx>
Sent: Friday, November 19, 2021 7:03 AM
To: Das, Dibakar <dibakar.das@xxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] Document 11-21/1686r0 (Identification of LL streams)
Hi Dibakar,
I understand your point, but If there is no SCS identifier in the TWT IE, how does a station make a link between a given rTWT SP and SCS streams negotiated during SCS setup ?
I think the AP scheduling policy will take into account the streams information coming from the STAs, but if the AP does not indicate some information about the expected traffic in a given rTWT, stations will not follow AP’s expectation
and its scheduling becomes useless.
Regards.
Stéphane.
Hi Stephane,
I agree during the TWT SP, a STA should prioritize own traffic to AP or vice versa based on the parameters obtained during SCS stream setup (e.g., latency bound, PDR etc.). The action here is likely about picking for transmission the MSDUs
belonging to high priority SCS streams over low priority SCS streams that map to same TID, or picking MSDUs with high priority TIDs over low priority ones etc.
However, it seems to me the STA should make the above decision regardless of whether an SCSID is included in the TWT IE. It already has the necessary information from SCS setup. So,its not clear to me how
adding more information to the TWT IE helps in this regard.
Regards,
Dibakar
Hi Dibakar,
I think one important related action that can be taken by a station during an rTWT SP is the data selection.
In my opinion, a STA should take into account the SCS stream negociated for a given rTWT to select the data for transmission during the corresponding rTWT SP.
This is why adding a finer traffic identifier, like SCS, in the rTWT IE is a good point.
Regards.
Stéphane.
Mostly, TXOP level actions such as Sending TF to solicit PPDUs for particular SCS stream, or DL packets belonging to a particular SCS stream etc.
Hi Dibakar,
Thank you so much for the response.
When you say R-TWT related actions, what are they? Do you mean, for example, negotiation of R-TWT SP parameter setting such as start time, interval, duration or any actions that AP/STAs take during R-TWT SP?
Hi Liangxiao,
I think the issue is not contradiction or about adding information in the r-twt IE. Since its just signaling we can always add more information to TWT IE. The question is whether
the AP/STA can take some additional r-twt related action only if that information is included. If there is no such action, what is the value of appending extra information ?
Regards,
Dibakar
Hi Dibakar,
"“if the STA is not able to send MSDUs that have higher priority, especially those of negotiated
rTWT between AP and STA, the STA will also send data units (not-LL stream or other local LL stream belonging to another rTWT deadline contact) that are not in the rTWT contract during a rTWT SP. Thus QoS is broken, due to this unfairness. The rTWT is no longer
“restricted”.”
I think that’s precisely the reason the negotiation in r-TWT is at TID-level."
Could you please explain "the reason"? How does SCS information contradict the R-TWT negotiation at TID level? What is the issue there if adding SCS information in the R-TWT negotiation?
Thank you!
Hi Pascal,
I think TCLAS has some behavior (primarily about setting UP) associated to it that has already been tested in certification programs recently.
For TSPEC/TSPEC-lite, I expect this to contain informative parameters with the action being largely limited to the tools we have. For example,
-
For DL, AP uses the information about QoS flow characteristics to transmit MSDUs with lower latency bound earlier, provided the baseline SN assignment etc allows for it.
-
For UL, AP schedules a STA that it knows has urgent low latency packet first with the expectation that the STA will do its own prioritization when responding to the TF.
Regards,
Dibakar
Hi Dibakar,
Thank you for your feedback.
In that case, I wonder what is the necessity to define TCLAS and TSPEC (or TSPEC-equivalent) if MSDUs can no longer be treated independently
(e.g MSDU lifetime of 2 streams fitting in same TID could be differently specified but finally considered as identical for delivery).
Regards,
Pascal
Hi Pascal,
“if the STA is not able to send MSDUs that have higher priority, especially those of negotiated rTWT between AP and STA, the STA will also send data units (not-LL
stream or other local LL stream belonging to another rTWT deadline contact) that are not in the rTWT contract during a rTWT SP. Thus QoS is broken, due to this unfairness. The rTWT is no longer “restricted”.”
I think that’s precisely the reason the negotiation in r-TWT is at TID-level.
Regards,
Dibakar
Hello All,
I presented last Monday document 11-21/1686r0 (CR for Low-Latency stream identification).
This document demonstrates the requirement to finely identify data units related to latency sensitive streams, especially for an SCS contract well characterized
by TSPEC and TCLAS as per 35.3.21 . This SCS stream identification is useful for accurate reporting of BSR, for restricting the triggering to SCS stream (TF triggers accurate size according to the contract or adapted to received BSR) or even for rTWT (specify
the SP is for given SCS(s) ).
Thanks to the members who provided appreciated feedback during the call. I notice still remaining members in the queue: Chunyu, Jay, Muhammad, Dibakar, Liangxiao,
Boyce, Yonggang, Xiaofei.
Anyone interested in this topic, please feel free to provide any comment in this thread or contact me individually if you prefer.
In addition, please see some answers to comments received through the chat:
-
Topic about SN of MPDUs: “STA may still not be able to transmit MSDUs for that SCSID because it needs to transmit MSDUs according to SN “
-> if the STA is not able to send MSDUs that have higher priority, especially those of negotiated rTWT between AP and STA, the STA will also send data units (not-LL
stream or other local LL stream belonging to another rTWT deadline contact) that are not in the rTWT contract during a rTWT SP. Thus QoS is broken, due to this unfairness. The rTWT is no longer “restricted”.
-> I am of opinion that out-of-sequence delivery is already present for multi-link transmission; what is the special issue here ?
-> In addition, if MSDUs are to be strictly transmitted in sequence, a single erroneous MSDU/MPDU (e.g. worst case if non-LL stream) will break the delivery
to upper layer (re-ordering buffer at recipient), so that already arrived LL data units suffer from HOL issue and misses its deadline.
-> In addition, one may consider that low latency traffic can benefit from aging mechanism to avoid outdated packet to be sent or retransmitted.
In that case, SN delivery sequence is also impacted.
-
Topic about increasing the number of TIDs : “Only 8 TIDs are typically used, but there can be up to 255 SCSIDs”, “simplest approach is to open up TID 8-15”, “do we need to define the EDCA
parameter for TID 8-15 accordingly”…” define how to map TID 8-15 to AC ?”
-> IMHO, changing the EDCA with adding a bunch of new TIDs seems too complicated, for medium access point of view.
I expect using SCSID for packet classification at emitter side for LL data units is the same concept as building A-MSDU. If implementation only considers TID
and destination for building A-MSDU , then the fairness issue of mixing any MSDU belonging to a TID remains.
In case SN ordering could be an issue, triggering with SCSID would just mandate assigning sequence number upon transferring A-MSDU/MPDU frame to affiliated STA,
without any change in EDCA. SN assignment is still discussed in the group (11-21-1111).
-
Using SCSID in TF is an easy means for the AP to select appropriate STA(s) for communication, with a desired allocated RU size. There is no issue at AP as it only respects the contract scheduling. As a result,
AP at least expects the STA will also limit the data units corresponding to the intended LL flow.
-
SCSID size in “Trigger Dependent User Info” subfield : as per slide 7 of the document, the original SCSID is 8 bits SCSID, whereas the room as illustrated is 5 bits. This illustration is provided with HE variant,
maybe EHT variant User Info can have a dedicated ‘trigger dependent User Info’. Other way would consist of limiting to less bits, as 256 SCSIDs is large enough per STA (32 enough ?).
-
Location of SCSID subfield in TWT IE (slide 8) : it appears ‘Restricted TWT Traffic Info’ field is better, as there is room here for 1-byte (received a comment that this is no longer the case in ‘Broadcast
TWT Info’ field). SCSID subfield and DL/UL TID subfields will therefore be mutual exclusive.
Thank you,
Best regards,
Pascal
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
--
Liangxiao Xin
Sr. Applied Research Engineer - Wireless
Sony Corporation of America
--
Liangxiao Xin
Sr. Applied Research Engineer - Wireless
Sony Corporation of America
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
|