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

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