[tor-dev] [Question to sysadmins and HS operators:] How should Hidden Services scale?

[George Kadianakis]

Hello people,

you might have noticed that there is a redesign of hidden services
going on.

For a while we've been told that "hidden services don't scale" and
"there is a max number of clients that a hidden service can handle" so
we decided to also consider hidden service scalability as part of the
upcoming redesign. Unfortunately, we are not experienced in
maintaining busy hidden services so we need some help here.

For example, a load balancing technique that hidden services are
missing is DNS round-robin; that is, something that load balances on
the IP layer (you send some clients to one IP and the rest to another
IP). To do the equivalent in hidden services you have to do the load
distribution in the Introduction Point layer. Some people have been
thinking about this:
https://lists.torproject.org/pipermail/tor-dev/2013-October/005556.html
https://lists.torproject.org/pipermail/tor-dev/2013-October/005674.html

Unfortunately, the above designs are not trivial to implement. They
require the hidden service peers to communicate with each other so
that they can generate and recycle keys, and it also puts Introduction
Points in a position where they can find out the status or number of
hidden service peers.

For this reason we started wondering whether DNS-round-robin-like
scalability is actually worth such trouble. AFAIK most big websites
use DNS round-robin, but is it necessary? What about application-layer
solutions like HAProxy? Do application-layer load balancing solutions
exist for other (stateful) protocols (IRC, XMPP, etc.)?

What should we do to make Hidden Services scale to a large number of
clients?

Also, is "scalability" the correct phrase here? Should we replace it
with a combination of "load balancing", "high availability", or
something else?

[I sent this mail twice because the first did not get posted in tor-dev.]