Re: SCTP
I would wait until it can ubiquitously work behind NATs. (Only FreeBSD has NAT SCTP support and it was committed on Feb 2009). Camilo Gregory Maxwell wrote: On Wed, Jun 3, 2009 at 10:07 AM, Scott Bennett benn...@cs.niu.edu wrote: This may seem to some like beating a dead horse, but SCTP really is coming to the Internet. It just looks too useful to die like OSI did. The more I find out about it, the more it looks like a really good match for tor. In fact, it looks like it might be something from a network- application-developer heaven. It has been available in FreeBSD since 7.0-RELEASE and was officially announced as being a fully supported part of FreeBSD when 7.2-RELEASE was made available about a month ago. More features will be supported in 8.0-RELEASE whenever that comes out, too. There must be similar progress in LINUX kernel development, but I don't follow that very much, so I'd be grateful if a few of the LINUX users on this list were to describe the current support status of SCTP in the various distributions of LINUX. Sooner or later, even Micro$lop will have to release it for its miserable excuses for operating systems, too. [snip] SCTP works fine in Linux. Has been there since around the kernel 2.5 days.
Re: Performance
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
Vidalia exit-country
Hello Maillist As part of the 'google summer of code'(gsoc) I was able to add some of blossom's functionality to vidalia. The project consisted of adding a 'select exit by country' option to vidalia so that users could leverage the Tor network to select the 'perspective' of the network the wished to have. The idea is that many entities select their content based on the traffic ip address 'source' and users might like to have different perspectives easily controlled by them. The project added a new 'tab' on the vidalia's settings window where users can select a country from where they want to 'exit'. Users can also select countries they would like to avoid. There is no Tor version prerequiste to use this tool. This exit aware vidalia version has been tested on windows xp(mingw), linux (2.6-386) and OsX(leopard-ppc) with both Qt 4.3.5 and 4.4.1. Binary packages from windows(Thanks to Matt Edman) are available at: http://vidalia-project.net:8001/vidalia/vidalia-0.1.8-svn-exit-country.exe http://vidalia-project.net:8001/vidalia/vidalia-0.1.8-svn-exit-country.exe.asc Unix tarballs are available at: http://www.vidalia-project.net/dist/exit-country.tar.gz http://www.vidalia-project.net/dist/exit-country.tar.gz.asc The source code can also be downloaded from the vidalia svn by doing: svn co https://svn.vidalia-project.net/svn/vidalia/branches/exit-country exit-country-vidalia Building instructions and prerequsites are the same as vidalia. The build requires cmake and qt. The complete build instructions can be found at: http://trac.vidalia-project.net/wiki/InstallSource Have a nice summer Camilo Viecco / GPG (GPG) Key fingerprint = 0781 10A0 44CC C441 594F E5A9 858A 173E 3EC5 EA42 /
