Re: How many hidden service circuits built?

[Karsten Loesing <karsten.loesing@xxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Bernhard,

Bernhard Fischer wrote:
> Sorry, I didn't see this before. I'll read your paper and I appreciate all 
> improvements regarding hidden services. 

You might also want to read the documents that are linked from the NLnet
project page, for example:

http://freehaven.net/~karsten/hidserv/perfanalysis-2008-06-15.pdf

> While TOR is building circuits there's always some kind of randomness 
> involved. As far as I know TOR chooses nodes based on directory flags 
> (like "fast", "stable", ...) and the randomizes those matching some criteria.
> Obviously the flag "fast" is somehow misleading because bandwidth is a local 
> property and does not necessarily mean that it's also fast across the network 
> to any other node.

Okay, we didn't change anything about path selection so far. One reason
is that this might have serious consequences on anonymity. While it
would be great to make Tor and hidden services faster by using only the
best nodes available, this largely destroys anonymity. All changes here
should be made with extra caution!

> I'm interested in performance improvements of hidden services, but I'm talking 
> about RTT once the connections are established and not so much on the 
> connection setup time (which of course is also important but this time is 
> only spent once)
> 
> I did some RTT measurements and my observations are really ugly. It usually is 
> never below 5s. What you can observe is that when the circuit is rotated the 
> RTT also changes signifficant.

See the measurements in the analysis linked above. This document
contains some data about message transfer times after connections are
established. Basically, we excluded message transfer times from the
project, because they didn't seem to be a problem of hidden services,
but rather of Tor in general.

> My idea now was to open several circuits to the same hidden service. If 
> they're connected through different nodes (because of the random selection) 
> also the RTT will be different. Then I continuously do RTT measurements on 
> all those circuits and always use that one with the lowest time for user 
> data.

Even though this would constitute a local optimization, the effects on
overall network load would be seriously bad. There must be ways to
improve RTTs which waste less resources than this approach.

One solution might be to change path selection for rendezvous circuits,
both on client- and server-side. If we knew what relays to pick for
these circuits which are likely to deliver good RTTs, we could improve
RTTs for the 6-hop circuit from client to server. Again, changing path
selection requires caution as stated above.

Another solution is to start performing QoS for hidden services. In
combination with client authorization (see proposal 121), hidden servers
could decide whether to pick an extra-fast circuit to connect to the
client's rendezvous point, or not.

Having said that, did you look at proposal 121 for OnionCat. I could
imagine that OnionCat would make good use of the additional security
that client authorization offers for hidden services. See also a
Technical Report on that topic:

http://petsymposium.org/2008/hotpets/vrtprsvc.pdf

- --Karsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJQ8hE0M+WPffBEmURAgzYAJ95qU0k+V9Ic9hRVvMsNJWAbf8tSQCfYfnK
goWrW1jA183eTsvj5BJfcXo=
=5Mur
-----END PGP SIGNATURE-----