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

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



Hi Matt and Rojan,

 

Thanks a lot for your discussion. I think we all are discussing about BA in multi-link, but we don’t focus on same problem.  I am very glad to see you to discuss related problems.

 

For my presentation, actually the “problem” is simple. I just think “BA shall response on the same link” is a little bit over restricted in some case. I agree that BA on the same link is the main method to response, but in some case, it doesn’t need to send use a BAR to solicit BA if the receive status already known (feedback on another link) or doesn’t need to know (Ack policy set to No Ack). If we force the STA to send BAR to solicit BA under these cases. The BAR/BA are redundant, and are pure overhead. In my examples, they don’t have any technical problem, just conflict with Motion’s text (I don’t think they conflict with the intention of the Motion). So my modification doesn’t has any technical change, just clarify that some case can be excluded from the strong restriction of “shall”.

During the teleconference, I am worrying that some other cases that have similar issues are missed. If so, we could think about more cases to make the rules more complete. But I still not very clear what cases are missed. Currently my opinion is that the current proposed solution are listing the exception cases in bullets, if we find more exception cases in the future, then we can list them out in similar way. But I am open to discuss whether it has a better way for the modification.

 

 

Back to Matt’s comments in e-mail. Same as Rojan, I also agree with Matt that the SSN issue (or moving WinStart issue) can be solved without introduce a new BAR variant. I also want to say that it may can be solved both from the transmitter MLD side and receiver MLD side. Matt give a solution from transmitter MLD side, and similarly, it can be solved at the receiver MLD side, as long as the receiver MLD move the WinStart base on the minimum SSN received from both links.

 

Regards,

Yunbo

 

发件人: Rojan Chitrakar [mailto:rojan.chitrakar@xxxxxxxxxxxxxxxx]
发送时间: 2020429 11:32
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] SP discussion about 11-20/0432r1 //: [STDS-802-11-TGBE] TGbe Teleconference [04/27/2020]: Agenda Posted

 

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

 


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]
发送时间: 2020427 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 ETand can be found here:

 

 

The dial in details can be found below 

  ·         Bridge for  MACWebex meeting : Join

Meeting number:   717 442 353      

Meeting password: wireless

·         Bridge for  PHYWebex 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 participants 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


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