[tor-dev] Proposal 286: Controller APIs for hibernation access on mobile

[Michael Rogers]

Hi Nick,

On 30/11/17 12:55, Nick Mathewson wrote:
> 2. Improvements to the hibernation model
> 
>    To present a consistent interface that applications and
>    controllers can use to manage power consumption, we make these
>    enhancements to our hibernation model.
> 
>    First, we add three new hibernation states: "IDLE",
>    "IDLE_UPDATING", "SLEEP", and "SLEEP_UPDATING".
> 
>    "IDLE" is like the current "idle" or "no predicted ports" state:
>    Tor doesn't launch circuits or start any directory activity, but
>    its listeners are still open.  Tor clients can enter the IDLE
>    state on their own when they are LIVE, but haven't gotten any
>    client activity for a while.  Existing connections and circuits
>    are not closed. If the Tor instance receives any new connections,
>    it becomes LIVE.

Does receiving a new connection include receiving a rendezvous cell from
one of the instance's intro points? If not, do we need a new status
message to tell the controller about this, or is there an existing
message we can use?

> 2.2. Onion service operation
> 
>    When a Tor instance that is running an onion service is IDLE, it
>    does the minimum to try to remain responsive on the onion
>    service: It keeps its introduction points open if it can. Once a
>    day, it fetches new directory information and opens new
>    introduction points.

If a client connects to the service, the service will need to build a
circuit to the rendezvous point. Does it fetch up-to-date directory
information before doing so? If so, there's a delay that may let the
client know the service was idle. Is that a problem?

Two other possibilities would be for the service to fetch directory
information every hour in case a client connects, or to build the
circuit using whatever information it has available, which may be up to
a day old. Is that a problem?

> 3.2. Changing the hibernation state
> 
>    We add the following new possible values to the SIGNAL controller
>    command:
>       "SLEEP" -- enter the sleep state, after an appropriate
>          shutdown interval.
> 
>       "IDLE" -- enter the idle state
> 
>       "SLEEPWALK" -- If in sleep or idle, start probing for
>          directory information in the sleep-update or idle-update
>          state respectively.  Remain in that state until we've
>          probed for directory information, or until we're told to
>          IDLE or SLEEP again, or (if we're idle) until we get client
>          activity. Has no effect if not in sleep or idle.
> 
>       "WAKEUP" -- If in sleep, sleep-update, idle, idle-update, or
>          shutdown:sleep state, enter the live state.  Has no effect
>          in any other state.

How does the controller find out when the Tor instance next needs to
fetch directory information (or post a hidden service descriptor) so it
can send a SLEEPWALK command at the right time? Or should the controller
just send the command periodically, maybe once an hour?

Cheers,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x9FC527CC.asc
Type: application/pgp-keys
Size: 4660 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20171201/dfbfc6f4/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20171201/dfbfc6f4/attachment.sig>