Hi Thomas,
Thanks for discussion.
I didn’t say the SN re-allocation is necessary. I think it may depend on the implementation. As you said, a MSDU will not be allocated SN until
it will be transmitted immediately.
For your last sentence, based on the current spec., the MSDU order is normally implemented in the MAC layer.
Regards
发件人: Thomas Derham [mailto:thomas.derham@xxxxxxxxxxxx]
发送时间: 2022年11月15日
15:41
收件人: huangguogang <huangguogang1@xxxxxxxxxx>
抄送: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE] Discussion of 11-22/1828 R-TWT Traffic Delivery
Hi Guogang
>> In the above case, does the transmitter need to re-order MSDUS in the queue based on the remaining time before being
discarded and re-allocate the SN and so on?
Why would SN reallocation be necessary? To my understanding, transmitter does not (need to) allocate an SN until immediately prior to encryption
(and PN allocation) and transmission.
In general such packet reordering based on SCS traffic characteristics can probably be handled above the MAC.
Thanks
Thomas
On Sat, Nov 12, 2022 at 8:07 AM huangguogang <000017b1384624cd-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
Update
Hi Chunyu,
Thanks for imitating this email discussion.
For CID 10691, I think the commenter’ concern should be addressed in a appropriate way. I have the following reason.
As what you said, currently, a TID can be shared by multiple SCS traffic streams as 802.11 doesn’t specify any rules to prevent so. Hence, there is a possibility that multiple SCS streams with different delay bound requirements at least in theory. Furthermore, considering even the SCS negotiation is done before, TID 0-7 may already have been used by the traffic which doesn’t belong to any SCS stream. Hence, the above case is not a corner case.
In the above case, does the transmitter need to re-order MSDUS in the queue based on the remaining time before being discarded and re-allocate the SN and so on?
If no, then the HOL MSDU may not be the one which has the minimum remaining time before being discarded. We will face this issue when the buffer report will be defined. I had already found this issue （i.e. HOL Packet Delay Feedback vs. Earliest MSDU Expiration Time） when I review 1373r1 and 1278r1.
Hence, I suggest to add some text to clarify this.
10691
Liangxiao Xin
35.9.5
512.44
Can a R-TWT TID be shared by mulitple SCS traffic streams?
A R-TWT TID can only be shared by mulitple SCS traffic stream with the same delay bound
Rejected
A TID can be shared by multiple SCS traffic streams as 802.11 doesn’t specify any rules to prevent so. The “same delay bound” is vague – a traffic stream requiring 10 msec vs 10.1 msec cannot be served with the same R-TWT schedule? Such enforced limit is not realistic nor necessary. AP/non-AP STAs should mutually and jointly examine the network resources and their traffic load/requirements to utilize TID and R-TWT schedule.
Regards
Guogang Huang
发件人: huangguogang [mailto:000017b1384624cd-dmarc-request@xxxxxxxxxxxxxxxxx]
发送时间: 2022年11月12日 23:59
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Discussion of 11-22/1828 R-TWT Traffic Delivery
Hi Chunyu,
Thanks for imitating this email discussion.
For CID 10691, I think the commenter’ concern should be addressed in a appropriate way. I have the following reason.
As what you said, currently, a TID can be shared by multiple SCS traffic streams as 802.11 doesn’t specify any rules to prevent so. Hence, there is a possibility that multiple SCS streams with different delay bound requirements at least in theory. In this case, does the transmitter need to re-order MSDUS in the queue based on the remaining time before being discarded and re-allocate the SN and so on?
If no, then the HOL MSDU may be the one which has the minimum remaining time before being discarded. We will face this issue when the buffer report will be defined. I had already found this issue （i.e. HOL Packet Delay Feedback vs. Earliest MSDU Expiration Time） when I review 1373r1 and 1278r1.
Hence, I suggest to add some text to clarify this.
10691
Liangxiao Xin
35.9.5
512.44
Can a R-TWT TID be shared by mulitple SCS traffic streams?
A R-TWT TID can only be shared by mulitple SCS traffic stream with the same delay bound
Rejected
A TID can be shared by multiple SCS traffic streams as 802.11 doesn’t specify any rules to prevent so. The “same delay bound” is vague – a traffic stream requiring 10 msec vs 10.1 msec cannot be served with the same R-TWT schedule? Such enforced limit is not realistic nor necessary. AP/non-AP STAs should mutually and jointly examine the network resources and their traffic load/requirements to utilize TID and R-TWT schedule.
Regards
Guogang Huang
发件人: Chunyu Hu [mailto:chunyuhu07@xxxxxxxxx]
发送时间: 2022年11月12日 12:37
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: [STDS-802-11-TGBE] Discussion of 11-22/1828 R-TWT Traffic Delivery
Hi, all:
I presented the document 11-22/1828 on R-TWT traffic delivery:
Please share your comments via email to me or find me for a f2f discussion in Bangkok. Thank you!
Chunyu
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
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