[PATCH] P2P: Make P2P invitation flow less aggressive

[Otcheretianski, Andrei]

> I don't really like to force upper layer components or users to be responsible
> for configuring this type of things to make something work while potentially
> breaking something else..
> 
> Why is the wait time dropped for both cases of active GO (which I can
> understand) and no other parallel operations (which seems quite separate
> and unnecessary)?

Indeed, changing the wait time when there's no active GO is not critical.
For an active GO it's really painful, since long offchannel activity will result in a notice of absence that can't be cancelled.
However, even if there's no active go, there may be still concurrent channel activity which that can be affected by a long offchannel operation - but it is much less critical.
I will drop this part.

> I don't think you can avoid missing a Beacon frame
> transmission on another channels without low level synchronization
> somewhere at the firmware/hardware level to jump between channels.. I
> guess making the active P2P GO case use something like 1.5 times the
> beacon interval might be justifiable so that it would hopefully not skip more
> than two Beacon frames in a row.

Since the exact beacon interval is not available in this flow, I'll change it to 150ms instead.

Thanks,
Andrei
> 
> --
> Jouni Malinen                                            PGP id EFC895FA