| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Mark, On 9/1/23, 11:20 AM, "Mark Hamilton" <mark.hamilton2152@xxxxxxxxx> wrote: Dan, below. Mark From: Harkins, Dan <daniel.harkins@xxxxxxx>
Hi Mark, On 9/1/23, 10:25 AM, "Mark Hamilton" <mark.hamilton2152@xxxxxxxxx> wrote: Dan/Jay/all, I might be missing some of what Jay is trying to point out – please respond if there is more, Jay. But, I have a couple comments, if I can jump into this thread:
-
@Harkins, Dan: Jay pointed out below what I think is just a typo: The
frames are called “Beacon Request” and “Beacon Report”. There is no “Beacon Report Request” – I think you meant just “Beacon Request”. Thank you, yes.
-
Dan asks below: >>> “When STA1 sends a probe request to AP2 what shared state is it creating?”
o
I would respond: The state is that STA1 is able to hear both AP1 and AP2, and some information about the link quality between STA1 and each of those APs. This state information can be gathered by both the AP and the STA, during
a Beacon report scanning (probing). The STA will report the information in the actual Beacon Report. The APs may also create their own state information based on the reception of the Probe Requests, but that only works if the APs can identify the Probe Request(s)
that are from STA1. That's not shared state. Gathering information about RF conditions through probing or scanning or whatever may create state on the STA doing the probing and scanning but the AP doesn't create the same state and
bind the STAs MAC address to it. [[MAH]] Dan, nothing in the 11aq text says that the state has to be “shared”. It’s just “state on an AP” and “state bound to a MAC address”, and both of those apply here. I think you're just parsing words here. What is the point of creating state bound to a MAC address on an AP? Why would a STA "configure its MAC address according to the rules of the local address space prior to the start of the transaction"
if it didn't have any knowledge of the state or share the state? How would it use that state? It doesn't even know whether it is generated or not! That can't be transactional.
There's a reason this text exists. The reason is to allow a STA to access state on an AP that it created earlier. If it doesn't know that state was created in the first place or know anything about what that state looks like then there's
no point in applying this section. Is it "state on an AP"? Yea, I guess. Is it "state bound to a MAC address"? Well, that depends on what the AP is doing with that state, we don't know and neither does the STA. But is it usable by the STA at some future time
such that it would want to change its MAC address back to use it? Absolutely not. It has nothing to do with 12.2.10. When the state is shared it becomes useful for the STA. It does a transactional exchange that results in state being created on the AP. The STA knows about this state and what it can be used for. That is the sharing.
(I know that the 12.2.10 text ended up getting massaged during the RAC wars after sponsor ballot, so there are lots of fingerprints in it, but the original text was mine. The intent was to indicate to STAs that if they create state on an
AP and want to use it in the future they have to return back to the MAC address they used when it was created. That's the whole point).
For the purposes of band steering an AP may create state regarding who it is that's probing the AP in an effort to not answer if the desire is to steer the STA to another band but that is not state that the STA
even knows is being created nor is it state that the STA can refer to later with a particular MAC address. But in general I don't believe APs fill up memory with "I got probed by MAC-X" state because they get probed a lot.
[[MAH]] I agree with you here, although I’ll note that some APs do keep some of this in memory (with a quick FIFO flush). However, in this case were talking about an AP that does a specific Beacon Requests,
so it is likely to store the state for these responses (at least long enough to make a roaming recommendation decision), but of course only if it can correlate the Probe Requests. AP1 did the beacon request. That is to an associated STA. The question is, when the STA goes off and probes AP2 is it accessing any state that was created with the MAC address used while associated to AP1? No. The probing is not transactional.
It gathers information, sure. The STA gets some environmental information it can send back to AP1 but AP2 does not need to be aware of this and the STA does not have to use the MAC that is associated to AP1 in order to probe to AP2. The probing is not transactional.
If you think it is, then what would the STA do in the future with AP2 using whatever state you think AP2 created as a result of that probe? What would compel the STA to use a particular MAC address when interacting with AP2? When talking about these transactional exchanges, they are things that create the same stuff on both the STA and AP. Think of SAE. Or FILS. Pre-auth is another example of creating shared state between a STA and
and AP that can be referred to later by using the MAC bound to that state. Just gathering some requested environmental data is not a transactional exchange because there's really no transaction made when gathering said data. Probe request, probe response.
End of exchange. No transaction, no state retained. There is nothing the STA expects the AP to have that it would use on a future connection. But with SAE there is. There is an exchange of 802.11 authentication frames and the end result should be a PMKSA on
both the STA and AP. When the STA wants to use that state to association it must revert back to the MAC address it used to create that PMKSA. A STA could do SAE with AP1 using MAC1, do SAE with AP2 using MAC2, and SAE with AP3 using MAC3. Now it has shared
state, each bound to a unique MAC address, on 3 APs in the ESS. If it later wants to go associate with AP2 it will change its MAC address to MAC2 and associate. But a probe? No, there's no shared state bound to a MAC address that the STA will want to refer
to later. It's not a transactional exchange. [[MAH]] SAE, FILS, pre-auth, etc. are all great examples, I agree. But, I disagree in your claim that Beacon Request is not also an example. First, “transaction” (transactional exchange) to me, is defined
something like “a set of related tasks that
form a logical unit of work”. In the case of a Beacon Request, all the Probe Requests and the information gleaned from them, is combined into a set of data for decision-making. To me, those all become one transaction as a result. (And, again, per above,
there is nothing that says this state has to be shared, so how/whether the STA expects the AP to have this state is not relevant.) I'm getting dizzy jumping from the minutiae of specific words to the 10000' view of what's going on…. AP1 is asking the STA to go do some work for it. Is that a "transaction"? Who cares. It's not relevant to the 12.2.10 text. It's a semantic
argument which I do not wish to have. The point I'm trying to make here and in my submission is that when the STA goes off and starts to act on that request, the probes it does are not transactional per 12.2.10 and do not create state which would cause the
12.2.10 rules to apply. Yes the STA is gathering data. Yes it's going to send that data back to AP1. AP2 doesn't care. And if AP2 created any state as a result of this probing—no one knows, including the STA—then the STA will have no use of it in the future
so 12.2.10 doesn't apply. regards, 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 Mark From: Harkins, Dan <daniel.harkins@xxxxxxx>
Hi Jay, On 8/31/23, 11:26 PM, "yang.zhijie@xxxxxxxxxx" <yang.zhijie@xxxxxxxxxx> wrote: Hi Dan, The state created on the AP and STA is per-AP level, not per-BSS. After the STA associated with the AP(AP1),the STA can send Class1/2/3 frame to AP1. But the
STA is only allowed to send Class 1 frame to the second AP(AP2). e.g. the STA can't send Class 3 frame, like Data frame, to AP2. Obviously, the STA is in the state 1 from AP2 perspective. So? I don't understand what point you're making here. Yes, the state governs what frames can be sent. And…. When we talk "transactional exchange", i guess there is a precondition to say the transactional exchange shall be between one entity peer, like AP1 and STA1
is an entity peer, while STA1 and AP2 is the another entity peer. If so, beacon request/report between AP1/STA1 is a transactional exchange, while probe request/response between STA1/AP2 is another transactional exchange. It looks like one transactional exchange
insert into the procedure of another transactional exchange. Maybe I'm totally wrong as 11aq doesn't describe this part very clear. The transactional exchange generates shared state. If there is no shared state created then it's not a transactional exchange—"starts any transaction that establishes state bound to a MAC". Let me ask my question below again. When STA1 sends a probe request to AP2 what shared state is it creating? Or is it using some state it created due to the fact that its associated with AP1? If so how? regards, 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
Best Regards
Jay Yang (杨志杰)
Wi-Fi Standard Research Engineer
ZTE Corporation
R&D Building I, No.899 Bibo , Pudong District, Shanghai, P. R. China
Original From: Harkins ,Dan <daniel.harkins@xxxxxxx> To: 杨志杰10343608;STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
<STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx>; Date: 2023年09月01日
11:02 Subject: Re: [STDS-802-11-TGBH] 11-23/1453r0
Hi Jay,
The question is, does the STA doing the probing require the use of any state it had created on an AP in the ESS to perform its activities? If so then what is that state?
Is this a transactional exchange or not? The fact that there might be 4 types of frame exchanges does not affect the answer. So? What's the answer? You don't need to wait until Tuesday, you can answer now.
regards,
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
On 8/31/23, 6:28 PM, "Jay Yang" <yang.zhijie@ZTE .COM.CN> wrote:
Hi Dan, I have a quick look at your contribution. I've some hard time to understand the question "Is
a probe made in response to a Beacon Report Request a transactional exchange? ". There are 4 type of frames exchange in this procedure: Beacon request, Beacon report, probe request
and probe response. Beacon report is the response to the Beacon request. So not sure what's the meaning "Beacon Report Request" here. Anyway, I'm happy to discuss more with you next Tues.
Best Regards
Jay Yang (杨志杰)
Wi-Fi Standard Research Engineer
ZTE Corporation
R&D Building I, No.899 Bibo , Pudong District, Shanghai, P. R. China
Original
From: MarkHamilton <mark.hamilton2152@xxxxxxxxx>
Date: 2023年09月01日
03:59
Subject: Re: [STDS-802-11-TGBH] 11-23/1453r0
Thanks, Dan. I’ve added it.
Mark
From: Harkins , Dan <daniel.harkins@xxxxxxx>
Hi Mark,
I've uploaded document 11-23/1453r0 to mentor. Can you put me on the agenda for the next teleconference on 5 September please?
thanks and regards,
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
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 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 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 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 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 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 |