Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
"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>)"
--- This message came from the IEEE 802.11 Working Group Reflector ---Sean,I don't find it odd at all that we are careful to specify the size of the TX and given that we are trying to communicate, the RX (IMHO) is expected to receive that precisely defined frame.As Dan noted, What kind of specification would spend all those paragraphs to describe what is being transmitted and then not expect that they be received.I think this entire argument is a bit of a red herring.FWIW,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 Tue, Feb 8, 2022 at 12:16 PM Sean Coffey <coffey@xxxxxxxxxxx> wrote:--- This message came from the IEEE 802.11 Working Group Reflector ---
Mark,
Thanks. I agree that that first passage implies (arguably, even plausibly) a requirement on receivers to support all MMPDU … MPDU sizes: “supported by the recipient(s) … as specified in Table 9-34”.
It seems a slightly unusual way to state a normative requirement to me, but since I don’t object to the requirement, I’m not complaining.
Regards,
Sean
From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Tuesday, February 8, 2022 11:00 AM
To: Sean Coffey <coffey@xxxxxxxxxxx>; STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11] 11me/D1.0 CID 1479 (Beacon frame size)
> I think receivers should process all valid frames (within reason). Of course!
> But where is the normative requirement that they have to, in order to be compliant with the IEEE 802.11 spec? I don’t see any specific statement anywhere, and apparently neither does Mark H. I’m open to correction; does anyone have a specific page and line number?
11me/D1.0 page 944 line 49:
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.
> However, many of the later amendments have much longer maximum frame sizes. Table 9-34 says that HE PSDUs have a maximum size of 6,500,631 octets.
[Note that this is not a frame size. A PSDU is not a frame.]
> Seems like a lot! Is there really an implied requirement that all HE STAs shave to be able to receive PSDUs of this size? I don’t see any such requirement anywhere (again, open to correction on this).
I don't see such a requirement either, at least in Subclause 9.2.4.8.1
on page 944. The only requirements are on the "maximum MMPDU, MSDU, A-MSDU, and MPDU sizes".
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: Sean Coffey <coffey@xxxxxxxxxxx>
Sent: Tuesday, 8 February 2022 18:08
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 ---
Dan,
I think receivers should process all valid frames (within reason). Of course!
But where is the normative requirement that they have to, in order to be compliant with the IEEE 802.11 spec? I don’t see any specific statement anywhere, and apparently neither does Mark H. I’m open to correction; does anyone have a specific page and line number?
Perhaps we should add one in REVme? It’s a bit late for devices that have already deployed, but by all means let’s fix what we can.
However, many of the later amendments have much longer maximum frame sizes. Table 9-34 says that HE PSDUs have a maximum size of 6,500,631 octets. Seems like a lot! Is there really an implied requirement that all HE STAs shave to be able to receive PSDUs of this size? I don’t see any such requirement anywhere (again, open to correction on this).
To reiterate on the proposed note that started this discussion, it seems fully reasonable to expect (and require) all STAs to be able to receive 2304 octets. I’m against adding a note that discourages transmitters from sending frames of this length.
Regards,
Sean
From: Harkins, Daniel <daniel.harkins@xxxxxxx>
Sent: Tuesday, February 8, 2022 9:38 AM
To: Sean Coffey <coffey@xxxxxxxxxxx>; STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] 11me/D1.0 CID 1479 (Beacon frame size)
Hello,
On 2/8/22, 9:06 AM, "Sean Coffey" <coffey@xxxxxxxxxxx> wrote:
--- 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.
Receivers are not required to process valid frames? What kind of standard is this!? The baseline for interoperability (which is the whole point of doing a standard, right?) is that every valid thing that can be constructed and sent can be received and processed. On top of that we can have requirements to ignore what you don't understand—be conservative in what you send and liberal in what you accept, etc—or drop things that you don't understand or whatever, but if our standard doesn't require that valid frames have to be able to be processed on reception then we have a bigger problem.
Dan.
--
"the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." – Marcus Aurelius
------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
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