Delivery-Date: Tue, 14 Oct 2014 17:10:43 -0400
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id 72BA51E107B;
	Tue, 14 Oct 2014 17:10:41 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 3E54831206;
	Tue, 14 Oct 2014 21:10:37 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id AFD2130E75
 for <tor-talk@lists.torproject.org>; Tue, 14 Oct 2014 21:10:33 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at eugeni.torproject.org
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 8NQ6O2DUG2RX for <tor-talk@lists.torproject.org>;
 Tue, 14 Oct 2014 21:10:33 +0000 (UTC)
Received: from khazad-dum.seul.org (khazad-dum.csail.mit.edu [128.31.0.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "moria.seul.org", Issuer "moria.seul.org" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 7B7E030C20
 for <tor-talk@lists.torproject.org>; Tue, 14 Oct 2014 21:10:33 +0000 (UTC)
Received: by khazad-dum.seul.org (Postfix, from userid 501)
 id 716511E107B; Tue, 14 Oct 2014 17:10:30 -0400 (EDT)
Date: Tue, 14 Oct 2014 17:10:30 -0400
From: Roger Dingledine <arma@mit.edu>
To: tor-talk@lists.torproject.org
Message-ID: <20141014211030.GI54413@moria.seul.org>
References: <543D4C97.1060500@umail.iu.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <543D4C97.1060500@umail.iu.edu>
User-Agent: Mutt/1.5.20 (2009-12-10)
Subject: Re: [tor-talk] Reasoning behind 10 minute circuit switch?
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

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

