Performance Improvements on Tor or, Why Tor is slow and what we're going to do about it

As Tor’s user base has grown, the performance of the Tor network has suffered. This document describes our current understanding of why Tor is slow, and lays out our options for fixing it. Over the past few years, our funding (and thus our development effort) has focused on usability and blocking-resistance. We’ve come up with a portable self-contained Windows bundle; deployed tools to handle the upcoming censorship arms race; further developed supporting applications like Vidalia, Torbutton, and Thandy; made it easier for users to be relays by adding better rate limiting and an easy graphical interface with uPnP support; developed an effective translation and localization team and infrastructure; and spread understanding of Tor in a safe word-of-mouth way that stayed mostly under the radar of censors. In parallel to adding these features, we’ve also been laying the groundwork for performance improvements. We’ve been working with academics to write research papers on improving Tor’s speed, funding some academic groups directly to come up with prototypes, and thinking hard about how to safely collect metrics about network performance. But it’s becoming increasingly clear that we’re not going to produce the perfect answers just by thinking hard. We need to roll out some attempts at solutions, and use the experience to get better intuition about how to really solve the problems. We’ve identified six main reasons why the Tor network is slow. Problem #1 is that Tor’s congestion control does not work well. We need to come up with ways to let “quiet” streams like web browsing co-exist better with “loud” streams like bulk transfer. Problem #2 is that some Tor users simply put too much traffic onto the network relative to the amount they contribute, so we need to work on ways to limit the effects of those users and/or provide priority to the other users. Problem #3 is that the Tor network simply doesn’t have enough capacity to handle all the users that want privacy on the Internet. We need to develop strategies for increasing the overall community of relays, and consider introducing incentives to make the network more self-sustaining. Problem #4 is that Tor’s current path selection algorithms don’t actually distribute load correctly over the network, meaning some relays are overloaded and some are underloaded. We need to develop ways to more accurately estimate the properties of each relay, and also ways for clients to select paths more fairly. Problem #5 is that Tor clients aren’t as good as they should be at handling high or variable latency and connection failures. We need better heuristics for clients to automatically shift away from bad circuits, and other tricks for them to dynamically adapt their behavior. Problem #6 is that low-bandwidth users spend too much of their network overhead downloading directory information. We’ve made a serious dent in this problem already, but more work remains here too. We discuss each reason more in its own section below. For each section, we explain our current intuition for how to address the problem, how effective we think each fix would be, how much effort and risk is involved, and the recommended next steps, all with an eye to what can be accomplished in 2009. While all six categories need to be resolved in order to make the Tor network fast enough to handle everyone who wants to use it, we’ve ordered the sections by precedence. That is, solving the earlier sections will be necessary before we can see benefits from solving the later sections.