On 23 Oct 2015, at 03:30, Alec Muffett alecm@fb.com wrote:
However, if you were to use proposal #255 to split the introduction and rendezvous to separate tor instances, you would then be limited to:
- 6*10*N tor introduction points, where there are 6 HSDirs, each receiving 10 different introduction points from different tor instances, and N failover instances of this infrastructure competing to post descriptors. (Where N = 1, 2, 3.)
- a virtually unlimited number of tor servers doing the rendezvous and exchanging data (say 1 server per M clients, where M is perhaps 100 or so, but ideally dynamically determined based on load/response time).
In this scenario, you could potentially overload the introduction points.
Exactly my concern, especially when combined with overlong lifetimes of mostly-zombie descriptors.
Hopefully, at this point the onion service operator would inform the directory authority operators. They would then decide on higher values for the HSDir hashring consensus parameters, thus increasing the number of HSDir replicas per onion service.
Of course, this assumes a lot - including that the directory authorities will change, and that no-one has hard-coded the 6 replicas as a constant anywhere in their code. We might want to check this for OnionBalance.
Better to fix the issues at the source, if we can.
Tim