[or-cvs] Implemented link padding and receiver token buckets

[Roger Dingledine]

On Wed, Jul 17, 2002 at 02:58:20PM +0100, Andrei Serjantov wrote:
> But then surely, if you want to find out the bandwidth of real traffic on
> the network, you just attack the network and then watch the traffic in the
> next few seconds and it will all be real traffic. I think you have to
> implement another one of these random back-off schemes I proposed: as the
> network is songested, put in fewer and fewer dummies and then you may
> rearrange the order of the dummies and real traffic in a fairly random
> fashion as well. Should I work out the details or are we not going to
> bother with such things? What I said above is a fairly weak attack, so I
> don;t mind either way.

Ok, here's my first pass at a fix, in terms of ease of current
implementation.

Whenever you queue a data cell onto an outbuf, with some probability
(say, 20%) you also queue a padding cell (either in front or behind the
data cell). If you prefer, we can flip a biased coin, and as long as it
comes up "padding" we add a padding cell and flip the coin again.

Would that address your issue? But yes, more broadly, I think Paul's
right that we shouldn't be solving some of the timing issues while
leaving others wide open. :)

--Roger