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

Re: [STDS-802-11-TGM] 11me/D3.0 CID 4341 (what BA params can be modified)

--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

 

Mark-san,

 

My understanding stands on the following descriptions:

“The block ack mechanism is initialized by an exchange of ADDBA Request/Response frames” in 10.25.1 and

“For each accepted block ack agreement, the originator shall set the sequence number of the first frame transmitted under the agreement to the value of the Block Ack Starting Sequence Control field of the ADDBA Request frame of the accepted block ack agreement.” in 10.25.2.

From the first sentence, I read as, when a block ack agreement for the same TID is re-setup, everything is reinitialized.

From the second sentence, if the MPDU whose sequence number was previously 82 is intended to be transmitted after the renegotiation, then the new SSN, 21, is assigned to that MPDU in your example. If the originator cannot overwrite the sequence number for that MPDU, then it needs to start transmitting from the MPDU that can be set to 21, because it promised that the SSN is 21 in the ADDBA Request.

 

Also, I'm slightly uncomfortable with the suggestion that in the

example below 82 would be renumbered to 21.  I'd be worried about

what would happen with what was previously acked as SN 81 (is

the old one discarded?  The new one, when it comes around?).

 

If the originator is worried about the frames which were previously acked and not acked, it means that the originator wants to continue the transmission in the current agreement, so the originator won’t send an ADDBA Request frame.

 

Best regards,

tomo

 

From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Friday, June 16, 2023 5:07 PM
To: adachi tomoko(足立 朋子 ○ＲＤＣ□ＩＴ研○ＷＳＬ) <tomo.adachi@xxxxxxxxxxxxx>; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: RE: 11me/D3.0 CID 4341 (what BA params can be modified)

 

So you mean that when modifying BA, any MPDUs that have been txed

are discarded, even if they are not acked?  In the example below,

MPDUs with SNs 21 to 80 are just lost, if the receiver hadn't

received them?  That doesn't sound ideal to me, though I suppose

the originator could choose to retry or timeout before modifying BA,

if it wants to avoid this.  Do you think this discard behaviour on

modify is already specified?

 

Also, I'm slightly uncomfortable with the suggestion that in the

example below 82 would be renumbered to 21.  I'd be worried about

what would happen with what was previously acked as SN 81 (is

the old one discarded?  The new one, when it comes around?).

But perhaps it's OK if the rule is that everything is reset on BA

modification.  Not sure!

 

Thanks,

 

Mark

 

--

Mark RISON, Standards Architect, WLAN   English/Esperanto/Français

Samsung Cambridge Solution Centre       Tel: +44 1223  434600

Innovation Park, Cambridge CB4 0DS      Fax: +44 1223  434601

ROYAUME UNI                             WWW: http://www.samsung.com/uk

 

From: Tomo Adachi <tomo.adachi@xxxxxxxxxxxxx>
Sent: Thursday, 15 June 2023 12:13
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] 11me/D3.0 CID 4341 (what BA params can be modified)

 

--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

 

Hello Mark-san,

 

I meant “gone” as “discarded”.

 

My understanding is as follows:

If the MPDU whose sequence number was previously 82 is intended to be transmitted after the renegotiation, then the new SSN is assigned to that MPDU.

If the new SSN is 21, then the sequence number which was 82 will be overwritten by 21 and all the following MPDUs will have reassigned sequence numbers in ascending order.

But note that the SSN doesn’t need to be 21 in this case. It can be 0 or 20 or 82 or whatever.

And you even don’t need to try transmitting from the MPDU which was previously 82 but discard those that already had sequence numbers assigned and can restart from a brand new MPDU that came into the queue requesting a new sequence number assignment.

 

Best regards,

tomo

 

From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Thursday, June 15, 2023 7:40 PM
To: adachi tomoko(足立 朋子 ○ＲＤＣ□ＩＴ研○ＷＳＬ) <tomo.adachi@xxxxxxxxxxxxx>; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: RE: 11me/D3.0 CID 4341 (what BA params can be modified)

 

Thanks for this feedback, Tomo-san.

 

Let's work through an example to make sure we have a shared understanding.

 

We start with:

Buffer Size = 64

Window start = 20

Scoreboard (lsb first) = 10…0100

i.e. SNs 20 and 81 have been acked; SNs 21-80 have been txed but not acked; 82 onwards have not been txed yet

 

Then the BA is modified, with SSN = 21 and Buffer Size = 32.

 

What happens to SNs 21-80 ("all the MPDUs that were waiting for an BlockAck will be gone" -- what does "gone" mean here)?

 

What happens to SN 81?  The originator probably can't tx this when it

gets to it because it's already been thrown away locally (since acked).

Presumably the recipient still holds onto it (for reordering and

replay purposes) until it receives 82 (or times out)?  And the originator

has to skip over it when it gets there, but also has to remember that

it was already txed (so that it doesn't wait for it to be acked)?

 

Thanks,

 

Mark

 

--

Mark RISON, Standards Architect, WLAN   English/Esperanto/Français

Samsung Cambridge Solution Centre       Tel: +44 1223  434600

Innovation Park, Cambridge CB4 0DS      Fax: +44 1223  434601

ROYAUME UNI                             WWW: http://www.samsung.com/uk

 

From: tomo.adachi@xxxxxxxxxxxxx <tomo.adachi@xxxxxxxxxxxxx>
Sent: Thursday, 15 June 2023 10:38
To: Mark Rison <m.rison@xxxxxxxxxxx>; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: RE: 11me/D3.0 CID 4341 (what BA params can be modified)

 

 

Hello Mark,

 

From my understanding, whenever the block ack agreement is renegotiated, the starting sequence number will be refreshed.

So, all the MPDUs that were waiting for an BlockAck will be gone and the originator and the responder can sync at the start of the renegotiation.

The reason why the TID is special is because the block agreement is on TID basis (i.e., if the TID is different, then the negotiation is different), as I understand.

 

So I agree only on your a) and I suggest leave the other places as is.

 

