In 802.11-2020 we have in 10.25.2:
When a block
ack agreement is established between two HT STAs, two DMG STAs, or two S1G STAs, the
originator may change the size of its transmission window if the value in the Buffer Size field of the ADDBA
Response frame is larger than the value in the ADDBA Request frame. If the value in the Buffer Size field of
the ADDBA Response frame is smaller than the value in the ADDBA Request frame, the originator shall
change the size of its transmission window (WinSizeO) so that it is not greater than the value in the Buffer Size
field of the ADDBA Response frame and is not greater than the value 64.
So there the limit was basically 64, though the first sentence was
somewhat ambiguous ("may change the size" to what exactly? -- this was
fixed by 11ax, as shown below).
In 802.11me/D1.0 we have in 10.25.2:
When a block
ack agreement is established between two HT STAs, two DMG STAs, or two S1G STAs, the
originator may change the size of its transmission window if the value in the Buffer Size field of the ADDBA
Response frame is larger than the value in the ADDBA Request frame, subject to the following
conditions:(11ax)
— The transmission window is not greater than the value in the Buffer Size field of the ADDBA
Response frame.(11ax)
— The transmission window is not greater than 64 if the sender or receiver of the ADDBA Response
frame is a non-HE STA.(11ax)
— The transmission window is not greater than 256 if the sender and receiver of the ADDBA Response
frame are HE STAs.(11ax)
If the value in the Buffer Size field of the ADDBA Response frame is smaller than the value in the ADDBA
Request frame, the originator shall change the size of its transmission window (WinSizeO) so that it meets the
following conditions:(11ax)
— Is not greater than the value in the Buffer Size field of the ADDBA Response frame.(11ax)
— Is not greater than 64 if the sender or receiver of the ADDBA Response frame is a non-HE STA or if
the STAs that establish the block
ack agreement are HT STAs or DMG STAs that are not EDMG
STAs.(11ax)(11ay)
— Is not greater than 256 if the sender and receiver of the ADDBA Response frame are HE
STAs.(11ax)
— Is not greater than 1024 if the STAs that establish the block
ack agreement are EDMG STAs.(11ay)
so I think I was probably confused by the "(11ax)"s and didn't realise
some of the wording was for pre-11ax STAs.
I note, however, that since
an HE STA is an HT STA,
— Is not greater than 64 if the sender or receiver of the ADDBA Response frame is a non-HE STA
or if
the STAs that establish the block
ack agreement are HT STAs or DMG STAs that are not EDMG
STAs.(11ax)(11ay)
— Is not greater than 256
if the sender and receiver of the ADDBA Response frame are HE
STAs.(11ax)
is self-contradictory, and I also note that you can increase to more
than 256 for EDMG STAs if the
rsp size is less than the req (but more
than 256), but not if the
rsp size is more than the req (and more than
256).
Having said that, I also can't find any constraints on the Buffer Size
field, except for HE STAs in the ADDBA response in 26.4.3:
The recipient shall not include in the Buffer Size field of an ADDBA Response frame a value that would
cause the
BlockAck Bitmap length of its block
ack responses to exceed the BlockAck Bitmap length that is
derived by the Buffer Size field of the ADDBA Request frame sent by the originator. When the Buffer Size
field in the ADDBA Request frame is 0, the Buffer Size field of an ADDBA Response frame is in the
range 1 to 64.
There are also various absolute references to 64, e.g. in 10.25.6.4
Scoreboard context control during partial-state operation:
In an HT-immediate block
ack agreement that uses partial-state operation, […]
WinSizeR, […] is set to the smaller of 64 and the value of the Buffer
Size field of the associated ADDBA Response frame that established the block
ack agreement.
(and similarly in 10.25.8.2 Scoreboard context control during GCR block
ack
and 10.25.8.3 Scoreboard context control during GLK-GCR block
ack,
but maybe these are OK since they need to stay backward-compatible
with pre-HE STAs)
and it looks to me as if this is just an oversight, because
10.25.6.3 Scoreboard context control during full-state operation
says:
For each HT-immediate block
ack agreement that uses full-state operation, […]
WinSizeR, […] is set to the smaller of
BitmapLength(11ax) and the value of the
Buffer Size field of the associated ADDBA Response frame that established the block
ack agreement.
So I think that at this stage my proposal would for now be to
just make the following changes:
In 10.25.2 Setup and modification of the block
ack parameters:
When a block
ack agreement is established between two HT STAs, two DMG STAs, or two S1G STAs, the
originator may change the size of its transmission window if the value in the Buffer Size field of the ADDBA
Response frame is larger than the value in the ADDBA Request frame, subject to the following
conditions:(11ax)
— The transmission window is not greater than the value in the Buffer Size field of the ADDBA
Response frame.(11ax)
— The transmission window is not greater than 64 if the sender or receiver of the ADDBA Response
frame is a non-HE STA.(11ax)
— The transmission window is not greater than 256 if the sender and receiver of the ADDBA Response
frame are HE STAs.(11ax)
If the value in the Buffer Size field of the ADDBA Response frame is smaller than the value in the ADDBA
Request frame, the originator shall change the size of its transmission window (WinSizeO) so that it meets the
following conditions:(11ax)
— Is not greater than the value in the Buffer Size field of the ADDBA Response frame.(11ax)
— Is not greater than 64 if the sender or receiver of the ADDBA Response frame is a non-HE STA or if
the STAs that establish the block
ack agreement are HT STAs or
DMG STAs that are not EDMG
STAs.(11ax)(11ay)
— Is not greater than 256 if the sender and receiver of the ADDBA Response frame are HE
STAs.(11ax)
— Is not greater than 1024 if the STAs that establish the block
ack agreement are EDMG STAs.(11ay)
In 10.25.6.4 Scoreboard context control during partial-state operation:
In an HT-immediate block
ack agreement that uses partial-state operation, […]
WinSizeR, […] is set to the smaller of
64BitmapLength and the value of the Buffer
Size field of the associated ADDBA Response frame that established the block
ack agreement.
and postpone consideration of the following to D2.0:
- The hard-wired 64 limits for GCR (which might be OK)
- Constraining the Buffer Size field in the ADDBA
req (to BitmapLength)
- Constraining the Buffer Size field in the pre-HE ADDBA
rsp (to 64),
or presumably for EDMG to 1024
- Once this is done, simplifying the rules above to just "you can set
your
tx window to any value no bigger than in the ADDBA
rsp"
- Whether the transmission window can be increased up to 1024 by
an EDMG STA if the buffer size in the
rsp is greater than in the req
(presumably yes)
- The behaviour for CDMG and CMMG STAs
Thoughts?
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 Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: Tuesday, 5 July 2022 23:15
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] REVme CID 1819 (transmission window)
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Abhi (and for others – note that Abhi’s email may have not been posted to the reflector, so please note it below),
First, note that the cited text is talking about the BA originator, and when/how the originating STA can change its transmission buffer size, based on the response it got, and the types
of STAs involved. I don’t think this directly says anything about how the responder should set the Buffer Size.
Further, I think the question is whether the negotiated buffer size (or more correctly, the Buffer Size field in the ADDBA Response frame) would have already taken these other limitations
(the highlighted bullets, talking about the STA types and their limitations) into account, so those bullets are actually redundant. I think there is agreement that the STAs cannot exceed the assumed limits of the peer, due to the peer’s type. But, isn’t
that already “built-in” to the negotiation and the Buffer Size finally carried in the ADDBA Response? I think this is a different question than what you answered, below.
My personal response to the question that I think the comment is asking is that I can’t find anywhere that says the Buffer Size in the ADDBA Response is actually limited in this way. And,
hence the bullets are still needed here, to prevent the dynamic choice by the BA originator to increase its transmission buffer beyond the capabilities of the responder (or itself, interestingly – that also seems an odd limitation in the spec, but I guess
it doesn’t hurt anything). Do you agree with _that_ assessment, in my response?
Mark
From: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Sent: Tuesday, July 5, 2022 12:46 PM
To: mark.hamilton2152@xxxxxxxxx
Cc: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: RE: REVme CID 1819 (transmission window)
Hi Mark, All,
Sorry for my late response.
I am not convinced that we should delete the cited bullets. They providing guidance on how an HE STA that is a recipient of an ADDBA Request frame responds (based on the type of the originator
that transmitted the request frame). In other words, an HE STA can't specify a value that a non-HE STA can't support.
Hope this helps!
Regards,
Abhi
From:
mark.hamilton2152@xxxxxxxxx <mark.hamilton2152@xxxxxxxxx>
Sent: Friday, June 24, 2022 12:04 PM
To: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: REVme CID 1819 (transmission window)
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Abhi/all,
REVme looked at CID 1819 (copied below) today, as it does not appear to be getting covered in 11-22/0082 (yet) and it looked like it might be easy. However…
The claim, effectively, is that the technical points made in the bullets that are highlighted in the text below are already requirements for the Buffer Size
field in the ADDBA Response that set up the block ack agreement. On suggestion, I looked at the requirements in subclause 26.4.3, but I don’t see any such requirement/restriction on the Buffer Size. In fact, I’m finding other places, for example P2273L63
(D1.0) that have phrases like, “…WinSizeB
is set to the smaller of 1024 and the value of the MPDU Buffer Size field of the ADDBA Response frame that established the block ack agreement.”
(or similar with 64).
So, at this point, I’m not convinced that these bullets are “not necessary”. Do you (or anyone on the reflector) have a reference for where there is a requirement
that the Buffer Size in the ADDBA Response frame is already restricted to 64, 256 or 1024 (in the appropriate situations), as implied in the comment?
Thanks. Mark
|
CID |
Clause |
Page |
Line |
Comment |
Proposed Change |
|
1819 |
10.25.2 |
2260 |
1 |
"-- The transmission window is not greater than the value in the Buffer Size field of the ADDBA |
Delete the last 2 bullets, and similarly delete the last 3 bullets in the next list (lines 15-22) |
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