On 7 Nov 2018, at 04:10, Michael Rogers michael@briarproject.org wrote:
On 06/11/2018 01:58, Roger Dingledine wrote:
On Tue, Nov 06, 2018 at 11:38:33AM +1000, teor wrote:
so if we could ask the guard for regular keepalives, we might be able to promise that the CPU will wake once every keepalive interval, unless the guard connection's lost, in which case it will wake once every 15 minutes. But keepalives from the guard would require a protocol change, which would take time to roll out, and would let the guard know (if it doesn't already) that the client's running on Android.
Tor implemented netflow padding in 0.3.1.1-alpha (May 2017): https://gitweb.torproject.org/torspec.git/tree/padding-spec.txt
Connection padding may act like a keepalive, we should consider this use case as we improve our padding designs.
Relays already send a keepalive (padding) cell every 5 minutes: see the KeepalivePeriod config option. That's separate from any of the new netflow padding. Clients send them too.
Ah, thanks! I didn't realise keepalives were sent from relays to clients as well as vice versa.
That gives us a max sleep of 5 minutes when a guard connection's open and 15 minutes when it's not, which is a great improvement.
Would it have much impact on the network to reduce the default keepalive interval to, say, one minute?
It's doable, but it would take a while to roll out to all relays. And it seems like a strange solution to a platform-specific problem.
We might also have to be careful, because a multiple of the keepalive interval is used to close connections without any circuits.
The netflow padding is more interesting for the Briar case, since it comes way way more often than keepalives: so if you're trying for deep sleep but you wake up for network activity every several seconds, you'll probably end up sad.
Unfortunately we've disabled netflow padding due to bandwidth and battery usage.
Even with ReducedConnectionPadding?
T