[Also answering on or-dev.] On Wed, Apr 18, 2007 at 03:12:44PM +0200, Johannes Renner wrote: > Hello, > > I want to show you an architectural proposal for my project > and ask you about some technical questions/problems I worry > about. Besides that I would like to ask you for your general > opinion about it. The following is only a rough description > of an architecture, please have a look at the arch.pdf and feel > free to discuss: > > The first part is an addon for ORs, that is using the Tor > control protocol to listen for events (mainly ORCONN and/or > STREAM_BW), records bandwidth-data about single TLS-connections > the router maintains to other ORs, and simply provides this > data for requesting clients. The recordings can be done in a > configurable way and would provide e.g. max observed throughput > of some period as well as current average of last n minutes > (just a current value would be much better, but also much worse > for anonymity). We believe that the difference between max and > current avg correlates with the still available bandwidth of a link. > > The second part is a QoS-addon for OPs, that will contain the > algorithms for route selection. It can post requests to receive > the list of bw-information from an OR-addon. In addition to this > it does active measurings of latencies/RTTs through Tor and records > that data. Using these two orthogonal informations we can then > build fast circuits from here and attach the streams to them > using the control protocol. > > Now this all seems to be possible using Tor control protocol, but > there are two things I worry about : > > 1. In OnionCoffee I can do measurings of RTTs in the following > style: I take an established circuit and, as I already told > you, send a relay connect cell to connect to localhost over > it. I measure the time until I receive my relay end cell and > thus get the RTT of the whole circuit. I can do this not only > for three-hop circuits, but also for partial circuits: > By simply using only one or two onion skins I can address the > first or the second router in a circuit. By subtracting I can > then compute values for the single links between the routers. > Of course this is not the intended use for relay connect cells, > but it is working quite well (until we introduce something like > a ping-cell?). Unfortunately the original Tor software does not > offer me any possibilities to do such partial measurings. The > only possibility there is at the moment is to use Socks to try > to connect to localhost, but this only works for whole circuits > and is a bit of a detour. The most convenient way would be to > extend TC so that it could be possibly used to receive this data, > e.g. introduce a new command that lets Tor do the actual > measurings like "measureRTT(circID, addressedRouter)". > Tor-TODO (#8 under Research) already pinpoints that it would be > nice to make use of the ability to let some streams exit from > the second hop, some from the third, and so on. > Having the possibility to choose arbitrary exits within one > circuit would also enable us to do the measurements on > partial circuits. What do you think about that? This should be do-able by modifying the control protocol to adding an extra flag to ATTACHSTREAM, right? That is, you'd have a controller listen for circuit and stream events. You'd tell the controller to build a circuit. Then you'd launch a stream to localost and say something like, ATTACHSTREAM (yourstream) (yourcircuit) HOP=2 to attach the stream to the second hop. Then you'd time the delay between the ATTACHSTREAM and receiving the END cell. > 2. The OR-addon needs to set a flag in the ORs router descriptor, > to tell clients, that it is providing bw-data. So how can I set > an "opt"-flag in my ORs descriptor just to tell the directory > that I am using my addon? Is there any way to do this, preferably > via the control protocol? There's no way currently to tell _just_ the directory about something. All information goes into your descriptor, or it does not. The descriptor gets uploaded to the directory authorities, and clients download it from the caches. I guess we could have a controller feature that let you set extra flags values in descriptor. For safety, we'd probably want them to start with "X-", like extension headers in email or http. There is an accepted proposal in progress of implementation that has a separate "extra info" document containing data that most users don't care about. Check out proposal 104 for more info on that. -------------------- Now for stuff from later emails. (I like to batch.) WRT your idea for a separate "bandwidthinformer" port: I don't see the need for that. How about this idea instead: For a while, we've been meaning to have _all_ routers, even routers that aren't directory caches, accept BEGIN_DIR commands to retrieve a limited amount of directory information via Tor connections. Caches would serve everything that they would serve normally; non-caches would only serve their own descriptor. Given this, I think you could just make any bandwidth information that you decide it's important to serve a separate document served this way. Of course, if you want to have routers potentially send this much info, there are bandwidth issues to consider. You'll probably want to write up a unified design before you push too far ahead. Publishing this much information is probably good for an research phase of your project phase, but potentially not so good for long-term use. As for the CONNECT idea: I'm not sure I see what CONNECT would get you that an extended ATTACHSTREAM wouldn't. Yes, ATTACHSTREAM requires you to launch a new SOCKS connection to Tor, but ATTACHSTREAM has an advantage over your CONNECT proposal: if the connection _doesn't_ fail, your proposal leaves no good way to actually use the newly created connection. yrs, -- Nick Mathewson
Attachment:
pgpv8vI7G9kKp.pgp
Description: PGP signature