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

Re: [STDS-802-11] Channel Switch Count question/suggested change in REVme



--- This message came from the IEEE 802.11 Working Group Reflector ---
FWIW...negative requirements are often a problem. Usually not verifiable (one can not show something never happens) and often cause confusion and/or heartache (sometimes not immediately).  Absence may make the heart grow fonder but is usually harder to verify in all cases.  And according to the IEEE-SA style manual, "may not" is invalid.  "may" is equivalent to "may or may not".  "shall not" should be a red flag to poor specification, and "may not" is simply wrong. 
Just a general observation....
Ben


From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Tuesday, August 30, 2022 9:24 AM
To: STDS-802-11@xxxxxxxxxxxxxxxxx <STDS-802-11@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11] Channel Switch Count question/suggested change in REVme
 
--- This message came from the IEEE 802.11 Working Group Reflector ---

> I am concerned that removing the “… it shall not include a Max Channel Switch Time element in a Beacon or Probe Response frame” is adding a new requirement that an AP that sends a Channel Switch Announcement with the Channel Switch Announcement element set to 0 shall include a Max Channel Switch Time element.

 

I don't buy this at all.  Not saying "it shall not include X"

does not imply "it shall include X".  Otherwise every element would

have to have hundreds of "it shall not include X"s specified.

 

> Alternative proposal: change the clause to: “… it may shall not include a Max Channel Switch Time element in a Beacon or Probe Response frame”.
> Note: the 802.11 Editorial Style Guide – states that “may not” is ambiguous, however in this requirement I believe it is not ambiguous, as when this may applies is clearly stated in the first part of this requirement: When the Channel Switch Announcement element is 0.

 

I would not want a "may not".  I suppose I could live with a

"it may include a MCSTe".

 

> Rejected: There is no known benefit of including the Max Channel Switch Time element in a Beacon or Probe Response frame with a Channel Switch Count field of the Channel Switch Announcement element set to 0.

 

I think there are at least two benefits to the MCSTe:

1) for the STA to be able to lengthen any "AP has gone away, time to roam" timeout

2) for the STA to be able to decide that waiting for the AP to turn up would spoil its latency/throughput expectations, and to immediately roam to another AP instead

 

Both of these would be applicable in the zero count case.

 

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: Joseph Levy <000019588066c6b7-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, 29 August 2022 17:21
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] Channel Switch Count question/suggested change in REVme

 

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

Dear All,

 

I am concerned that removing the “… it shall not include a Max Channel Switch Time element in a Beacon or Probe Response frame” is adding a new requirement that an AP that sends a Channel Switch Announcement with the Channel Switch Announcement element set to 0 shall include a Max Channel Switch Time element.  While this may have some benefit to the non-AP STAs, informing it of the maximum time the AP will take to complete the channel switch, this does put a “new” requirement on the AP to provide this information.  I don’t know if this something an AP can do with minimum impact.  Also, this is a change in AP behavior and existing APs will not follow this new behavior as the current requirement clearly states that the element is not included. Therefore it is probably best to not require this a new behavior.  If the benefit of adding this additional information to the Channel Switch Announcement is viewed as beneficial it may be preferred to simply allow the Max Channel Switch Time element to be included, at the discretion of the AP, by replacing the “shall” with a “may”.  

 

Alternative proposal: change the clause to: “… it may shall not include a Max Channel Switch Time element in a Beacon or Probe Response frame”.
Note: the 802.11 Editorial Style Guide – states that “may not” is ambiguous, however in this requirement I believe it is not ambiguous, as when this may applies is clearly stated in the first part of this requirement: When the Channel Switch Announcement element is 0.

 

This alternative proposal allows the current behavior of the AP of not including the Max Channel Switch Time element and the proposed new behavior of including the Max Channel Switch Time element to both be allowed. 

 

Also it should be noted that there are benefits of having all APs behave in the same manner and existing APs currently follow the requirement not to include a Max Channel Switch Time element.  If it is viewed that the inclusion of the element is beneficial to non-AP STAs then this new behavior should be allowed, however if there is no benefit for this new behavior then the comment should be rejected. 

Rejected: There is no known benefit of including the Max Channel Switch Time element in a Beacon or Probe Response frame with a Channel Switch Count field of the Channel Switch Announcement element set to 0.

 

Regards,

Joseph

From: Lumbatis, Kurt <kurt.lumbatis@xxxxxxxxxxxxx>
Sent: Monday, August 29, 2022 10:04 AM
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] Channel Switch Count question/suggested change in REVme

 

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

I am fine with those changes.

 

Kurt Lumbatis

Distinguished Software Engineer

DOCSIS CPE R&D SW Architecture (Wi-Fi)

 

ARRIS AND RUCKUS HAVE JOINED COMMSCOPE

 

3871 Lakefield Dr, Suwanee, GA 30024 USA

Office: +01-678-473-2921

 

From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: Saturday, August 27, 2022 3:51 PM
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11] Channel Switch Count question/suggested change in REVme

 

 

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

All,

 

I’m looking for those interested in Channel Switch Announcement procedures, to consider a change being proposed in REVme (see below).

 

Does anyone have a comment/concern with this proposed change?

 

Thanks.  Mark

 

 

1812

Mark RISON

2799.35

11.8.8.2

"When the AP sets the Channel Switch Count field of the Channel Switch Announcement element to 0, it shall
not include a Max Channel Switch Time element in a Beacon or Probe Response frame(#6)." -- why not?  Even if you have to switch immediately, the AP might not be available on the new channel for a while

Delete the cited text

 


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