Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGBE] Document 11-21/1686r0 (Identification of LL streams)

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!

Regards,
Liangxiao

On Thu, Nov 11, 2021 at 7:45 AM Das, Dibakar <dibakar.das@xxxxxxxxx> wrote:

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,

  1. 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.
  2. 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

 

From: VIGER Pascal <Pascal.Viger@xxxxxxxxxxxx>
Sent: Thursday, November 11, 2021 6:49 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,

 

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

 

 

From: Das, Dibakar <dibakar.das@xxxxxxxxx>
Sent: 10 November 2021 18:57
To: VIGER Pascal <Pascal.Viger@xxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] Document 11-21/1686r0 (Identification of LL streams)

 

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  

 

From: VIGER Pascal <Pascal.Viger@xxxxxxxxxxxx>
Sent: Wednesday, November 10, 2021 5:08 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] Document 11-21/1686r0 (Identification of LL streams)

 

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  

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