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