[tor-dev] Dealing with frequent suspends on Android

[teor]

> On 7 Nov 2018, at 04:10, Michael Rogers <michael at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20181107/a58a1422/attachment-0001.sig>