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

[teor]

> On 1 Dec 2017, at 21:56, Michael Rogers <michael at briarproject.org> wrote:
> 
> 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?

For services, it should include receiving an INTRODUCE cell.

For clients, it should include application activity on the SOCKSPort
and similar.

Do clients fetch directory information on an application request?
It might have to get microdescs to get the right position on the HSDir
hash ring.
For a client .onion address request, does the client fetch the latest onion
service descriptor before connecting?

>> 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?

Interesting question.

It's not required, because the INTRODUCE cell contains all the
rendezvous point details. But I think we should be consistent,
and fetch a consensus and enough microdescs before performing
any client or service activity, just like we do when bootstrapping.
Otherwise, we'll end up with weird bugs.

(Services require microdescs to choose intro points, and to post
their descriptors to the right HSDirs on the hash ring.)

> If so, there's a delay that may let the
> client know the service was idle. Is that a problem?

Mobile clients typically have high latency already.
If enough clients do this, it won't be a problem.

> Two other possibilities would be for the service to fetch directory
> information every hour in case a client connects,

Even if it isn't a CPU drain, fetching info every hour would add to
network usage.

> or to build the
> circuit using whatever information it has available, which may be up to
> a day old. Is that a problem?

It increases the failure rate.

It also makes the client stick out a bit more. We could mitigate this by
allowing all clients to use stale directory information to build circuits.

But I still think it's best to be consistent and get enough directory info.

>> 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?

I'm trying to work out what the use case is here, and why SLEEPWALK
is a good solution,

If the controller sends SLEEPWALK, and Tor has nothing to do, it should
immediately return to IDLE or SLEEP.

If the controller puts the Tor instance in IDLE mode, it doesn't need to
issue a SLEEPWALK command every hour, because Tor will do the
minimum it needs to do to be connected.

If the controller wants to keep the directory information more up to date
(so it can "warm start" with less delay), issuing a SLEEPWALK every
2 hours should be sufficient. (Clients typically have consensuses that
expire in 1.5 - 3 hours.)

The more options that Tor provides, and the more unusual things a
controller tries to do, the more clients will stick out due to delays.
So I don't think SLEEPWALK is a good idea, because it allows every
different controller to pick a different update interval.

So if IDLE doesn't meet your needs, it would help us to know why. If
there's enough demand for it, it may be better to add a "WARM" state,
where Tor checks for directory documents whenever a consensus
expires, and otherwise acts like IDLE.

That might be better than every controller choosing a separate
SLEEPWALK interval. In fact, it would allow us to remove the SLEEPWALK
state in favour of "WARM".

Is there any reason that controllers would want to do a once-off
SLEEPWALK, rather than staying "WARM" under certain conditions?

I can imagine that if we are on battery and wifi, we would want "WARM".
(It's simpler than triggering periodic SLEEPWALKs.)

But if the user launches a Tor-using app, or unlocks the screen, would we
want to issue one SLEEPWALK? Or would we want to stay "WARM" the
entire time the app or screen was being used?

The difference is subtle: it would only become apparent after 1-2 hours of
continuous device use. In the "WARM" state, the consensus would still
be live. If SLEEPWALK was issued once a few hours ago, it wouldn't be.

(The nice thing about SLEEPWALK is that controllers don't have to tell Tor
to IDLE again. Maybe that's enough of a benefit to justify it?)

T