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

["Glymr Darkmoon" <glymr_darkmoon@xxxxxxx>]

On Thu, 2 Feb 2006 03:43:23 -0500, "Roger Dingledine" <arma@xxxxxxx>
said:
> On Mon, Jan 23, 2006 at 02:47:44PM +1000, glymr wrote:
> > >Actually, we already do something like this. Nodes report their uptime,
> > >and we assume that a long uptime implies that it will stay up.
> >
> > 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.
> 
> You're right. We've put this on the roadmap for the 0.1.2 release.
> 
> The other piece is that we want to track average amount of time per day
> that the server is live, so we know whether it's a suitable choice as
> a guard entry node.

ah these are good things to hear, definitely progress in the right
direction.
 
> > 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.
> 
> Ah. We are not likely to implement this. It seems hard to predict, before
> a connection happens, what traffic pattern it will have. Judging by port
> may be an ok approximation for now, but it will encourage the trend
> toward
> moving the whole Internet over port 80. Most importantly, middle nodes
> don't know the port/address/etc for the streams they're transporting,
> and we don't want to get into that fine-grained level of censorship.

i actually am running peerguardian on my system, i hadn't really thought
about the implications of this on a tor node, but then again, when i
think about it a bit further, that might explain why i haven't had near
the degree of traffic that i expected to have, a lot of the ip ranges it
blocks are to popular sites, but it doesn't block any of the known irc
server ips :)

i don't really mean it as a form of 'censorship' but my main point is to
create two classes of circuit, interactive low bandwidth and bursty high
bandwidth. These are the two main types of traffic transported on tor
and just as occurs on any connection, the better you can separate these
two types the better the performance on the former. It would not
constitute a security weakness or censorship to be able to selectively
transport one or the other type of traffic, but the benefits to users on
interactive connections would be immense.

> > 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.
> 
> Yes, but the increased chance of having a broken connection is bad. It
> seems that extending the path length will really hurt your reliability.
> 
> As for getting more security from more hops, see
> http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#LongerPath
> 
> But you're right that long-lived circuits may be more vulnerable. As
> far as I know, nobody has done any research on the implications of this
> in practice.

i guess it's all in progress, the development, but i think that
ultimately it would be best to focus on the interactive/bulk dichotomy
in traffic classes, and create a circuit migration system for
interactive circuits, possibly even a different circuit architecture
where packets are split between two paths in a random pattern, keeping
grouped blocks together on one path so there is no out of order
receiving going on - this might be possible by doing the switches during
times when an application has a significant gap between. extending the
circuits will increase latency but circuit migration would not. it's a
shame that tcp connections are routing bound or this wouldn't be a
problem, one could switch exit nodes as well then.

> > 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.
> 
> We would love to make progress on everything at once. Please help out
> (development or funding) and we will focus on this too.
> 
> --Roger
> 

speaking of which, i have some money in an egold account which i would
love to send to you guys :) is there any way for me to do this?

Glymr
-- 
  Glymr Darkmoon
  glymr_darkmoon@xxxxxxx

-- 
http://www.fastmail.fm - And now for something completely different?