multiplexing over circuits too

[Roger Dingledine]

Right now the client builds an onion for every new tcp connection,
which in turn creates a new circuit on the network. In other words,
the onion routers do three or four public key decrypts for every picture
loaded from cnn.com. An RSA oaep decrypt on a 1024 bit key is 7ms on my
1GHz Athlon, so that puts us at 150 decrypts per second per node tops,
and more likely closer to 50 decrypts per second.

So it's going to be a race to see whether we run out of bandwidth or
cpu first on the servers. One answer is to add crypto hardware to the
servers so they can handle more decrypts each second. But that's not a
very flexible / extensible / cheap answer.

Another answer is to encourage people to use http/1.1's persistent
connections, so a single tcp connection is made to www.cnn.com, and
many GET requests are made over that one connection. That will help us,
but only by a bit.

A third answer would be to step back and try to convince ourselves
that our users don't actually generate that many new web requests each
second, so being able to handle 15 new circuits per second per node in
the network is plenty. I think this reasoning won't work very far.

A fourth answer is to add another layer of multiplexing. Each connection
currently handles multiple circuits and distinguishes them via the
'aci' identifier. We might treat the first 4 bytes of each data
cell's payload as special. (Perhaps call it the 'topic', to follow our
conversation metaphor? Other names are 'request'..somebody give me a
better one?) Creates and destroys continue to work as before. But now
when you're an endpoint node in a circuit, you examine the topic. The
first byte describes the command (one of "open a new topic to the site
that the rest of this data cell describes", "this is a data cell for
an established topic", "this topic should close", "your topic is ready
to start talking about" (which lets me remove the separate 'connected'
cell type), etc), and the remaining bytes of the topic identifier specify
which topic we're talking about.

Effectively we're allowing the users to build a tunnel to the exit point,
and from there they can make a variety of requests, even to different
servers, without laying down a new circuit. We use the same symmetric key
at each hop for all topics, and indeed only the exit node can distinguish
between different topics.

Of course, the cost is that now our users are more profilable because
they're linking together actions at a variety of websites. I'm not sure
what a good interface would be to let the user have multiple nyms and
switch between them. On the surface these 'topics' are easy to add,
but they may be introducing lots of complexity when we try to retain
anonymity. Hm.
Thoughts?

--Roger