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

[Roger Dingledine <arma@xxxxxxx>]

On Mon, Jan 23, 2006 at 12:36:53PM +1000, glymr wrote:
> 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.

> 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?

> 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:

LongLivedPorts PORTS
  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,
  8888)

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:
http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#MigrateStreams

What other approaches are there that might work?

--Roger