Re: [tor-talk] hidden services and stream isolation (file transfer over Tor HS speedup?)

[Roger Dingledine <arma@xxxxxxx>]

On Sat, Sep 08, 2012 at 07:59:03PM +0200, Fabio Pietrosanti (naif) wrote:
> That step come while brainstorming with hellais and vecna about a file
> upload system for big files that should try to optimize at maximum the
> transfer over a TorHS with Javascript /web browser.

Tricks like this make sense when the bottleneck is at the edges of the
network. But when the bottleneck is in the core of the network (which is
the case with Tor, since it has way too much load compared to the relay
capacity), then trying to 'optimize' your transfer by pretending to be
multiple people is an arms race that just makes things worse.

> While making big files transfer over a TorHS, there is the risk to went
> into very low-bandwidth circuit or even unstable circuits due to the
> length of a TorHS connection path (7 hops right?).

6 hops.

But yes, this is a risk. We're trying to resolve it in general with both

a) the relay consensus weights (to shift traffic to the relays that can
handle it better) and

b) the circuit-build-timeout computation (where you as a client discard
the slowest 20% of your circuits).

If everybody moved to the fastest 20% of the relays, though, it would
be worse than what it is now. Good load balancing means using the
slower relays too, just less often.

(But not *too* slow:
https://trac.torproject.org/projects/tor/ticket/1854 )

> The idea is:
> - to split the files that need to be transferred in chunk of fixed size
> - then send that chunks over multiple sockets
> - every new chunk has to be sent, open a new socket trough a different
> Socks port (so trough a different tor circuit)

I think you aren't considering how much cpu load is added by opening a
new circuit. In this case (for hidden services), the circuit creation will
be on-demand (rather than preemptive), which means you'll be waiting for
each circuit to open (which involves many circuits, for a hidden service
rendezvous) before you can use it. This latency you will experience is
exactly the sort of thing that will get worse if people start overloading
the network with extra circuits.

This is another instance of the general problem that we see from a lot
of researchers: "I think Tor is slow because of X. Therefore I will
change my client behavior to do this other thing. It works better for
me now. Therefore every client should make this change." That's why Rob
and I have been pushing Shadow so much:
https://shadow.cs.umn.edu/
since whole-Tor-network simulators are the right way to evaluate
largescale client behavior changes.

I wonder if it would be worthwhile to try to rig up a Shadow simulation
to see results. My guess is that if my clients do it, it will ruin the
network for the clients who don't; whether it also ruins the network
for the clients that *also* do it remains to be seen. See also
http://freehaven.net/anonbib/#throttling-sec12

While I'm at it, there *are* several steps that would lead to
significantly improving hidden service performance:
https://trac.torproject.org/projects/tor/ticket/1944
plus the various performance and security fixes in the 'Tor hidden
service' category.

I know it can be tempting to treat the Tor design and code as a black
box and try to hack around it, but I think in this case the clear right
thing to do is to make the code not suck so much.

--Roger

_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk