On Tue, Oct 14, 2014 at 12:17:27PM -0400, Greg Norcie wrote:
I'm working on doing a study on user tolerance of delays (for
example, latency on Tor).
During our discussion, a bit of a debate occured about the TBB's
circuit switching. I was wondering if there's any research that's
been done to arrive at the 10 minute window for circuit switching,
or if that was number picked arbitrarily?
It was alas picked arbitrarily. As Nick notes, it used to be 30 seconds,
and then when we started getting users, all the relays complained of
running at 100% cpu handling circuit handshakes. We changed it to 10
minutes, and the complaints went away -- at least until the botnet
showed up.
We've had an open research question listed for years now -- see bullet
point 4 on
https://research.torproject.org/ideas.html
"""
Right now Tor clients are willing to reuse a given circuit for ten
minutes after it's first used. The goal is to avoid loading down the
network with too many circuit creations, yet to also avoid having
clients use the same circuit for so long that the exit node can build a
useful pseudonymous profile of them. Alas, ten minutes is probably way
too long, especially if connections from multiple protocols (e.g. IM and
web browsing) are put on the same circuit. If we keep fixed the overall
number of circuit extends that the network needs to do, are there more
efficient and/or safer ways for clients to allocate streams to circuits,
or for clients to build preemptive circuits? Perhaps this research item
needs to start with gathering some traces of what requests typical
clients try to launch, so you have something realistic to try to
optimize.
"""
Also note that if a stream request times out (or for certain similar
failures), you move to a new circuit earlier than the 10 minute period.
So it might be that users actively browsing will switch much more often
than every 10 minutes. Somebody should study what happens in practice.
The future plan is to isolate streams by domain, not by time interval:
https://trac.torproject.org/projects/tor/ticket/5752
But of course there are some tricky engineering and security
considerations there.
And lastly, see
https://trac.torproject.org/projects/tor/ticket/5830
for a standalone related analysis/research project that I wish somebody
would do. :)
--Roger