Remailer Phases

[Anonymous Coredump]

Joseph Ashwood wrote:
> As has been pointed out it's not latency but latency/messages that
> matters.  If there are 2 messages a day going through the system
> then 5 minutes is simply not enough, it will be completely
> traceable. OTOH if there are 5000/sec going through the system then
> 5 minutes is arguably overkill.

Oh, I think I understand the confusion now.

There is a latency feature which allows a sender to request a message
be held for some specified length of time before being placed in the
message pool.  In essence, the arrival of the message to the core of
the remailer is delayed.

This is a fine feature - it is almost a requirement for a really good
remailer net.

However, the latency I am discussing is less complicated - it's just
the average time a message remains in the remailer when it's being
sent straight through the system with no extra latency requested.  In
other words, a message which is sent in such a way that transit time
is minimized.  It is not something the sender can, or would want to,
specify.

This value is a function only of the pool sizes of the remailers and
the number of messages sent through over a period of time.  

For example, let's say we have 10 remailers and 100 users.  How many
messages a day do these users have to send to see an average latency
of 5 min. per hop?  (Assume the pool size is 30.)

Each remailer must handle 30 msgs / 5 min. = 6 msgs/min, or 8,640
msgs/day.  Assuming each user routes their messages through 20 hops,
each message will go through each remailer twice, on average.  So, the
users will send 8,640 msgs/2 = 4,320 msgs during the day.  On average,
each user would send 43.2 messages per day, or one every 33.33
minutes.

So, you can see that this is quite feasible if people are sending any
news feeds, mailing lists, cover traffic, or even just a lot of e-mail
through the system.