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 ---
I will agree and reinforce the "the as last resort" and challenge it even then it probably signals a problem. The primary job of TG is to reach consensus.  The resolution says the TG has failed to do it's job.   To give up at this stage (D1) seems like tossing away a lot of good work.  If the comment contains a proposed change with which the consensus (75% + 1 vote) disagree with, and the group can articulate a valid technical reason for the position, then that is consensus to reject the proposed change.  
FWIW
Ben



From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Wednesday, September 7, 2022 12:42 PM
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 ---

I do not think "The TG could not reach consensus on a resolution to this comment." is an appropriate resolution here.

 

13/0230r5 (802.11 Comment Resolution – a Tutorial) indicates that such a

resolution can be used when:

 

–         The CRC has considered one or more other resolutions that attempt to satisfy the comment, but no such resolution has received 75% approval.

–         It should be recorded in the minutes what other resolution(s) have been considered, together with the results of any straw polls or motions on those alternative solutions so that the commenter can understand that this solution was used after due diligence to satisfy the comment.

 

However, no other resolution that attempts to satisfy the comment

has been considered, I think.

 

11/1625r2 (802.11 Comment Resolution Guide) further clarifies that:

 

“cannot reach consensus” should be a resolution of last resort. It also fails the “responsiveness” test. It should be used only when other resolutions have been considered and debated and no consensus has been discovered for any other resolution.   It should not be used as a shorthand for “we can’t be bothered to find a proper resolution” or “we don’t want to change the draft and won’t tell you why”.   Over-use of this resolution is likely to lead to increased negative votes and hostile debate in the WG.

 

The WG chair has also confirmed by email that:

 

the “lack of consensus” resolution should be used very sparingly, and typically late in the recirculation process.

 

We are at D1.0 so I think going to "no consensus" based on an

accept/reject SP is inappropriate.  If a D1.0 comment can just be

resolved as "no consensus" on such a basis then anything could

be so resolved and the comment resolution process is essentially

rendered useless.

 

"no consensus" should not mean "no consensus on making the

proposed change", it should mean "no consensus on making any of

multiple changes carefully considered by the group".

 

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.hamilton2152@xxxxxxxxx <mark.hamilton2152@xxxxxxxxx>
Sent: Wednesday, 7 September 2022 19:50
To: Mark Rison <m.rison@xxxxxxxxxxx>; STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11] 11me/D1.0 CID 1479 (Beacon frame size)

 

All,

 

For my action item, I have the following, and am open to comments/alternate suggestions:

Proposed: REJECTED: The TG could not reach consensus on a resolution to this comment.  Concerns were raised that even though this is a NOTE, it _implies_ that for the sake of interoperability, implementations need to (must/shall?) restrict Beacons to 1536 octets.  Also, the same concern/restriction seems to apply to Probe Responses.  However, restricting Beacons and Probe Responses is becoming problematic with the addition of information, such as Multiple BSSID elements (which is helping with the number of Beacons that need to be transmitted, and similar combination signaling that will be heavily leveraged in 11be).  A straw poll was held on Aug 15 TGme teleconference: "Are you okay with ACCEPT as the resolution to CID 1479?" with results: 4y, 4n, 1a.

 

Mark

 

From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Wednesday, September 7, 2022 12:36 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 ---

I was reminded that the minutes say:

 

7.7.4.4 ACTION ITEM #13: – Michael MONTEMURRO – Schedule CID 1479 (MAC) discussion during the Sept 802W Interim

7.7.4.5 ACTION ITEM #14: – Mark HAMILTON – Craft a Reject reason for CID 1479 (MAC) for consideration.

7.7.4.6 ACTION ITEM #15: – Mark RISON – Post details of CID 1479 (MAC) to the WG Reflector again to see if there is any agreement or an alternative proposal.

 

So I'm just doing my ACTION ITEM #15.  In parallel, MarkH can of course

do his ACTION ITEM #14.

 

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: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Wednesday, 7 September 2022 18:37
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, 

 

We straw polled the resolution on Aug 8 and then revisited the discussion on Aug 23 during the REVme adhoc. There

is no support for adding a note so Mark Hamilton was actioned with crafting a rejection reason.

 

Thanks,

 

Mike

 

On Wed, Sep 7, 2022 at 1:18 PM Jon Rosdahl <jrosdahl@xxxxxxxx> wrote:

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

I would not be in favor of adding a NOTE.

Jon

On Sep 7, 2022, at 10:44 AM, Mark Rison <m.rison@xxxxxxxxxxx> wrote:

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

I'm relaunching this thread to see if anyone can suggest some wording

that would find consensus.

 

Based on the existing note in 10.27.4, which is a similar issue of something

being allowed by the spec but causing interop problems:

 

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.

 

how about:

 

NOTE <n>---The transmission of Beacon and Probe Response frames might be restricted to fewer than 2304 octets

if it is determined that the use of long frames fails to effectively achieve reception by all STAs.  How this is

determined is outside the scope of the standard.

 

?

 

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: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Wednesday, 9 February 2022 21: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 ---

Hi Mark,

 

There's no circular argument as far as I'm concerned. On the topic of this thread and the CID in question, I believe I've been clear in stating that I do not support resolving the 

comment by adding a note.

 

Cheers,

 

Mike

 

On Wed, Feb 9, 2022 at 4:04 PM Mark Rison <m.rison@xxxxxxxxxxx> wrote:

We're going in circles.

 

1) A NOTE does not, repeat not, introduce any new requirement.  If you

don't care about interop you can continue to use 2304-octet beacons.

 

2) The requirement to use the OFDM (L_)LENGTH as part of CCA has been

in the standard since 802.11-2003 and yet we felt the need to add the

