[RFC] P2P: Handling single channel concurrency

[Jouni Malinen]

On Tue, Feb 07, 2012 at 06:53:48AM +0530, Jithu Jance wrote:
> I was also thinking of something that can be set in wpa_global. I will
> update this part.

OK, thanks.

> > It looks like this patch may have somewhat strange behavior for the case
> > where a P2P client interface is using wpa_supplicant-controlled
> > "roaming", i.e., changing frequencies to follow the GO that is doing a
> > channel switch. In that case, we should allow the association request
> > even if the interface is not marked prioritized since that association
> > operation itself is going to resolve the frequency conflict.
> This is mentioned in the case 3(a) below. If the interface is GO and
> channel switch is supported,
> we would move the GO (only a hook is provided at this point) and allow the
> assoc to proceed.

No, this is different case. I was thinking of a case that does not have
any concurrency at all, i.e., just a single P2P client interface that is
associated with a GO that decides to change channels. Though, maybe I
missed the part of shared_freq>0 not hitting in this particular
sequence.

> I am expecting the driver not to attempt a connection, if another interface
> is connected on a different channel (and FW roaming is supported). But
> again, this is debatable. Some drivers might
> by default give preference to STA operation. We might need to handle cases
> where supplicant gets the STA connected event while we already have a p2p
> connection  on some other channel. Probably in this case, we can just  do
> a p2p_group_remove with reason=freq_conflict.

OK, that may be good enough assumption and resolution for the conflict.
I guess some drivers could end up moving GO interface to a new channel
automatically, so that may need some handling to address potential race
with the events (GO channel frequency change and new association event
at more or less the same time).

> Two more changes from my side which are not in the current set of patches.
> a) I later felt that providing network_id would be better than providing
> ssid and bssid during WPA_EVENT_FREQ_CONFLICT.
> +???????????wpa_msg(wpa_s, MSG_INFO, WPA_EVENT_FREQ_CONFLICT
> +???????????????" ssid=%s bssid=" MACSTR,
> +???????????????wpa_ssid_txt(ssid->ssid, ssid->ssid_len),
> +???????????????MAC2STR(wpa_s->pending_bssid));
> 
> changed to
> 
> +???????????wpa_msg(wpa_s, MSG_INFO, WPA_EVENT_FREQ_CONFLICT
> " id=%d", ssid->id);.

Agreed.

> b) I have added a new reason code to P2P_GROUP_REMOVE
> reason=FREQ_CONFLICT. This is useful when a p2p group gets removed when STA
> connection has more priority.

OK.

> Let me put the scenarios which we want to address and what have so far been
> handled by the current patches. Please add to this, if i missed any.
> 
> 1. We got a STA connection already. Now a P2P Join is requested.
> Action: Check whether there is the GO to which Join is requested on a
> different channel. If
>       channel is different, announce GROUP-FORMATION-FAILURE with reason as
> freq_conflict. Let
>       the application decide further. This is handled by concurrent-2.patch

If the GO is already in the BSS table at the time the p2p_connect join
is issued, that command may return failure immediately. For the case
where a scan is started, this event message sounds fine.

> 2. We got a STA connection already. Now a P2P GO Nego connection is
> requested. The supplicant
>    automatically tries to start the new connection on the shared channel.
> 
>    There can be failures
>    a) The go nego requesting device may not support the channel.
>    b) The other device doesn't support channel (due to a shared interface
> on someother channel).
> 
>    If GO negotiation fails with status 7, it could be caused due to freq
> conflict. I think status code is good enough for application to know that
> it is a channel problem.

Yes, this case should already be handled.

> 3. We got a P2P Connection present and now a STA association is attempted.
> This could include
>    supplicant based roaming. It would be difficult to make a run-time based
> decision. So basically,
>    the decision will be done based on the pre-set connection priority
> (whether STA or P2P connection
>    has the priority).

If the STA association request is triggered without a command from
external entity, this sounds fine. If this is based on a new
reassociation (etc.) command, there may be cases where the ctrl_iface
command can be rejected immediately instead of having to go through
this. Anyway, those can be handled as separate optimizations.

>    a) If the P2P interface is a GO, then try moving the GO to the STA
> channel (there by avoiding the conflict).
> 
>   b) If GO channel switch is not supported or if the interface is a
> P2P-client, then we need to terminate
>         one of the connection.
> 
>    c) If STA has priority, the P2P connection is terminated indicating that
> it is caused due to frequency
>       conflict.

OK.

>    d) If P2P connection has priority, the STA ssid is disabled and upper
> framework is notified about that.
>        Now the application/framwork can decide whether to terminate P2P in
> favor or STA or leave it like that.

I'm not sure whether the STA network block needs to be disabled (I'm
assuming you meant that with ssid getting disabled), but yes, the STA
interface would not be allowed to associate on another channel.

>     e) If the priority is not set, the default behavior is to notify the
> upper application or framework. The supplicant
>         won't do any policing.

Hmm.. How is this different from (d) ?

> 4. supplicant gets the STA connected event while we already have a p2p
> connection on some other channel
>    (roaming handled by driver/firmware).
> 
> Status: Not yet handled.

This is related to the possibility of driver/firmware handling all
channel changes internally. wpa_supplicant may need to be quite flexible
in this area to allow various different architectures.

> In short, the Action Items for me.
> 1. Move prioritize setting to wpa_global
> 2. Handle cases where we get STA CONNECTED event while we have a
> p2p_interface.
> 
> I will get back to you again after making the above two changes.

OK, great.

> The rest probably we can take care as second step.
> 1) The concurrent-3.patch expansion [go_switch_channel].

Yeah, there should be no requirement to have all parts merged in at the
same time.

-- 
Jouni Malinen                                            PGP id EFC895FA