[tor-dev] Proposal 214: Allow 4-byte circuit IDs in a new link protocol

Nick Mathewson nickm at alum.mit.edu
Wed Nov 7 03:10:15 UTC 2012


On Tue, Nov 6, 2012 at 9:55 PM, Roger Dingledine <arma at mit.edu> wrote:

> On Tue, Nov 06, 2012 at 09:36:34PM -0500, Nick Mathewson wrote:
> >    Relays are running out of circuit IDs.  It's time to make the field
> >    bigger.
>
> I don't doubt the second sentence, but is the first sentence actually
> true? Do we have any evidence / measurements / something here?
>
> (Since circids are relative to the connection they're on, it's not clear
> to me that any given TLS connection accrues more than a few tens of
> thousands of circuits.


I think that's enough?  32K from A to B, or from B to A, is where we run
out.  So if A is a popular middle node, and B is a popular exit, most of
the circuits between A and B will be A->B.  So if we get "a few tens of
thousands" of circuits from A to B, we hit the limit.


> And if a very few do, maybe the solution is to
> move to a new TLS connection for those rare cases, rather than impose
> a 2-byte penalty on every cell in all cases.)
>

Maaaybe, but I sure can't think of a sane testable design for that.  Can
you?  To do this sanely, we'd need to negotiate this before we exchange any
actual data, and predict in advance that we'd want it. (We wouldn't want to
do it on-the-fly for connections that happen to have large numbers of
circuits: that way lies madness.)

Also, I think those "rare cases" are communications between the busiest Tor
nodes.  I think those communications might represent a reasonably large
fraction of total Tor bytes, such that having a fallback mode might not
save us so much.

And also, this only adds 1/256 additonal overhead before TLS happens.  Not
huge IMO.  We could save far more than that by more intelligent TLS use, if
we needed to.

-- 
Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20121106/be1b8f9d/attachment.html>


More information about the tor-dev mailing list