Bandwidth throttling (was Re: Padding)

Roger Dingledine arma at
Fri Jul 5 06:05:31 UTC 2002

On Thu, Jul 04, 2002 at 03:07:25PM -0400, Roger Dingledine wrote:
> > Yes that's the sort of idea I had with ACK/NACK cells - but there is no 
> > provision for discarding cells. I think we need to be able to drop cells
> > (at each node, in whichever way we like) to protect against DoS. In this 
> > idea, a node can't drop a cell once it has received it because it isn't 
> > being buffered anywhere else. So should we not consider end-to-end (OP -> 
> > COR_last) flow control?
> I don't think dropping cells solves our problem. If you are going to have
> to drop the cell, then you shouldn't be reading it in the first place. If

Ok, I have a more coherent argument for this now. :)

There are two approaches to these anonymous communication systems.

One approach is to have tcp connections between nodes, and some sort
of simple flow control and link padding/traffic shaping on top of
that. This is a much less flexible approach, because it only works for
tcp connections, and it's unclear how it will perform for real-time
things like ssh. It also requires that the network designers anticipate
all the protocols they want to support, and come up with client proxies
for each protocol. Doing a client proxy for ssh is going to be a real
bugger. On the other hand, the network itself should be simpler to build
and simpler to understand.

The second approach uses udp between nodes --- it basically packages
up each packet, sends it along the hops, and unwraps it at the end. It
can do packet rewriting at the end to correct IPs. It can handle any
sort of protocol, ranging from ping to ssh, including new ones that the
system designers didn't know about. If a given node is congested it will
drop the packets, and the end-to-end tcp connections will recognize this,
adjust windows, and resend. This is a fine approach, and it's the one that
Freedom and its successor Cebolla take. However, it's harder to get right,
and much more complex to tune. In also requires a kernel patch in the
general case, to capture all packets and redirect them into the anonymity
network (but arguably with modern things like ipchains and tc, you can
do it entirely in userspace (but Windows users are out in the cold)).

People are already trying to do the second approach, but nobody's doing
the first. It could well be that the second is the better engineering
answer. Perhaps we should all pack up and go home, and wait for Zach
Brown to finish it. :) (He's got working code, btw. He demo'ed it at
the Ottawa Linux Symposium.) But the first approach is easier for me to
understand, and I get to avoid a) learning all about internet packets,
and b) reimplementing protocols like tcp.

It's this second reason that makes me want to not deal with dropping
cells. I'd like to keep the protocol simple, and so I want to avoid
adding sequence numbers, dropping cells, acks/nacks, etc. If we want
to add complexity, then after a certain point I'll vote for switching
entirely to the second approach.

I'd like other perspectives on this too -- Matej? Bruce? Paul? Andrei?

I'm tempted to mail Zach and try to get him into some of
these discussions. You can read his paper at page 55 of


More information about the tor-dev mailing list