Best regards,

tomo

 

From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Thursday, June 15, 2023 5:26 PM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] 11me/D3.0 CID 4341 (what BA params can be modified)

 

--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

I haven't had any response on this, so I will try to float a possible

direction and see if this provokes a response:

 

a) Revert the "When Block Ack operation is modified, only the timeout can be changed."

in 9.6.4.1 (anyway, this is more behaviour than format)

 

b) State in 11.5.4 Error recovery upon a peer failure that BA agreement

modification also resets the inactivity timer.  Maybe also tweak

penultimate para of 10.25.4 Teardown of the block ack mechanism

to cover BA agreement modification

 

c) Put a NOTE in 10.25.2 and 11.5.1 along the lines of

 

NOTE—The parameters of the agreement are identified in

9.6.4.2 ADDBA Request frame format and

9.6.4.3 ADDBA Response frame format.  The handling of a

modification to any given parameter other than the timeout

is parameter-dependent.  Care should be taken if any

restrictions are introduced (e.g. the new buffer size is

smaller than the current buffer size, and there are MPDUs

outside the range of the new buffer size).

 

[I'm mentioning 9.6.4.2 as well as 9.6.4.3 because I'm not 100%

confident everything is entirely governed by the ADDBA Response.]

 

Thanks,

 

Mark

 

--

Mark RISON, Standards Architect, WLAN   English/Esperanto/Français

Samsung Cambridge Solution Centre       Tel: +44 1223  434600

Innovation Park, Cambridge CB4 0DS      Fax: +44 1223  434601

ROYAUME UNI                             WWW: http://www.samsung.com/uk

 

From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Friday, 26 May 2023 19:55
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGM] 11me/D3.0 CID 4341 (what BA params can be modified)

 

--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

CID 4341 asks what parameters of a block ack agreement can be modified.

If you have any answers to the questions highlighted in cyan below, or

any other thoughts on the matter, please do respond!

 

Identifiers

Comment

Proposed change

CID 4341

Mark RISON

10.25.2

9.6.4.1 says "When Block Ack operation is modified, only the timeout can be changed." but 10.25.2 says "All parameters of the agreement may be changed except for the TID." and 11.5.1 says something similar

Decide one way or the other.  If buffer size and timeout can be changed, describe what happens if the new values are smaller than the current, and the current window/idle time exceed the new limits [needs discussion]

 

Discussion:

 

We currently have:

 

9.6.4.1 Block Ack Action field(#3729)

ADDBA Request and ADDBA Response frames are used to set up or to modify block ack operation(#3518) for a specific TC, TS, or GCR group address. (#3172)When Block Ack operation is modified, only the timeout can be changed.

 

10.25.2 Setup and modification of the block ack parameters

(#1807)A block ack agreement may be modified by the originator by sending an ADDBA Request frame ((#3174)see 11.5.2 (Setup and modification of the block ack parameters), except that MLME-ADDBA primitives are not used). All parameters of the agreement may be modified except for the TID.

 

11.5 Block ack operation

11.5.1 Introduction

(#3174)Block ack agreements may be set up, modified by the originator, or deleted from the MAC (see 10.25.2 (Setup and modification of the block ack parameters)) or from the SME. The setup, modification by the originator and deletion of block ack agreements from the SME is described in this subclause. All parameters of an agreement may be modified except for the TID.

 

An ADDBA Request frame is defined in Table 9-445—ADDBA Request frame Action field format and contains the following fields:

 

Block Ack Parameter Set, which contains A-MSDU Supported, Block Ack Policy, TID and Buffer Size subfields

Block Ack Timeout Value

Block Ack Starting Sequence Control, which contains a SSN

GCR Group Address element (optional), which contains a GCR group address

Multi-band (optional), which contains loads of stuff

TCLAS (optional), which contains loads of stuff

ADDBA Extension (optional), which contains No-Fragmentation and HE Fragmentation Operation subfields

EDMG Flow Control Extension Configuration (optional), which contains loads of stuff

SAR Configuration (optional), which contains quite a lot of stuff

 

Q1: is it really OK for all of these to be modified?  E.g. change A-MSDU support or GCR address or TCLAS or fragmentation or Multi-band/EDMG/SAR config?

 

An ADDBA Response frame is defined in Table 9-446—ADDBA Response frame Action field format and contains the following fields:

 

Block Ack Parameter Set

Block Ack Timeout Value

GCR Group Address element (optional)

Multi-band (optional)

TCLAS (optional)

ADDBA Extension (optional)

EDMG Flow Control Extension Configuration (optional)

SAR Configuration (optional)

Originator Preferred MCS element (optional)

 

Q2: is it really OK for all of these to be modified, even if not modified in the request (either w.r.t. the original request, or the original response)?

 

Q3: even if we focus on the “core” parameters, i.e. timeout and buffer size, what if the new values are smaller than the current values, i.e. there has been no traffic for more than the new timeout, or the new buffer size is smaller than the current outstanding window size?

 

Thanks,

 

Mark

 

--

Mark RISON, Standards Architect, WLAN   English/Esperanto/Français

Samsung Cambridge Solution Centre       Tel: +44 1223  434600

Innovation Park, Cambridge CB4 0DS      Fax: +44 1223  434601

ROYAUME UNI                             WWW: http://www.samsung.com/uk

 

 

イメージは差出人によって削除されました。

To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1

 

 

イメージは差出人によって削除されました。

 

To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1

 

 

 

イメージは差出人によって削除されました。

 

To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1