On 7 Nov 2015, at 04:36, Alec Muffett alecm@fb.com wrote:
These three solutions in aggregate should lower latency and scale tor daemon bandwidth by a range of 18..60x
Then:
- (Wishlist) implementation of TVDW's handoff of RP callback
...which will resolve any remaining CPU-bandwidth issues.
These plans are subject to change, but seem reasonable so far.
Rendezvous handoff is partially implemented in: https://trac.torproject.org/projects/tor/ticket/17254 https://trac.torproject.org/projects/tor/ticket/17254
I think we're waiting on the following: * a more detailed specification of the handoff data fields for current and next-generation onion services, so we can be sure it's future-proof (I believe this is the decrypted and parsed cell content) * confirmation that the introduction-side will decrypt (and parse) the INTRODUCE2 cell, to avoid sending introduction point private keys over the control port (this puts slightly more load on the introduction point, but a single message compromise would only compromise that rendezvous, not all the rendezvous for that day from that introduction point)
Together, these two changes would also support the "rendezvous approver" control port feature, where the handoff controller can filter requests as needed based on their content or on external factors such as load.
This also might be a nice way of doing geographical load-balancing: an introduction for a European rendezvous point could be sent to a nearby European data center to perform the actual rendezvous. Alternately, it could be send to a lightly-loaded instance.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F