On 1 Dec 2017, at 21:56, Michael Rogers michael@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