| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Ming, Thanks for the clarification. Just to point out that even if it is WinStartR/WinEndR, saying all the values in the recipient’s record of status between WinStarto
and WinEndo shall be included in the bitmap of Block Ack is also not true. In fact, in 11ax, it is changed and saying that STA can report a portion of status in WinStartR and WinEndR rather than all the status. Please see the texts below. The Starting Sequence Number subfield of the Block Ack Starting Sequence Control subfield of the BlockAck frame shall be set to any We consider our proposal is for the transmitter to indicate the range and recipient can report the portion in the range. In some sense, it is an extension of
what we do today with the benefits for the transmitter to know. Best, Po-Kai From: Ganming (Ming) <ming.gan@xxxxxxxxxx>
Oh, there is typo, it is WinStartR/WinEndR 发件人:
Huang, Po-kai [mailto:po-kai.huang@xxxxxxxxx]
Hi Ming,
Thanks for checking with me. I provide my clarification below. Best, Po-Kai From: Ganming (Ming) <ming.gan@xxxxxxxxxx>
Hello Po-kai Thank you for presenting DCN 20-462.In my mind, controlling bitmap size at the originator will impact the partial state BA. I just
confirm that all the values in the recipient’s record of status between WinStarto and WinEndo shall be included in the bitmap of Block Ack.
So the proposal conflicts with the spec.
[Po-Kai]: I wonder if you check your source right. WinStart0 and WinEnd0 is for transmit buffer control. As you said below, recipient
can respond based on partial state, so I do not think your statement above is correct. Regarding partial state, if the info of the scoreboard can not be sent to the originator at one time because of the solicited bitmap
size . Later it will be erased by another active block ack session such that the receiver status is lost.
[Po-Kai]: I agree with you that partial state may happen. In fact, we expect multi-link will have more usage of partial state in each
link. Perhaps, I should clarify that STA will have any of it record like today, and when transmitter indicates the range, STAs just respond what it have in the range.
For example, if transmitter indicates range 0 to 511, and recipient only has say 448 to 511, then recipient can just respond 448 to
511 with what the recipient has. The proposal does not mandate recipient to implement full state. I wonder if this is the confusion that we can not address at the end. Moreover, controlling the bitmap size of Block Ack will lead to more processing time to generate BA. That is to say, it burdens the
recipient. [Po-Kai]: I think I mention in the slide that this is optional. Currently, a recipient may continue to send the largest BA based on
negotiated buffer size if it wishes, but we think the recipient will have to pay performance price, which we can leave to implementation if a recipient decides to do so. So I suggest we should follow baseline to reduce the overhead if we really want it. [Po-Kai]: I agree that we should continue to allow partial state, and I believe that the proposal does not mandate full state.
I think if we continue to allow recipient to send the largest BA size and transmitter does not know, then overhead will just continue
to scale as we go for larger and larger BA size. Best wishes, Ming Gan 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 |