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

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

Maybe this Friday (CID 4341 is on the agenda) we need a straw poll:

Do you think that when a BA agreement is modified, any frames

that have been transmitted at least once are discarded at the

originator (even if an acknowledgment has not been received)

and cleared in the recipient scoreboard (even if they were

received and acked)?

The SP result was 1Y/2N/6A, so not dramatically conclusive! I invite

those who voted Y or N, or indeed anyone with an opinion on the subject,

to explain their choice, either by email to me or on the reflector, so

we can try to come to some consensus.

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
Sent: Wednesday, 21 June 2023 14:55
To: 'tomo.adachi@xxxxxxxxxxxxx' <tomo.adachi@xxxxxxxxxxxxx>; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Cc: M Montemurro (montemurro.michael@xxxxxxxxx) <montemurro.michael@xxxxxxxxx>
Subject: RE: 11me/D3.0 CID 4341 (what BA params can be modified)

“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.

Hm, I see this is a possible interpretation, but personally I think

the first sentence was not written with BA modification in mind.

I think the first sentence was just trying to say "BA starts with

ADDBA req/rsp".

Re the second sentence, the originator could just set SSN = 82

in the ADDBA req, and so avoid transmitting two different frames

with SSN 81 in quick succession. But irrespective of whether it

sets SSN = 82 or 21 it has to be happy to potentially lose the

frames with SN 21-81 ("potentially" because maybe they were received

but the ack was lost).

Maybe this Friday (CID 4341 is on the agenda) we need a straw poll:

Do you think that when a BA agreement is modified, any frames

that have been transmitted at least once are discarded at the

originator (even if an acknowledgment has not been received)

and cleared in the recipient scoreboard (even if they were

received and acked)?

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.

I can imagine situations in which the originator wants to change

the timeout, or one of the zillions of other things associated with

the BA agreement (e.g. TCLAS?), even though there are frames that

have not been acked. But this goes back to the original question:

what can be modified when BA is modified, and how exactly does it

work w.r.t. the previous state?

Yoroshiku onegaishimasu,

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: Friday, 16 June 2023 11:46
To: Mark Rison <m.rison@xxxxxxxxxxx>; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: RE: 11me/D3.0 CID 4341 (what BA params can be modified)

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

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

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?).

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