Looking for some clarification about remain on channel timing

[Jouni Malinen]

On Mon, Jan 21, 2013 at 03:08:16PM +0000, Peer, Ilan wrote:
> I'm currently trying to test some P2P Device flows, and I'm looking for some clarification regarding the remain on channel timing and semantics:
> 
> *         After the kernel reported that it is ready on the specific channel, does the wpa_supplicant assume that it will not notify about cancel ready on channel earlier than expected? It is possible that after the remain on channel session started, some other event happened that required the canceling of the remain on channel session.

Well, there is some assumption of the remain-on-channel operations
keeping the radio awake and on the specified channel for the full
requested duration. If this does not happen, various operations may not
work correctly. That said, it would be good if wpa_supplicant would be
able to handle this cleanly in the sense that it would recover with
minimal issues due to such case. I'm not aware of any sequences where
this would result in significant problems.

> o   For example, the p2p_long_listen is decremented regardless of the actual time that the device spent on the requested channel, which in turn can result in shortening the discoverability time of the device.

That's not ideal and could be improved if there are cases where
remain-on-channel cases get truncated frequently.

> *         When the wpa_supplicant requests the kernel to remain on a specific channel for a specific amount of time, is it acceptable to delay the request for some time? How long? For example assume that the remain on channel was in order to transmit some action frame to a peer device, if the remain on channel operation is delayed for too long, it might be irrelevant to transmit the frame, and the entire operation should be aborted.

The initial design on this was to allow the driver to delay start as
long as needed for whatever reason. There is no mechanism to skip the
following operation or well, to determine whether it could be irrelevant
at the time. I cannot think of any existing use case where there would
be strict timing requirement on sending a frame with a new
remain-on-channel operation.

> o   I guess that alternatively, the wpa_supplicant, can trigger a timer to cancel the request if it exceeds a reasonable amount of time.

It could, but unless some code is added to determine when operations
become irrelevant, there are not really cases where this would be of
much use.

-- 
Jouni Malinen                                            PGP id EFC895FA