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

Re: [STDS-802-11-TGBE] SP discussion about 11-20/0432r1 //: [STDS-802-11-TGBE] TGbe Teleconference [04/27/2020]: Agenda Posted


Yunbo,

I made an incorrect reference - Chunyu proposed a BAR that does the opposite - one that advances the window but does not solicit a BA. You want a BAR that does NOT advance the window, but does solicit a BA.

Anyway, you can create both variants, although I only see the need for the one that does NOT advance the recipient window.

There's another choice:

Send an AMPDU that solicits an immediate BA instead of sending a BAR.
This is effectively a BAR without a window push.
You can argue that you might not have an MPDU available to send.
You could repeat a previous MPDU, there's some overhead as it is a few more bytes than a BAR.
And you might have to always save the last TX MPDU just in case you need it.

The system that you describe is a delayed BA system.

The open questions for me are whether :

1) we can fix the delayed BA problem without a new BA
2) are there problems with the immediate BA system that need a fix?

For 1)

The originator can keep a common pre-split knowledge of the BA window position.
I.e. the WinEndO value, which it does keep anyway
Whenever a BAR is generated on either link, the BAR would always have SSN=WinEndO-windowSize
Then every BAR is always correct and never incorrectly advances the window.
No change to BAR is needed, only a change to how BAR is generated.
I.e. you need to have this WinEndO value constantly available to both links' BAR generation code.
But this is not a problem, at worst, the WinEndO value is slow to update and the BAR that goes to the recipient is a bit slow in pushing the recipient window.

And in this case, it does not matter what the recipient does with respect to returned bitmap values.
I.e. the recipient could send ack status on the link on which the DATA arrived and also send that status on the other link and it would not confuse either the originator or the recipient.

For 2)

if a BA is lost, then the originator might want to send a BAR to retrieve it

Again, in this case, if the recipient had sent link2 MPDU status onto link1, then the BAR generated on link1 might inadvertently move the window of the common RX reorder buffer

So a good solution in this case is the same as for the delayed case, that is - simply always generate BAR frames with an SSN that comes from the single, common originator WinEndO value (minus WinSize).



Matthew Fischer
Nice Guy
Broadcom Inc.
+1 408 543 3370 office


On Mon, Apr 27, 2020 at 8:20 PM Matthew Fischer <matthew.fischer@xxxxxxxxxxxx> wrote:

Yunbo

You need to carry out a few more examples.

There's a much simpler case to consider.

Suppose that you have the following sequence:

Link1 TX SEQ 1-20 - RX error on SEQ 10
Link2 TX SEQ 21-40 - RX error on SEQ 30

Now you need to send BAR frames

If you assume that the BAR generator for link1 does not talk to the BAR generator for link2, then what do you send?

link1 BAR SSN = 1
link2 BAR SSN = 21

if you do this, then I assume that the recipient will generate the BA and transmit it correctly on each link
HOWEVER, the recipient will forward the BAR frames from both links up to the data merge point and will then cause the RX BUFFER window to move to 21, failing to wait for any retransmission of SEQ 10

Note that in this example, the recipient did NOT take the option to send ACK information from one link on the other link!

so - if you are going to send BAR frames on any link, you need to know about the status of the other link

You can know either because:

1) you always look at the complete information from both links before setting the SSN in a BAR
i.e. above the originator's BA reception merge point
2) you always demand ACK information from both links
not a good solution, as it requires the recipient to pass information back and forth - why not just make the originator do this

You can also just require the BAR on each side to only reference some lowest SSN value, until you can generate a BAR from above the merge point - and then you need to advance your lowest SSN value which is common to both links.

Another way to solve this is to use Chunyu's suggestion of creating a BAR that does not advance the RX BUFFER window.

I.e. the BAR currently does two things:

1) solicit a BA
2) advance the RX BUFFER window to SSN

You could create two new BAR variants, one that solicits a BA without advancing the window and one that advances the window without soliciting a BA

But before doing that, I think that we need to think about even more possibilities and what the behavior should be on both the recipient and originator sides.

Matthew Fischer
Nice Guy
Broadcom Inc.
+1 408 543 3370 office


On Mon, Apr 27, 2020 at 7:38 PM Liyunbo <liyunbo@xxxxxxxxxx> wrote:

Dear all,

 

Thanks for your good feedback and comments about below Straw Poll, I will try to think about whether a better _expression_ can be found. Further comments are welcome.

 

@ Po-kai, It would be appreciate that if you can give an example of partial-state BA that may has problem.

@ Jarkko, would you please further explain your questions? Sorry that I didn’t get it during teleconference discussion.

 

 

SP1:

•    Do you agree to modify acknowledgement rule in multi-link as below:

–  The receive status of a MSDU or A-MSDU in a QoS Data frames of a TID received on a link shall be signaled on the same link unless at least one of following conditions is true:

•    The receive status of the MSDU or A-MSDU has already be signaled in other available link(s) with corresponding bit in the BA be set to 1;

•    The corresponding Ack Policy of the MSDU or A-MSDU is set to No Ack.

 

 

Regards,

Yunbo

 

发件人: Alfred Asterjadhi [mailto:asterjadhi@xxxxxxxxx]
发送时间: 2020年4月27日 6:08
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: [STDS-802-11-TGBE] TGbe Teleconference [04/27/2020]: Agenda Posted

 

Hello all,

 

I uploaded an updated version of the agendas, which contains the agenda for the next conference call (which starts on Monday 04/27/2020 at 19:00 ET) and can be found here:

 

 

The dial in details can be found below 

  ·         Bridge for  MAC: Webex meeting : Join

Meeting number:   717 442 353      

Meeting password: wireless

·         Bridge for  PHY: Webex meeting : Join

Meeting number:    791 676 431

Meeting password: wireless

 

As a gentle reminder, please ensure that the following information is listed correctly when joining the call:

- [voter status] First Name Last Name (Affiliation)

 

Format for overall participant’s detail: “[V] John Doe (Affiliation)"

 

Please let me know if you have any questions and/or suggestions.

 

Best Regards,

 

Alfred

 

--

Alfred Asterjadhi, PhD

IEEE802.11 TGbe Chair,

Qualcomm Technologies Inc.

Cell #:    +1 858 263 9445

Office #: +1 858 658 5302

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