[tor-dev] Timers in Arti?

[Michael Rogers]

Thanks for this information. Android devices are generally able to keep 
TCP connections open during deep sleep, as long as there are keepalives 
from the other side (which we can request for Tor guard connections via 
KeepalivePeriod). The device will wake from deep sleep to handle network 
activity, so any state changes in Tor that are driven by network events 
should also work fine. The problem really is state changes that are 
driven by local timers.

If we assume optimistically that the device wakes often enough (due to 
network activity, background work scheduled by other apps, etc) to 
handle HS descriptor publication and consensus fetches in a reasonably 
timely way, then it seems to me that the main question is whether we can 
keep the introduction circuits alive if local timers don't fire in a 
timely way. And it would also be great to know whether we can not only 
keep the circuits alive, but avoid network-visible changes in behaviour 
compared with a device that's not sleeping.

Cheers,
Michael

On 09/01/2024 17:57, Micah Elizabeth Scott wrote:
> Ah. If you want to run an onion service you'll need to keep at least a 
> couple circuits open continuously for the introduction points. I'm not 
> sure where you would meaningfully find time to deep sleep in that 
> scenario. There will be ongoing obligations from the wifi/wan and tcp 
> stacks. You need a continuous TCP connection to the guard, and multiple 
> circuits that are not discarded as idle. Incoming traffic on those 
> circuits need to be addressed quickly or clients won't be able to connect.
> 
> If we were really optimizing for a low power mobile onion service 
> platform we'd have a different way to facilitate introductions without a 
> continuously open set of circuits, but that would also be much more 
> abuse-prone.
> 
> -beth
> 
> 
> On 1/9/24 05:19, Michael Rogers wrote:
>> 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/20240110/34c591a0/attachment-0001.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/20240110/34c591a0/attachment-0001.sig>