Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
--- This message came from the IEEE 802.11 Working Group Reflector ---
Thanks for the added info. If we know from experience that implementations commonly fail to 2304-octent beacons, whether documented (or sanctioned) by some other organization or not, it would be appropriate IMO to state a recommendation in the standard -not
a note.
It sounds like a "should" is needed. While leaving the means of determination outside the scope of the standard is a time honored tradition in 802, we should at least be sure there is a possible way to do it. I'm not sure how the device generating beacons
determines if those are received or not (due to my lack of understanding, not any shortcoming in the standard).
FWIW I'm usually an advocate of aligning the standard with reality as we understand it 😉. It's always that "as we understand it" part that hangs me up.
Ben
From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Wednesday, February 9, 2022 1:53 AM To: STDS-802-11@xxxxxxxxxxxxxxxxx <STDS-802-11@xxxxxxxxxxxxxxxxx> Subject: Re: [STDS-802-11] 11me/D1.0 CID 1479 (Beacon frame size) --- This message came from the IEEE 802.11 Working Group Reflector ---
> One of the first: Is support for beacon frames that are 2304 octets in length required?
As I said in my earlier email, per 11me/D1.0 page 944 line 49 I think it is:
The maximum length of the frame body is constrained or affected by the following: — The maximum MMPDU, MSDU, A-MSDU, and MPDU sizes supported by the recipient(s) for the PPDU format in use, as specified in Table 9-34 (Maximum data unit sizes (in octets) and durations (in microseconds)).
where said table says that for a Non-HT non-VHT non-HE(11ax) non-S1G non-DMG PPDU and non-HT duplicate PPDU and an HT PPDU the maximum MMPDU size is 2304 octets.
> If the answer is NO, then a note reminding the reader not to assume a beacon of length 2304 will be received and processed by all conforming devices is allowed by the IEEE SA Standards Board Operations Manual (6.4). I would suggest a cross reference to the clause in the standard that states the requirements for beacon frame support. If we can't find that then the answer is "we don't know". A clarifying note is NOT appropriate in that case. > If the answer is "Yes it is required" but we know from experience that there are implementations that are not conforming to the standard, this leads to the question "is this implementation reality OK?". If the answer is "yes" (e.g. some other requirement is defined in a specification from an external industry alliance that is commonly used as the reference for what is acceptable in the market, hint..) then the correct course of action is change the standard to agree with the accepted practice. Then we are back to the first case. This is also the best course if the answer is "we don't know": having ambiguous requirements is something we should fix during a revision. Taking the fix from accepted practice is ideal.
I do think we know from experience that there are implementations that cannot cope with 2304-octet beacons, but I don't think there is any public reference for a smaller limit by another SDO.
I could probably live with something more waffly like:
NOTE <n>---Beacon and Probe Response frames might be restricted to fewer than 2304 octets if it is determined that longer frames fail to be received. How this is determined is outside the scope of the standard.
at least until such time as a lower industry limit becomes public.
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: Benjamin Rolfe <ben@xxxxxxxxxxxxxx>
--- This message came from the IEEE 802.11 Working Group Reflector --- Thank you Mike, Now I am confused and know why 😉. The comment is asking for a clarification. The added note has "might not" and other words that raise many more questions than answers. One of the first: Is support for beacon frames that are 2304 octets in length required? If the answer is NO, then a note reminding the reader not to assume a beacon of length 2304 will be received and processed by all conforming devices is allowed by the IEEE SA Standards Board Operations Manual (6.4). I would suggest a cross reference to the clause in the standard that states the requirements for beacon frame support. If we can't find that then the answer is "we don't know". A clarifying note is NOT appropriate in that case. If the answer is "Yes it is required" but we know from experience that there are implementations that are not conforming to the standard, this leads to the question "is this implementation reality OK?". If the answer is "yes" (e.g. some other requirement is defined in a specification from an external industry alliance that is commonly used as the reference for what is acceptable in the market, hint..) then the correct course of action is change the standard to agree with the accepted practice. Then we are back to the first case. This is also the best course if the answer is "we don't know": having ambiguous requirements is something we should fix during a revision. Taking the fix from accepted practice is ideal.
Just one opinion...but as one who is just coming back up to speed on 802.11 and having missed a lot of history, the note doesn't seem to clarify but only further confuse the user. And spending a few minutes searching the standard I couldn't come up with an answer, as illustrated by this discussion, which further suggests to me there is a fix needed in normative specification somewhere. FWIW Thanks Ben
From: M Montemurro <montemurro.michael@xxxxxxxxx>
--- This message came from the IEEE 802.11 Working Group Reflector --- Hi All,
So to bring this thread back on track, the question is whether you support resolving the following comment with the proposed change below: "It is not clear that all implementations support Beacon frames that are 2304 octets long
I would like to propose the following change:
After the table in 9.2.4.8.1 add "NOTE <n>---Some implementations might not support 2304-octet Beacon or Probe Response frames. Restricting Beacon and Probe Response frames to a maximum of 1536 octets might improve interoperability." and in the "MMPDU size" cell add "(see NOTE <n>)"
Personally I do not agree with adding the note.
Cheers,
Mike
On Tue, Feb 8, 2022 at 4:00 PM Jon Rosdahl <jrosdahl@xxxxxxxx> wrote:
To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1 To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1 To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1 To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1 |