NOTE 2 in 10.27.4 to point out interop problems.

 

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: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Wednesday, 9 February 2022 19:14
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,

 

Even though it's a note, it introduces a new requirement that if you want to interoperate with some WLAN equipment, you need to limit your Beacon and Probe Response frames 

a size less than the 2304 octets.

 

The 2304 octet limit on frame size has been in the standard since 802.11-1999 so in my opinion, the requirement is clear and the note is not required.

 

Cheers,


Mike 

 

 

 

 

 

On Wed, Feb 9, 2022 at 1:51 PM Harkins, Daniel <daniel.harkins@xxxxxxx> wrote:

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

 

 

On 2/9/22, 10:43 AM, "Mark Rison" <m.rison@xxxxxxxxxxx> wrote:

 

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

By definition a NOTE introduces no requirement.

 

  But it could introduce confusion. The nuance around "by definition" may, in fact, be lost on Joe Random reader-of-the-standard who will implement undesirable things because of it.

 

  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

 

 

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: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Wednesday, 9 February 2022 17:32
To: Mark Rison <m.rison@xxxxxxxxxxx>
Cc: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] 11me/D1.0 CID 1479 (Beacon frame size)

 

Hi Mark,

 

I disagree. 

 

Your proposed note introduces a new implicit requirement to restrict beacons to 1536 octets (or whatever the number is).

 

The note in the standard say that if you transmit a PPDU of length greater than 2304, under certain circumstances beyond the scope of the standard, you may want to protect the frame. There is no new requirements introduced and this behavior is already defined in the standard.

 

Cheers,


Mike

 

On Wed, Feb 9, 2022 at 12:14 PM Mark Rison <m.rison@xxxxxxxxxxx> wrote:

The situation is exactly parallel.  The only reason STAs might need to use

a protection mechanism to protect PPDUs that have an L_LENGTH above 2304

is that some implementations fail to take PPDUs with such L_LENGTHs into

account in their CCA.  So the NOTE is suggesting there might be a need for

a workaround.  This is exactly the same as suggesting you might need to

keep your beacon size down, as a workaround to cope with implementations

that choke on big 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: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Wednesday, 9 February 2022 16:06
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 ---

Hey Mark,

 

The way I interpret that note is that a STA might use a protection mechanism to protect frames that are longer than 2304 octets, but the mechanism that it uses to determine that the transmission needs protection is beyond the scope of the standard (i.e. there are no requirements on how a STA determines to use protection).

 

I don't see how this is in any way similar to the note you propose.

 

Cheers,

 

Mike

 

On Wed, Feb 9, 2022 at 10:42 AM Mark Rison <m.rison@xxxxxxxxxxx> wrote:

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

 

> > > I disagree with adding either of the notes that you have proposed because it justifies the behaviour of a poor implementation of the standard 

> > > I'm not sure there is a problem with the standard that the commenter points out. The commenter is pointing out problems with implementations. The implementation should be fixed, not the standard.

 

> > So we should delete 

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

 

> Why should we delete the NOTE -- 2 that you quote? What is the problem? 

 

It's a NOTE that was added to point out problems with implementations,

not with the standard.

 

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: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Wednesday, 9 February 2022 15:35
To: Mark Rison <m.rison@xxxxxxxxxxx>
Cc: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] 11me/D1.0 CID 1479 (Beacon frame size)

 

Hi Mark,

 

Why should we delete the NOTE -- 2 that you quote? What is the problem? 

 

Note that this has nothing to do with the comment.

 

Cheers,

 

Mike

 

On Wed, Feb 9, 2022 at 10:30 AM Mark Rison <m.rison@xxxxxxxxxxx> wrote:

So we should delete

 

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.

 

at 2302.43, correct?

 

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: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Wednesday, 9 February 2022 14:57
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,

 

I disagree with adding either of the notes that you have proposed because it justifies the behaviour of a poor implementation of the standard.

 

I'm not sure there is a problem with the standard that the commenter points out. The commenter is pointing out problems with implementations. The implementation should be fixed, not the standard.

 

Cheers,

 

Mike

 

On Wed, Feb 9, 2022 at 4:53 AM Mark Rison <m.rison@xxxxxxxxxxx> wrote:

--- 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>
Sent: Tuesday, 8 February 2022 21:33
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 ---

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>
Sent: Tuesday, February 8, 2022 1:10 PM
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 ---

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:

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

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

http://ext.w1.samsung.net/mail/ext/v1/external/status/update?userid=cambridge.it&do=bWFpbElEPTIwMjIwMjA5MDk1MzQ1ZXVjYXMxcDFiZmEwNzQ3MzM4NTAwMGNkYWNiYmU0ODRiMTRlNjYzNSZyZWNpcGllbnRBZGRyZXNzPVNURFMtODAyLTExQExJU1RTRVJWLklFRUUuT1JH

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

http://ext.w1.samsung.net/mail/ext/v1/external/status/update?userid=cambridge.it&do=bWFpbElEPTIwMjIwMjA5MTUzMDU2ZXVjYXMxcDE4NDUxNDdjOWY5NGI0NzU1ZDU5ZWY2YWUzNmE4MjZkMiZyZWNpcGllbnRBZGRyZXNzPW1vbnRlbXVycm8ubWljaGFlbEBHTUFJTC5DT00_

 

http://ext.w1.samsung.net/mail/ext/v1/external/status/update?userid=cambridge.it&do=bWFpbElEPTIwMjIwMjA5MTU0MjU3ZXVjYXMxcDE0NjAyMTY2MDhlYzlhOTNlZTRlYTE2ODhkMTgzZGMzNCZyZWNpcGllbnRBZGRyZXNzPW1vbnRlbXVycm8ubWljaGFlbEBnbWFpbC5jb20_

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

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

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