an idea about how to improve routing for interactive services

[glymr]

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
>