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 ---
>
Does anyone know if there is a normative statement that 2304 must be supported, or an implied requirement to that effect, such that these implementations that don’t support it are non-compliant? I think this is this bit of 9.2.4.8.1 (no explicit "shall" because this is Clause 9): 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)). >
If so, then I have a real problem with a Standard that lays out a bunch of requirements, but then has NOTE(s) that say “Oh, by the way, some implementations don’t meet the requirement, so your implementation
(to the reader) had better adapt.” I agree, but we are where we are.
I'm suggesting just a NOTE because (a) we should not break any existing conformant implementations that transmit 2304-octet beacons and (b) in general we should be concerned with conformant implementations, not
nonconformant ones. We do have some other cases of "having said all this, note there are nonconformant
devices around",
e.g. in 10.27.4: NOTE 2—The transmission of frames with L_LENGTH above 2332 octets (i.e., a Data frame containing an unencrypted 2304-octet MSDU) might be accompanied by a protection mechanism (e.g., RTS/CTS or CTS-to-self protection) if it is determined that the use of L_LENGTH fails to effectively suppress non-HT transmissions.
How
this is determined is outside the scope of this standard. Maybe I'm happy to reword the NOTE as: NOTE <n>---Beacon and Probe Response frames might be restricted to 1536 octets if it is determined that longer frames fail to be received.
How this is determined is outside the scope of the standard. I would be happy to have a number other than 1536 (I picked this on the somewhat tenuous basis that it was the 0x0600 boundary between EPD and LPD, and close to the 802.3 maximum frame size). > Why not leave the Standard open and allow external testing and developers to identify the optimum size that they would like to use? Because at the moment the standard allows conformant AP implementations to transmit 2304-octet beacons and requires conformant non-AP STA implementations to receive 2304-octet beacons.
Since in practice my understanding is that there are significant deployments of non-AP STAs that do not support receiving 2304-octet beacons, it would be good to recommend to conformant transmitters to consider interop with
nonconformant receivers, before they go ahead and transmit 2304-octet beacons. 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>
--- This message came from the IEEE 802.11 Working Group Reflector ---
All, Does anyone know if there is a normative statement that 2304 must be supported, or an implied requirement to that effect, such that these implementations that don’t support it are non-compliant?
If so, then I have a real problem with a Standard that lays out a bunch of requirements, but then has NOTE(s) that say “Oh, by the way, some implementations don’t meet the requirement, so your implementation (to the reader) had better adapt.”
On the other hand, if there really is no such a requirement, just a hint/implication that an implementation _should_ handle this, then we are in a different direction. If we’re
in that direction, my only concern with Mark R’s proposal is the quoting of a specific size that might work better, when I’ve seen no evidence supporting that number. I’d rather leave the number out, and just NOTE that using smaller Beacons might be beneficial
due to this problem. (However, I would still struggling internally that we don’t actually have normative text saying what is required – but I agree that would be very difficult to add at this point.) Mark From: Jon Rosdahl <jrosdahl@xxxxxxxx>
--- This message came from the IEEE 802.11 Working Group Reflector ---
Mark, Why not leave the Standard open and allow external testing and developers to identify the optimum size that they would like to use? There is not a reason to limit this in the standard. Kind regards, Jon
----------------------------------------------------------------------------- Jon Rosdahl Engineer, Senior Staff
On Mon, Feb 7, 2022 at 11:09 AM Mark Rison <m.rison@xxxxxxxxxxx> 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 |