[tor-dev] Timers in Arti?

[Michael Rogers]

Sorry, I should have said that we're interested in keeping a hidden 
service running. Without that requirement, I agree we could just close 
the guard connection via DisableNetwork after some idle period.

So the question is about keeping circuits alive, and I guess also 
keeping HS descriptors published and the consensus fresh, although 
hopefully the timing requirements for those are a bit looser due to the 
longer timescales involved.

Cheers,
Michael

On 08/01/2024 21:01, Micah Elizabeth Scott wrote:
> A variety of timers are needed on the relay side; on the client side 
> though, aren't you mostly limited by the requirement of keeping a TCP 
> connection open?
> 
> Really deep sleep would involve avoiding any protocol-level keepalives 
> as well as TCP keepalives. This seems a lot like just shutting down the 
> connection to the guard when sleeping; but of course that's got a 
> latency penalty and it's visible to anyone who can see network activity.
> 
> -beth
> 
> On 1/4/24 04:48, Michael Rogers wrote:
> 
>> Hi,
>>
>> If I understand right, the C implementation of Tor has various state 
>> machines that are driven by local libevent timers as well as events 
>> from the network. For example, when building a circuit, if there 
>> hasn't been any progress for a certain amount of time then a timer 
>> fires to handle the timeout.
>>
>> When running Tor on Android, we need to prevent the OS from suspending 
>> so that these timers fire when they're supposed to. This uses a lot of 
>> battery, because normally the OS would spend most of its time 
>> suspended. Unlike a laptop, an Android device with its screen turned 
>> off is constantly dipping in an out of suspension, and a lot of the 
>> platform's power optimisations are aimed at batching whatever work 
>> needs to be done so that the periods of suspension can be longer.
>>
>> If we allowed the OS to suspend then the timers would fire with 
>> arbitrary delays, and I don't really know what impact that would have: 
>> I'd speculate that there might be connectivity problems (eg dead 
>> circuits not being detected and replaced) and/or network-visible 
>> changes in the behaviour of circuits that could affect anonymity.
>>
>> So I've had a longstanding but not-very-hopeful request that maybe 
>> Tor's reliance on timers could be reduced, or at least clarified, so 
>> that we could either allow the OS to suspend without breaking 
>> anything, or at least know what was likely to break.
>>
>> And basically I'd just like to renew that request for Arti. Could 
>> anyone give me an overview of how these local timers are handled in 
>> Arti, or any information about what's likely to happen if the timers 
>> are arbitrarily delayed?
>>
>> Thanks,
>> Michael
>>
>> _______________________________________________
>> tor-dev mailing list
>> tor-dev at lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x11044FD19FC527CC.asc
Type: application/pgp-keys
Size: 12048 bytes
Desc: OpenPGP public key
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20240109/a3732633/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20240109/a3732633/attachment.sig>