architectural proposal & technical problems

[Nick Mathewson]

[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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20070427/a3a328c6/attachment.pgp>