Hidden Service Performance [was: Re: How many hidden service circuits built?]
On Saturday 13 December 2008, Karsten Loesing wrote: 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 Thanks, I had a look at it. Your measurements regarding message transfer reflect pretty much the observations I did. 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! Of course, you are right. Changes in the path selection algorithm should be done with caution. But it was just an idea which looked feasible for me from a user perspective (SOCKS interface) without changing TOR, thus not risking loss of anonymity. 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. That could also be possible. I didn't scientifically proven measurements yet, but I will do. Maybe it's a problem of TOR *and* hidden services. 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 QoS sounds good but I think it might have same troubles in its deployment as it has in plain Internet. QoS was foreseen in IP since decades but never used network-wide. Until today QoS is always a local service limited to the network of a provider or company. I can imagine that QoS deployment will last very long until it works TOR-network-wide for similar reasons. Regarding authorization: Thanks, I already knew proposal 121 before and I did test those authorizations features. They work and seem to be very useful for some scenarios. Best Regards, Bernhard signature.asc Description: This is a digitally signed message part.
Re: How many hidden service circuits built?
-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-
Re: How many hidden service circuits built?
On Thursday 11 December 2008, Roger Dingledine wrote: On Thu, Dec 11, 2008 at 11:25:40PM +0100, Bernhard Fischer wrote: If I connect through the SOCKS interface several times at the same time to the same hidden service, does TOR open a bunch of circuits in parallel to the designated hidden service or does it just open a single one and then reuse it for every of the incoming SOCKS request? It should try to reuse the same circuit. (You will see a bunch of circuits going to make the rendezvous happen, but only one of them will be the one that all your streams get connected to.) --Roger Is it possible to change this behavior (maybe by a slight modification of the source)? Best regards, Bernhard signature.asc Description: This is a digitally signed message part.
Re: How many hidden service circuits built?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bernhard Fischer wrote: On Thursday 11 December 2008, Roger Dingledine wrote: On Thu, Dec 11, 2008 at 11:25:40PM +0100, Bernhard Fischer wrote: If I connect through the SOCKS interface several times at the same time to the same hidden service, does TOR open a bunch of circuits in parallel to the designated hidden service or does it just open a single one and then reuse it for every of the incoming SOCKS request? It should try to reuse the same circuit. (You will see a bunch of circuits going to make the rendezvous happen, but only one of them will be the one that all your streams get connected to.) --Roger Is it possible to change this behavior (maybe by a slight modification of the source)? I'm not sure what you are up to, so I'm guessing. Are you asking for a) parallelizing connection establishment in order to reduce delay, b) having a separate circuit to the hidden server for every application-level stream, or something else? As for a), we are already working on improvements to reduce the delay in connection establishment. Did you have a look at this page?: https://www.torproject.org/projects/hidserv.html Part of the solution is to parallelize some of the substeps. One example are circuits to introduction points which are built in parallel after a delay of 15 seconds. Future ideas are to request hidden service descriptors from the directories in parallel. But making two (or even more) full connection establishments with all steps being performed twice (or more times) is a bit too brute-force, isn't it? The goal is to make hidden services faster, but in a way that doesn't put too much new load on the network. As for b), I don't know if this makes sense, either. Why separate the circuits when you can multiplex an arbitrary number of streams over them? Fault tolerance? Unlinkability of streams? But instead of guessing what you had in mind, I'll just ask: Why do you want to do this? - --Karsten -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJQkiP0M+WPffBEmURAsmuAJ4lf5aPZBg7IEXw0hzW4aCb0Ve2CgCfW37x ki2Nf2vTOF9Z+jRX8GevDfU= =1DHP -END PGP SIGNATURE-
Re: How many hidden service circuits built?
On Friday 12 December 2008, Karsten Loesing wrote: Bernhard Fischer wrote: On Thursday 11 December 2008, Roger Dingledine wrote: On Thu, Dec 11, 2008 at 11:25:40PM +0100, Bernhard Fischer wrote: If I connect through the SOCKS interface several times at the same time to the same hidden service, does TOR open a bunch of circuits in parallel to the designated hidden service or does it just open a single one and then reuse it for every of the incoming SOCKS request? It should try to reuse the same circuit. (You will see a bunch of circuits going to make the rendezvous happen, but only one of them will be the one that all your streams get connected to.) --Roger Is it possible to change this behavior (maybe by a slight modification of the source)? I'm not sure what you are up to, so I'm guessing. Are you asking for a) parallelizing connection establishment in order to reduce delay, b) having a separate circuit to the hidden server for every application-level stream, or something else? As for a), we are already working on improvements to reduce the delay in connection establishment. Did you have a look at this page?: https://www.torproject.org/projects/hidserv.html Sorry, I didn't see this before. I'll read your paper and I appreciate all improvements regarding hidden services. As for b), I don't know if this makes sense, either. Why separate the circuits when you can multiplex an arbitrary number of streams over them? Fault tolerance? Unlinkability of streams? But instead of guessing what you had in mind, I'll just ask: Why do you want to do this? You guessed pretty good ;) 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. 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. 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. Best regard, Bernhard signature.asc Description: This is a digitally signed message part.
How many hidden service circuits built?
If I connect through the SOCKS interface several times at the same time to the same hidden service, does TOR open a bunch of circuits in parallel to the designated hidden service or does it just open a single one and then reuse it for every of the incoming SOCKS request? Thanks, Bernhard signature.asc Description: This is a digitally signed message part.
Re: How many hidden service circuits built?
On Thu, Dec 11, 2008 at 11:25:40PM +0100, Bernhard Fischer wrote: If I connect through the SOCKS interface several times at the same time to the same hidden service, does TOR open a bunch of circuits in parallel to the designated hidden service or does it just open a single one and then reuse it for every of the incoming SOCKS request? It should try to reuse the same circuit. (You will see a bunch of circuits going to make the rendezvous happen, but only one of them will be the one that all your streams get connected to.) --Roger
