Hi Matt and all,
I agree with Matt that we need not define a new BAR for this issue, simply ensuring that the SSN is always set to the smallest SSN across links will ensure that the receive window does not advance. WinStartO (= WinEndO - WinSizeO) of the
common transmission window would indicate that value.
However, I think the main point in Yunbo’s presentation, is that BAR
need not be sent on both links (e.g. in case the A-MPDUs do not set the Ack policy to immediate ack or the immediate BAs are lost on both links etc.). For a recipient that is capable of providing cross-link receipt status, a single BAR-BA exchange on
any one link should suffice.
Another point to clarify on this topic: from yesterday’s discussions during my contribution, it appears that most prefer the scoreboard sizes to be the same on all links. And I assume the Receive window (Rx Reordering Buffer size, Rx Buffer
size for short) would also be the same size? If that is the case, wouldn’t the MLD throughput be restricted by the RX Buffer size? For example:
Example 1)
Link 1 and Link2 have same data rate; Rx Buffer size = per-link scoreboard sizes = 1024:
Link1 TX SEQ 513-1024 – No RX error
Link2 TX SEQ 1-512 – No RX error
Even though each link supports 1024 BA Bitmap, the transmissions on each link is restricted to half (512) due to the fact that the Rx Buffer is shared between the two links.
Let’s take another example (intentionally extreme case):
Example 2)
Link 1 is three times as fast as Link2; Rx Buffer size = per-link scoreboard sizes = 1024:
Link1 TX SEQ 257-1024 – No RX error
Link2 TX SEQ 1-256 - RX error on SEQ 1 - 10
Rx Buffer is stuck until SEQ1-10 are correctly received, or until the Originator decides to give up on them. Effectively, the transmission is blocked on Link1 and only SEQ1-10 can be retransmitted on Link2.
De-couping the Rx Buffer size from the scoreboard size (e.g. Rx Buffer size = n*scoreboard size, n = number of links) will allow MLDs to acieve higher efficiencies by taking full advantage of the larger BA Bitmap sizes. Sure we may need
to handle some issues with cross-link transmit window misalignments, but the efficiency gains would be worth it.
Regards,
Rojan
From: Matthew Fischer <00000959766b2ff5-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, April 29, 2020 3:08 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] SP discussion about 11-20/0432r1 //: [STDS-802-11-TGBE] TGbe Teleconference [04/27/2020]: Agenda Posted
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.
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?
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.
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).
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?
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:
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.
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
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,
--
Qualcomm Technologies Inc.
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
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