an idea about how to improve routing for interactive services

glymr glymr_darkmoon at ml1.net
Mon Jan 23 02:36:53 UTC 2006


Hi,

I've been running a tor server on and off for some time, I just recently 
got a dsl connection again, only a measly 256/64 connection, and one of 
my main uses for tor has always been instant messaging.

One of the most annoying things about tor, as it is presently run, for 
instant messaging purposes, is getting circuits which die frequently. I 
have an idea about how this problem could be solved, and I feel that 
this idea should be promoted at tor.eff.org - of specialised interactive 
traffic only nodes. This could be integrated into the configuration 
system in fact. The rules for how to define what one should set a node 
to do are as follows:

    1. If a node is run which is frequently offline, but with high
    bandwidth, this is suited to short-lived traffic, such as downloads
    of files (p2p, web browsing).

    2. If a node has low bandwidth, and can be kept online for long
    periods of time, this is the ideal situation for low-volume
    interactive traffic.


These rules could be used to weight classes of ports, a node could keep 
a history of its uptime, and report its average uptime value accumulated 
over time to the directory. This would help for choosing interactive 
traffic routes, the longer the average uptime, the greater the chance of 
it being picked on interactive circuits.

A cumulative history of average bandwidth usage would be added to this, 
and through the combination of these two, routers could create a pair of 
different classes of circuits, long lived circuits and short lived 
circuits, and one could overlay this and create another two classes of 
circuit, short-lived, low bandwidth circuits and long-lived 
high-bandwidth circuits. This second set of classes is probably not so 
important.

Tor could automatically select it's preference for the different traffic 
classes according to these values. At this point, without an automated 
system to do this, it can be done by users (as I am doing) - by using a 
rate-limiting system (netlimiter) and allowing only a small set of 
interactive traffic types through (in my case, irc and silc) - since tor 
precludes the use of file transfers on these two protocols, I set the 
rate limiting between 2 and 4kb/s depending on whether I am downloading 
more or chatting more.

However, I think it would be a worthwhile addition to the system by 
which Tor does its routing to use these rules in both the production of 
an uptime and bandwidth average, which is used by clients to select a 
pair of different circuit classes, interactive and high volume. High 
volume traffic usually is short lived, and interactive traffic is 
usually long lived. By specialising the circuits according to these 
rules one would find that interactivity is better promoted, and 
separated from volume.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20060123/49002ff7/attachment.htm>


More information about the tor-talk mailing list