architectural proposal & technical problems

[Johannes Renner]

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

Nick Mathewson wrote:
>   - It may soon be possible to have Tor servers serve descriptor-like
>     documents via Tor whether they are directories or not.
>   - The underlying protocol is HTTP, so it is easy to add new URLs.
>   - If you want to serve a new kind of information, the easiest way
>     could be to have that information served at a new URL, rather than
>     at a new port.

Aah ok, now I know .. You are right, that is of course the most simple way
to do this. I still would be able to generate a document in a controller
and just have to put it in the right place to be served by the OR. Actually
this would be much easier than opening a separate port.

> Though actually, if (as you say) the idea is to have it be
> experimental for now to figure out what works, it could be just as
> easy to have a separate port for it for the moment.  I don't think I
> can form much more of an opinion here until we know more about what's
> in the documents, and what's in your actual design.

A good format of such a document still has to be researched and specified,
but it will contain something like a list of averaged information about
the bandwidth/throughput of each TLS-link a running OR maintains as well
as about the total averaged throughput of the node. These get measured by
listening to bw and orconn-bw events for a configured short-term interval
(e.g. one minute) and examining the bytes read and written. I think that
the measuring method is quite an elegant one, because it does not produce
any extra traffic and simply counts traffic where it is already flowing.
Furthermore a max value for each TLS-connection and the total node's bw
will be delivered that was reached within a single interval in the last
long-term period (e.g. one hour). These documents shall (in a first step)
be downloaded by controllers of clients, that use the received values to
compute something like an "estimated currently available" bandwidth of
the links to support routing decisions. This is to make it simpler to
research, but as Mike already wrote this has a problem with lying, even
though you could still try to choose links for circuits in a probabilistic
way. So, later on we should maybe think about an alternate directory that
could be gathering and merging such information from all of the supporting
routers. Additionally, a client-controller does RTT-measurings for single
links, like I already explained in earlier messages, and finally chooses
routes using all of the gathered information.

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

iD8DBQFGO11j1TFW0/n+aNgRAuoiAKCE14oSJ7CuccQqj90X/YnaqaOg1wCgngJF
KJhHdQCzCKdSePbHcd8oUZA=
=Nmva
-----END PGP SIGNATURE-----