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