[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: On the performance scalability of Tor



On Wednesday 18 July 2007 15:58:17 Steven Murdoch wrote:
> A frequently stated problem with Tor is the poor performance and
> improving this is the goal of several sub-projects. One of these is to
> simply encourage the deployment of more Tor servers. This will
> increase the capacity of the network, but the consequent improvement
> to users is more difficult to estimate.
>
> The intuitive hypothesis -- that a n% increase in network capacity
> will result in an n% increase in performance for users -- is almost
> certainly wrong. In fact, the defining factor is how the number of
> users scales with the available bandwidth -- a currently unknown
> function.
>
> I discuss this way of looking at Tor as well as the consequences and
> limitations of the approach in a blog post published today:
>
> 
> http://www.lightbluetouchpaper.org/2007/07/18/economics-of-tor-performance/
>
> As always, comments and suggestions, either here on the list or on the
> blog, are appreciated.
>
> Steven.

It has always seemed to me that there is plenty of raw 'bandwidth' on the tor 
network. I've just downloaded the tor tarball at a relatively nippy 17KB/s. 
Not greased lightning by any means but clearly if it was just bandwidth at 
issue the general browsing experience would be a lot different.

From a layman's point of view, opening a web page with tor seems to involve at 
least 10 to 15 separate streams, usually over the same circuit. Once the 
streams are up they are only up for a short time before a new one is created. 
Just looking at the connection monitor on TorK it seems to me that half the 
time is spent creating these streams and half the time (often a lot less) 
actually using them.

I presume Tor is just reflecting the behaviour of privoxy and the browser 
here, which is opening up new tcp sessions for numerous different requests to 
the same destination. I understand that pipelining in firefox and polipo 
mitigates this somewhat. Or does it? I'm not 100% sure on that score.

At any rate couldn't/shouldn't Tor take care of this? Why can't Tor maintain 
and reuse a successfully created stream for all requests to an active 
destination and let the exit break out the requests into their respective tcp 
sessions? Put simply, if my understanding is correct Tor is respecting the 
tcp architecture in the wrong place, at the client (creating new streams for 
each tcp request/session) rather than the exit (creating new tcp sessions 
where appropriate from the same stream).

Feel free to slap some sense into me on this one.
-- 

Browse Anonymously Anywhere	- http://anonymityanywhere.com
TorK	- KDE Anonymity Manager	- http://tork.sf.net
KlamAV	- KDE Anti-Virus 	- http://www.klamav.net