To try to make progress, here are possible alternative resolutions:
In 9.6.4.1 delete “(#3172)When Block
Ack operation is modified, only the timeout can be changed.”
In 10.25.2 and 11.5.1 make “All parameters of an agreement may be modified except for the TID.” into a separate para and then append:
Alternative 1:
When an agreement is modified, at the originator any frames in the transmit buffer are discarded (even if they have not been acknowledged), and at the receiver:
·
the scoreboard is cleared
·
the reordering buffer is flushed
·
the replay counter, if any, is not modified
·
the inactivity timeout is restarted
NOTE 1—The originator might wait until any frames in the transmit buffer have been acknowledged before modifying the agreement, to avoid loss of data.
NOTE 2—Modification of a parameter can be requested by the originator, but for all but the starting sequence number the recipient might reject the request (by specifying the current value in the ADDBA Response
frame), or modify differently.
NOTE 3—The effect of modification of any parameter other than the starting sequence number, buffer size and timeout is parameter-dependent.
Alternative 2:
When an agreement is modified, at the originator the transmit buffer is not modified except for possible discarding of frames that precede the new starting sequence number or are beyond the window, and at the
receiver the scoreboard and reordering buffer are not modified except for possible flushing of frames that precede the new starting sequence number or are beyond the window and corresponding updating of the scoreboard; the inactivity timeout is also restarted
at the receiver.
NOTE 1—The originator might choose a new starting sequence number that does not exceed the sequence number of any frame that has not been acknowledged, to avoid loss of data.
The originator and responder might choose a buffer size that does not leave frames beyond it, to avoid loss of data.
NOTE 2—Modification of a parameter can be requested by the originator, but for all but the starting sequence number the recipient might reject the request (by specifying the current value in the ADDBA Response
frame), or modify differently.
NOTE 3—The effect of modification of any parameter other than the starting sequence number, buffer size and timeout is parameter-dependent.
[Alternative 3: pick one of alternatives 1 and 2 above, then make the change in 10.25.1 and just
xref to there from 11.5.1, or vice-versa.]
NOTE 3 on modifying something other than SSN/buffer size and timeout is a bit
of a cop-out but I can't find anything better for now at least.
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: Friday, 23 June 2023 20:24
To: 'tomo.adachi@xxxxxxxxxxxxx' <tomo.adachi@xxxxxxxxxxxxx>; 'STDS-802-11-TGM@xxxxxxxxxxxxxxxxx' <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)
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
“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