an idea about how to improve routing for interactive services

[ADB]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20060123/d92f2ddf/attachment.htm>