Hi all, Firstly, thank you to all of the onion service operators who took the time to get in touch with me. Your feedback has been very helpful. It is clear that there are a multitude of use-cases and requirements which can be quite different for people running 'public onion services' or anonymous onion services. A couple of common points have stood out which I will try to summarize here for future reference. 1. Redundancy, Failover and Scaling Many of the onion service operators that I talked to said that the ability to have redundant service hosting and avoid a single point of failure is a big priority. The current situation with a single Tor process on a single physical server is not ideal. Some operators have experimented with running multiple Tor daemons which then "compete" with one another to publish hidden service descriptors. Early results suggest that this basic approach shows promise. Operators also said that it is important that the deployment of onion services should not require much Tor specific 'magic'. Ideally it should be possible to deploy and manage onion services using much the same tools and process as regular internet services (e.g Puppet, Chef, Ansible). 2. Multicore Tor Operators were also interested in development of the Tor daemon to more fully utilize the resources on their multi-core systems. Currently onion services running on multi-core systems have difficulty utilizing much of the available processing resources beyond a single core. This work is outside the scope of my project, but I'll note these problems here anyways. My project may allow some degree of multicore utilization with onion services as onion service could be served by multiple Tor instances running on a single multicore system. Clients could then split connections between different cores by choosing an intro point managed by a particular Tor process/core. This was something I hadn't though about before but which might provide some easy improvements. 3. Instrumentation for Onion Service Monitoring Some operators have been trying to monitor and understand the performance and reliability of their onion services but have run into trouble due to a lack of information available on the Tor control port. In particular the following limitations were outlined: - No metrics about concurrent onion service connections over time - No metrics for data transfer over the onion service. - No data about resource constraints (Tor bandwidth, entry guard bandwidth) - No data about connection rates, failed introductions, rendezvous.. - Difficult to monitor if a service is actually reachable. Attempts to use information currently available via the control port was not perceived to be very insightful or useful. Due to lack of available metrics only anecdotal information is available when users contact the operator with complaints. As a result the operator currently has little options for debugging and diagnosis except for restarting Tor process and hoping for the best. I'll contact this list again when more design designs have been finalized and when I have more to report. Thank you all again, Regards, Donncha
Attachment:
signature.asc
Description: OpenPGP digital signature
-- tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk