[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: an idea about how to improve routing for interactive services
Roger Dingledine wrote:
On Mon, Jan 23, 2006 at 12:36:53PM +1000, glymr wrote:yes, that's not a good assumption to make however. average uptime is a
more useful metric, when a system has been up for a long time it may be
just about to go down. also, for irc users, a connection which can stay
up for 8 hours or more is regarded as quite adequate by most.
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.
Actually, we already do something like this. Nodes report their uptime,
and we assume that a long uptime implies that it will stay up.
what i mean is, different ports, for different protocols, have different
traffic characteristics. irc, silc, msn, aim/icq, jabber etc, these are
all long lived and mostly low bandwidth connections, whereas web
browsing is short lived and bursty. they should be treated differently.
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.
I'm not sure I understand this part. You are using an external tool to
traffic shape the stuff you send into Tor? Or you are using an external
tool to traffic shape the stuff that exits from your Tor server?
regarding the shaper, yes, i'm shaping the bandwidth that comes out of
my tor server so that it limits it, but because i have specified that it
only allows exit with irc and silc, to a large degree that will reduce
the amount of bursty high bandwidth connections it creates, once my node
is up for the 'long uptime' period (i'm still nutting out some problems
with a new installation, but i'm hoping i'll have over 24 hours uptime
but unfortunately there is nothing yet in the protocol to stop my node
being a part of a bursty, short-lived high-bandwidth circuit. being able
to control this would be very useful. and that's what i'm talking about,
having two classes of traffic in tor, so that nodes that have good
uptime but low bandwidth can contribute to improving the interactive
connection experience with tor.
I think that what i have described is the, at this point at least, best
answer to the problem of improving long lived interactive connections.
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.
Right, we do this too.
Check out the man page entry:
A list of ports for services that tend to have long-running connec-
tions (e.g. chat and interactive shells). Circuits for streams that
use these ports will contain only high-uptime nodes, to reduce the
chance that a node will go down before the stream is finished.
(Default: 21, 22, 706, 1863, 5050, 5190, 5222, 5223, 6667, 8300,
In 0.1.0.x, "high-uptime" is defined as "claiming an uptime of at least 24
hours." In 0.1.1.11-alpha, high-uptime is defined as meeting or exceeding
the median uptime of running valid servers. On the current Tor network
this tends to vary between 2 to 3 days.
But this clearly does not totally solve the problem: long-term connections
over Tor do still break. Part of this is because the Tor network is very
young and still quite dynamic, so people are upgrading, restarting their
servers, and so on. There is also clearly a tension between scaling the
network (and thus being more flexible about the volunteers we can make
use of) and providing stable links.
Another nice approach would be to be able to move streams to a new
circuit if the current one dies. But this has its own problems:
What other approaches are there that might work?
One other point that might be worth mentioning is that these long lived
connections would probably benefit, due to their long life and low ping,
from having 4 or 5 hops instead of 3 to help reduce the traffic analysis
problem, since it would be very easy to have a lot more people running
these low capacity high uptime nodes, the extra traffic is insignificant.
Oh, and because these connections are very low bandwidth, it could be
incorporated into the client to automatically relay traffic from known
low bandwidth ports, if the client finds itself with a high uptime average.
Think about how important persistence is with interactive connections.
SSH is a classic example... what happens if you are in the middle of
some irritaingly long process and suddenly your connection pings out? I
think that there should be a priority made in the tor architecture to
promote this kind of use of tor because it's probably the most delicate,
security wise. Consider the benefits for activists being able to use
instant messaging without being monitored, for organising and such.