[RFC] P2P: Handling single channel concurrency

[Reinette Chatre]

Hi Jithu,

On Thu, 2012-01-05 at 06:24 -0800, Jithu Jance wrote:
> > It would be nice if there were some hooks available to enable user to
> > have an opinion about the action being taken. The STA connection may (1)
> > be automated and be requested without user's knowledge, (2) be requested
> > by user not knowing that the current connection may be dropped, etc. For
> > example, user may not want to be disconnected from the current WFD
> > session with their TV when trying to send email at same time, user may
> > prefer to defer sending the email. Just dropping the WFD session is a
> > rather bad user experience in this example.
> 
> Agree with you. Sharing my thoughts on acheiving this user notification part. 
> One option is to have a config file parameter which framework can set and user 
> would be able to change that. This will allow user to decide to prefer STA over
> P2P or P2P over STA.

This sounds good. Maybe higher level options like "first come first
served" could make things even easier to get this off the ground. Maybe
even start with one default, which then does not even need a
configuration parameter - it could just be the one default that
wpa_supplicant supports unless there are hooks that indicate otherwise.
I am trying to be careful with the choices here since (based on my
potentially flawed assumption of a typical user) a typical user may not
care about the technology (P2P vs STA). A user may want to know things
like "if I try to print this document then I will loose my internet
connection" which is much higher level than what wpa_supplicant should
care about. 

>  In addition to this, we may add a new reason code to GROUP_REMOVE
> event to indicate that group has been removed due to frequency conflict. This way 
> framework/user app can come to know about it and notify user. This policing is 
> not run-time. But this probably can be attempted as a first step.

Excellent, yes. In addition to the reason added to GROUP_REMOVE there
should maybe also be a reason code to the STA side of things. Some logic
may need to be added to connection managers to support this smoothly so
that the connection manager will not keep trying to associate when
something like an already present P2P connection prevents it from doing
so. 

> Another option. This is kind of a runtime decision making. But not sure whether this
> is the right way to do it.

I do think runtime decision making is the way to go.

> 1. On attempting a STA connection, check whether there is a frequency conflict with any other
> interface.

Here we do have the "interface capabilities" information available (see
"cfg80211: advertise possible interface combinations" in kernel) to help
with this decision. I do not think this is being used by wpa_supplicant
yet. I am  not sure whether we would like to make things this
complicated inside wpa_supplicant core either and things could be worked
out if wpa_supplicant makes this information available to another
component that will make decisions with or without user interaction.

> 2. On detecting the frequency conflict following steps can be taken

As mentioned above I am not sure we want to complicate things inside
wpa_supplicant. 

> 	a) Disable the current STA network to avoid connection. supplicant won't try to connect until it is again
>        enabled from the application.
>         b) sent an event/notificaton to User space
>             i)   User app/framework on getting event should ask user persmission to forgo P2P connection
>             ii)  If user opts "no", the station config remains disabled and P2P connection stays as is.
>             iii) If user opts "yes", the framework removes the p2p group and enables the STA config. Since network blob is enabled, 
>                 sta connection is again attempted and this time supplicant won't find a conflict since p2p interface doesn't exist.

I agree with the high level concepts you show here. You present two
steps and I think it can be summarized that (a) will be the default
decision made by wpa_supplicant if there are not any hooks, (b) will be
whatever the "hook" decides.

One way to accomplish this is to have a new component that implements a
set of hooks. This component may be the one that could retrieve all the
interface capability information from wpa_supplicant (once it becomes
available), it could have a database of "known good behaviors", it may
even contain default behaviors (because a user previously selected a "Do
not ask me again" option), etc. This can be made pretty fancy.

A hook itself could be a question combined with enough state information
to make a decision. The answer could be a "yes" or "no" and may include
more information in response (like which channels are available for
use). How the hook comes to the answer can be a variety of things. It
can query its database or it can post a question to the user. Since this
component is contained it can be enhanced to support a very good user
experience.

One thing that I am not clear on is the "framework" you mention in your
description. As you mention, when a decision comes back from the hooks
then there may be a few steps that needs to be performed before the
original request can be serviced. Like in your example when the user
opts "yes" then the P2P group needs to be removed and STA connection
reattempted. It seems that there may be a need for a small layer on top
of (but maybe not separate from) wpa_supplicant that can arbitrate these
potentially conflicting incoming requests (which may not be limited to
connectivity) and take care of the additional steps needed to service
the original request.

> Request opinion on above thoughts.

You asked for it :)

Reinette