[PATCH 7/8] GAS: End remain-on-channel due to delayed GAS comeback request

[Peer, Ilan]

Hi Jouni,

> -----Original Message-----
> From: Jouni Malinen [mailto:j at w1.fi]
> Sent: Sunday, December 20, 2015 12:14
> To: Peer, Ilan
> Cc: hostap at lists.infradead.org; Gottlieb, Matti
> Subject: Re: [PATCH 7/8] GAS: End remain-on-channel due to delayed GAS
> comeback request
> 
> On Sun, Dec 20, 2015 at 08:52:37AM +0000, Peer, Ilan wrote:
> > Thanks. Let me know if there are issues with the last patch.
> 
> It does increase the risk of failures with deployed APs. I'm not at all convinced
> that they can reply quickly enough to GAS comeback requests in all cases.. I
> had actually experimented with this some time earlier but with even a shorted
> timeout (100 ms). wpa_supplicant does not currently retry GAS comeback

We did not think that this would be an issue as we assumed that after the GAS
initial request/response exchange all the comeback requests are negotiated directly
with the AP, without involving the advertisement server, so the exchange should be
fast enough to complete in 200 msec.

FWIW, in our testing setups we also used 100 msec which was also ok, however,
these are only testing setup, so we could still might issues in real deployments :)

> requests at higher layer and it may be necessary to add such a retry
> mechanism before dropping the wait timeout on each individual frame.
> 
> Other than that, the change itself is clearly of significant benefit for the cases
> where the first wait cannot be extended and mac80211 ends up waiting for
> significant amount of time between each attempt. I just don't want to optimize
> this at the cost of reliability to already deployed use cases.
> 

In case that all the wait times are equal, the first wait would never be extended, so 
eventually we will always need to pay the wait time between ROCs. As an alternative we
also considered to always cancel the previous running ROC before starting a new one, but this
has the disadvantage that scheduling a new ROC can once again incur additional delays,
so we decided to go with the approach in patch 8/8. We can revert to this approach
if you think that it is safer in terms of inter-op.

Regards,

Ilan.