Re: [STDS-802-11] 11me/D1.0 CID 1479 (Beacon frame size)

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

> 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>
Sent: Tuesday, 8 February 2022 01:29
To: 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 ---

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>
Sent: Monday, February 7, 2022 3:08 PM
To: 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 ---

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
IEEE 802 Executive Secretary Qualcomm Technologies, Inc.
office: 801-492-4023                  10871 North 5750 West
cell:   801-376-6435       Highland, UT 84003

A Job is only necessary to eat!
A Family is necessary to be happy!!

On Mon, Feb 7, 2022 at 11:09 AM Mark Rison <m.rison@xxxxxxxxxxx> wrote:

--- This message came from the IEEE 802.11 Working Group Reflector ---

Following discussions in TGme today, re the following comment on 11me/D1.0:

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>)"

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 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