| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
All, I have some thoughts on our discussion in TGbh this morning, that I didn’t try to get into the discussion (too hard to chair and try to inject technical opinion at the same time, on topics that are this lively – and thank you all for the lively discussion!). TL;DR: I support 11-23/1314’s proposal, only in so far as adding a Measurement ID to those Probe Requests which are in response to a Beacon Report Request, and keeping the Measurement ID small. “Keep it simple.” My thinking…: First, I am having trouble trying to relate the comments, to the discussion and proposal. The comments both talk about use case 4.8 (from our tracking document). As a reminder, use case 4.8 is about the fact that client devices are randomizing their MAC address when sending Probe Requests. The use case describe probing in support of a Beacon Request as one example (an “e.g.”), but that is not the whole scope of the problem – the issue of the infrastructure learning about the client’s RF situation, in order to help with client steering to the best AP, is actually much more likely for clients that are just scanning, and not scanning specifically to do a Beacon Report. That said, in our discussions, a concern was raised about infrastructure doing this sort of “client steering”, or at the very least it should only be when the client wanted steering advice in which case it could use a consistent MAC address intentionally to help. As a result, we left this feature in the tracking document as “In scope”, but “Perhaps only recommendations in Spec.” (recommendations, as opposed to making this be part of the reason for a new feature). So, in short, I’m torn about the importance of this solution, and I’m also not very clear about the scenarios for when it would/could be used (just for Beacon Report, or also for regular scanning). Anyway, I will take a position that it would be a “nice to have” if our infrastructure (APs) could tell when a Probe Request is coming from a device that is scanning because it was sent a Beacon Report Request. That information, and being able to correlate the receiver information we have from the Probe Requests that come in, would be one more bit of benefit to making better roaming suggestions to the client. I will further this position by saying that I think trying to get clients to provide any kind of identifying information in general/scanning Probe Requests is just not going to happen. First, many clients don’t even do active scanning anymore (or rarely). And, when they do, they are very privacy conscious of the information in those Probe Requests. And, it is too expensive (computation and OTA bandwidth) to provide identification that is encrypted sufficiently (and differently on each Probe Request?) to remove the privacy concerns. So, my view is that we give up on trying to identify such clients. That brings me back to using this only for Beacon Report probing. For that, it really is only necessary for the “Option 2” method, and for the Measurement ID to be a very small “token”. I don’t see any reason that this would be exposing a client privacy concern, since any third-party can tell that there is _some_ client at its location sending frames, anyway – and the concept that a third-party could correlate the Probe Requests to that location (without any further information about the client) is not providing any new/sensitive information. By similar logic (what a third-party can really learn from sniffing this), I don’t see any reason to change the device’s RMA/IRM during this scanning scenario. The device will be in a location, and sending all its traffic within the association context using its current MAC address. For a third-party to notice that the STA is also sending a few Probe Requests with that same address is not exposing any information that I can see. Thus, I don’t think there is any point in using (a new?) IRM for this. So, in the end, I come around to supporting the proposal in 11/23/1314 for CIDs 20 and 89, with Option 2, but with the Measurement ID element only (and we should make the Measurement ID explicitly both small (a couple octets at most) and will _not_ be an opaque identifier). I would then resolve the CIDs 20 and 89 by noting that while use case 4.8 is covering identification information in Probe Requests broadly, the mechanism that is proposed by the TG is only to address the correlation between Probe Requests for the purpose of responding to a Beacon Report Request. Mark To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1 |