[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] Hidden Service Scaling Summer of Privacy Project

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
  - 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,

Attachment: signature.asc
Description: OpenPGP digital signature

tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to