Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
--- 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>
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>
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>
--- 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>
--- 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!
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 |