Idea: Using the SPDY protocol to improve Tor performance

[Camilo Viecco]

Hello Steven

SPDY would probably achieve little improvements at all.
The primary problem with latency withing Tor is that:
1. the network keeps to much data inside it
2. Multiple streams (of different latency requirements) are
multiplexed over the same TCP connection.

Because of 2, the latency of each connection is dominated
by the internal TCP buffering of the most BW aggresive stream.
SPDY would not solve this issue.

The only mechanism to solve this is to change the
internal transport level of Tor so that the OR behave in a similar
manner to IP routers. I am aware of four approaches to solve this.

1. TCP over DTLS for Tor by Joel Reardon. This approaches
reusees the TOR protocol using UDP+TLS. There are per circuit per
hop userland TCP stacks to solve reordering/loss issues. Would
be great bu requries large amounts of memory per circuit per stack.
There is no downloadable source code (If anyone has it and is allowed
to share it, please post the link).

2.  UDP-OR by Camilo Viecco (yours truly). Uses a UDP for all connections.
A single TCP stream is build from each application at the client to
a socks server residing on the exit node. Uses minimal resources, but
exposes the clients TCP stack to the exit node as currently implemented.
Source code is available at: http://code.google.com/p/tdor/
a running testbed also exists. (Stats at:
http://nettrust1.ucs.indiana.edu/perl/tdor-status2.pl).

3. IPSEC+NAT OR by Csaba Kiraly. Uses IPSEC for encryption and
NAT to create the illusion of circuits (very nice). But uses IPSEC
(ugly, su level required) and
leaks the packet information to every node (there is no packet padding).
I do not have any links for the source code (again links would be
appreciated).

4. The neverending request for SCTP. This would require custom
encryption at the SCTP level
and would not traverse most NATs. But in theory would solve the problem.

Any of these approaches solve the problem better than SPDY, Tor problems are
network problems that require a network level solution. Transport level
solutions
cannot solve any of the issues.

I would prefer an HTTP proxy server advertised by the exit nodes than a
SPDY proxy.
(but who knows if there is enough time-space locality for the requests 
any caching to be useful).


Camilo




On 02/04/2010 03:54 PM, Steven J. Murdoch wrote:
> Hi Carsten,
>
> On Thu, Feb 04, 2010 at 12:13:03AM +0100, Carsten Krüger wrote:
>   
>> it's questionable is SPDY is usefull at all.
>>     
> Google's benchmarks show a ~50% speed-up, and better performance in
> high-latency environments. Using it in the way I suggested is
> different from Google's tests, so I am not certain how much an
> improvement SPDY would give, but I would like to perform some
> experiments before dismissing it.
>
>   
>> Normally only few things changes if you visit a website seconds time
>> (stylesheets, javascriptlib, pics, etc. are static).
>> They are not delivered two times via http because they are cached in
>> browser.
>> SPDY didn't support any caching so a client that visits websites more
>> than once has to load everything again. Very bad.
>>
>> If the caching problem isn't solved SPDY via tor would be worse than
>> http I think.
>>     
> SPDY is a transport layer for HTTP, and so has no effect on caching.
> All the Cache-Control parameters supported by HTTP work with SPDY.
> Browsers don't need to change their caching behaviour either.
>
> Server push does need to be handled carefully with respect to caching,
> because it would be silly to push a resource to a client, when the
> client has a copy. However, all the other features of SPDY should work
> just as well with caching on as with it off.
>
> Steven.
>
>