Re: Performance

[Camilo Viecco <cviecco@xxxxxxxxxxx>]

The main reason why Tor currently has bad performance is that it
multiplexes multiple circuits (and therefore the streams in those
circuits) under the same TLS(TCP) connection. This is very important
from the security perspective, but causes problems when any link in the
circuit that you chosen is under congestion. When a link is under
congestion, packet drops in that connection will make the TCP connection
to slow down (tcp transforms reduced bandwidth into latency). Thus if
only one stream is of heavy traffic, the latency of all other streams
that share that connection will be increased. It is now known that bulk
traffic accounts for >40% of Tor's exit traffic (It is impossible to
estimate hidden traffic) thus there is a very high probability that you
are sharing the connection with one of those streams. Further if there
are any hosts in you circuit that do not use TCP extensions for high
bandwidth-delay products (windows machines have this options disabled by
default), this 'side-effect' would be increased.

To test this, even on a 'fast circuit' try making 2 bulk downloads while
simultaneously browsing.. the latency of the browsing will be abysmal,
even tough the total throughput is ok.

Currently, there are two research paths to solve this on Tor : A
proposal by Joel Reardon that creates per circuit and hop userspace TCP
stacks for each circuit and a proposal by Camilo Viecco (myself) to use
a single TCP session for active each stream from the application  at the
client to the exit node.

There is running source code (and a running network) for my proposal
mostly as a Proof on concept (that is ,the network is really small, ,the
code is still not ready for production, is not available as binaries,
nor compiles in windows machines (only linux, and osx)) but that you can
use now for testing purposes. To download from the public svn repo: 'svn
checkout */http/*://tdor.googlecode.com/svn/trunk/ tdor-read-only'/ .
This code illustrates that you can have low latency while keeping
anonymity. I would love to hear more from testers, but I  will restate
the caveat : this network provides very little anonymity as I am in
control of all of the infrastructure (And why would you trust me).

I am very confident that some solution to the latency will be available
in Tor in the next two years, but for now we have to live with this

Camilo

PS.
The paper with the traffic statistics is available here:
http://www.cs.washington.edu/homes/yoshi/papers/Tor/PETS2008_37.pdf

Dominik Schaefer wrote:
> Alessandro Donnini schrieb:
>   
>> True, I did take that into account. I could be mistaken but I think the main
>> problem lies with the proxy software.
>>     
> I seriously doubt that. But you can check that if you use
> Polipo/Privoxy, but not Tor.
>
> Dominik
>
>