I can see Thomas’s point but the problem a lot of us seem to be facing
is that we are not the folks who have been directly affected by RCM.
I, for example, simply assumed that as the MAC address was being used
as the identifier, certain applications/uses did not work anymore or
were rendered useless due to RCM. Now are we saying that, further to
those in 11aq, some rules might be required for RCM to even work in
some important areas, such as “steering” - but, as Thomas says, is
that within TGbh to fix?
We have, for example, on our plate Use Cases such as “pre-association
steering”, “ allowed/disallowed steering”, “Parental controls”,
“managed network steering” and maybe some others. It would be nice to
know in detail how these worked pre-RCM and to understand how
important or not the recognition or pre-recognition of the non-AP STA
is so that we can see if Device-ID solves it, or not. I, and others,
took the approach that if the MAC address can still be the
‘identifier’, then applications that used it before, should be able to
use it again. The big difference being that only the particular
BSS/ESS should recognize that address.
So, I think we do have to at least find out how certain applications
worked “pre-RCM” and what they achieved. If we stick to only the
Device ID scheme then if there were apps that identified the non-AP
STA pre-association, then we have not covered them. That should be
our mission, it is not up to us to judge or, as Dan often said, tell
them how to do it better.
Hence at this stage, I am simply asking if those with the knowledge
can describe clearly what the applications in question really did and
how they did it, then we can see if we need to add another scheme or
schemes to the TGbh Draft.
At the moment I am reading several comments that seem to be saying
that these applications do/did exist, they were useful, and we should
be covering them. So once again, I am asking for some clear details,
from those who know, how these apps worked. As our Chair opined, It
is not up to us to determine the merits and then decide if they are
good applications or not, it is up to us to produce scheme(s) that
enable these and possible other future applications to work.
Thanks, and hoping that those with actual knowledge of these
applications can now chip in with “how they did it” and “why now they
don’t work”. Of course, I could have a stab at how they probably
worked, but I don’t want to do that.
Thanks
Graham
*From:* Thomas Derham <00000ad2eabc2931-dmarc-request@xxxxxxxxxxxxxxxxx>
*Sent:* Thursday, July 28, 2022 1:48 PM
*To:* STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
*Subject:* Re: [STDS-802-11-TGBH] Pre-association identification (was:
[STDS-802-11-TGBH] Mishandled TGbh motion vote)
Thanks Mark, all.
I agree in general with your description of the 11bh scope. However I
think part of the disagreement here relates to the level of detail and
assumptions associated with a given use case.
For example, there is a substantial difference between 11bh addressing
a use case where "a network can influence which BSS in a network an
RCM client initially connects to” (a high level use case)…
vs 11bh addressing a use case where “a network can influence which BSS
in a network an RCM client initially connects to by correlating
multiple probe requests sent by the client and selectively suppressing
probe responses” (a use case and a description of a specific technique
used).
While the specific technique described above has been effective for
legacy clients (and, yes, deployed quite broadly for many years), it
relies on multiple assumptions on client behavior which are not
mandated in the standard and (I am asserting) are no longer valid for
many modern client devices. Specifically, while historically most-all
client devices have performed discovery using exhaustive active scan
(sending probes), this is no longer true due to:
* (a) implementation of power-efficient passive scanning
technologies on client devices, and
* (b) standards-defined rules that constrain probe request
transmission by clients (FILS, 6 GHz, ..), and
* (c) use of out-of-band discovery (and standards-defined rules for
advertisement of such information) such that discovery of a given
BSS also results in discovery of other BSSs
Given this particular technique is “broken” not only by RCM but also
by other capabilities in the standard and other (standards-compliant)
client implementations, I do not think it is in-scope for 11bh to try
to “fix” the RCM aspects of the issue given that, even if those are
fixed, the technique itself will still not be viable.
Rather, we should focus on other (preferably standards-defined)
capabilities to achieve same/similar high-level objective, and ensure
those will work with RCM clients.
Examples of these capabilities include Neighbor Report ANQP element,
association rejection / comeback delay, and AP metrics that influence
clients’ BSS join decisions based on link quality assessment.
These might or might not be 100% equivalent to the legacy techniques
from a functional perspective, but really that is irrelevant given the
above.
Thanks
Thomas
On Jul 27, 2022 at 7:18:15 AM, Mark Hamilton
<mark.hamilton2152@xxxxxxxxx> wrote:
All,
(This time, with my Chair hat on…)
I would just like to note to those following this thread, that we
seem to have left the discussion of understanding this use case
(or these use cases), or discussing whether this is a use case
that used to work (before RCM) and has been broken by RCM. Rather
we now seem to be discussing whether we think it is a good
thing/necessary to make this use case work again, or if some other
approach is preferred.
I don’t mean to pass any judgment on such discussion, but I’ll
note that our scope was to consider use cases that used to work,
and have been broken. Whether the “solution” to those situations
should be to replace the prior operation, or require deployments
to use other alternative methods to accomplish similar results, is
getting into a grey area.
Just something to keep in mind, before we get too far into debate
over preferred ways to address these scenarios.
Mark