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 -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk