On 07/11/2018 09:04, teor wrote: > > >> On 7 Nov 2018, at 04:10, Michael Rogers <michael@xxxxxxxxxxxxxxxx> 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. You're right, it's not pretty. Using this hack on the client is bad enough, and asking the network to support the hack is worse. On the other hand, Android has a lot of users, and battery-friendly hidden services on mobile devices would be a great building block for privacy tools (assuming we could overcome the other obstacles too). > 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? Interestingly we found that ReducedConnectionPadding didn't make much of a difference for our use case, perhaps because the hidden service keeps the OR connection open. If I understand right, closing the connection is one of the ways ReducedConnectionPadding would normally save bandwidth. I ran some experiments over the weekend to double-check this. Here's the traffic per hour for Tor 0.3.4.8 running a hidden service with no incoming or outgoing connections, averaged over 12 hours: Default: sent 415 kB (stdev 90 k), received 434 kB (stdev 114 k) No padding: sent 176 kB (stdev 74 k), received 232 kB (stdev 182 k) Reduced padding: sent 418 kB (stdev 87 k), received 312 kB (stdev 183 k) Cheers, Michael
Attachment:
0x11044FD19FC527CC.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev