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