architectural proposal & technical problems

Nick Mathewson nickm at
Fri Apr 27 16:39:13 UTC 2007

[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.

Nick Mathewson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: not available
URL: <>

More information about the tor-dev mailing list