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

Re: an idea about how to improve routing for interactive services



yes, windows network system is seriously crappy at scheduling. i'm using winxp but i've got netlimiter installed for ratelimiting.

ADB wrote:

What OS are you using? I used to have this problem all the time with Windows, and it got worse over time as the system got more and more FUBARed. However, since switching entirely to Linux, I have not had any of these issues more than once every week or so. This is just my case though perhaps others have this issue on other platforms more frequently.

~Andrew

glymr wrote:

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