[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

an idea about how to improve routing for interactive services


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.