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

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

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

 

Mike, Mark, all,

 

I agree with Mark that there is no explicit requirement that a STA has to be able to receive all possible legal frames successfully. Minimum receive sensitivity requirements imply that STAs have to be able to receive certain lengths (1024 octets, 4096 octets, etc.), and perhaps there are implied requirements to be able to receive lengths that are used in some control frames, but where is the requirement that the receiving STA has to be able to process all frame lengths (or more to the point, all possible frames of all possible lengths) successfully?

 

I’d describe it as an expectation, rather than a requirement, that receivers have to be able to process valid frames. However, I don’t think it’s helpful to add a note here, and especially not the proposed note, which seems to place the onus on transmitters.

 

Regards,

 

Sean

 

From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Tuesday, February 8, 2022 8:46 AM
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 ---

Hi Mark,

 

In REVme D1.0 clause 9.1 (see 896.15)"

"A STA shall transmit frames using only the frame formats described in Clause 9 (Frame formats)."

 

In 9.2.1, it states:

"Each frame consists of the following basic components:

a) (#290)A MAC header, which comprises frame control, optional duration (not in PS-Poll frames),

address, optional sequence control information, optional QoS Control information (only in QoS

Data frames), and optional HT Control fields (only in +HTC frames);

b) A variable length frame body, which contains information specific to the frame type and subtype;

c) An FCS, which contains a 32-bit CRC based on ITU-T Recommendation V.42 [B54] (see 9.2.4.9

(FCS field)).

 

Table 9-34 gives the maximum lengths of the variable length frame. 

 

Given that clause 9 is all normative and the requirements above, table 9-34 is normative so its a requirement for a compliant STA to support frames up to the maximum length.

 

You can't define a frame format without specifying its length. If the transmitter can send that length of frame, the receiver better be able to receive that length of frame.

 

If some other organization wants to agree to additional requirements on implementations for interoperability, that's fine. But in my understanding, the requirements are clear.

 

Cheers,

 

Mike

 

Cheers,

 

Mike

 

 

 

On Tue, Feb 8, 2022 at 11:09 AM <mark.hamilton2152@xxxxxxxxx> wrote:

Mike,

 

Really not trying to be argumentative… !  But, I can’t find anything that says (or even implies) that 2304 must be supported on recieve.  The table(s) we’re looking at in this comment, for example, all seem to imply this is a maximum size, which could be interpreted as a requirement on the TXer to never send anything bigger than that.  But, I’m having a hard time finding a statement (or implied statement) that I can point to, that says an RXer must support receiving the maximum size.  If you can find such a hint, I would really appreciate that!

 

Mark

 

From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Tuesday, February 8, 2022 7:16 AM
To: mark.hamilton2152@xxxxxxxxx
Cc: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] 11me/D1.0 CID 1479 (Beacon frame size)

 

Hi Mark,

 

All  frame format requirements are normative so 2304 must be supported. That has always been the case. A STA that does not support 2304 is non-compliant.

 

Cheers,

 

Mike

 

On Mon, Feb 7, 2022 at 8:29 PM Mark Hamilton <mark.hamilton2152@xxxxxxxxx> wrote:

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

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


------Please consider the environment before printing this e-mail.

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