See if we can have 512-byte cells again
Concurrently with proposal 340, it could be nice to reduce cell length to 512 bytes again. (It increased to 514 bytes when we added support for 32-bit circuit IDs.) See discussions on #174 (closed) for a bit of motivation from @mikeperry and @dgoulet.
This is a nontrivial change, however. Unlike with proposal 340, we can't make this change only apply at the client and the exit: it needs support from the intermediate relays on the circuit as well.
To get 512-byte cells, we need to answer a few questions:
- What does relay crypto look like with this change? Where do we negotiate the cell length with the intermediate hops? Do we have to negotiate the same cell length with every hop, or can we somehow support mixed-cell-length circuits1? If we need the same cell length with every hop, how do we handle the migration period?
- What does the channel protocol look like with this change? Assuming that the same channels need to hold 514-byte cells and 512-byte cells, do we need an extra byte per cell to tell which kind is which? And how do we eventually throw out that byte?
The very easiest way to build this change would probably be as follows:
- Channels use the high bit of the channel command to distinguish cell length (for now).
- Circuits must be all-512-byte or all-514-byte. The format is determined by an ntor3 parameter.
- We use a consensus parameter to tell clients that it is okay to start using 512-byte circuits. We do this once at least 85% of the relays on the network support all-512-byte circuits. (This change is necessary, or else these circuits will be so rare that they will be easy to trace)
- Once 100% of the relays are upgraded, we tell clients to stop using the 514-byte protocol.
- Once 100% of the relays are upgraded, we use a new channel protocol to un-reserve the high bit of the channel command.
I can probably design something like this, but the clunky migration suggests that maybe we should do it at another time when we have a change that would plausibly need whole-circuit support. Maybe this would be good to bundle with an enhanced relay crypto? (We don't strictly need whole-circuit support for that, but it would make the analysis simpler at the expense of making security benefits slower to roll out.)
Since this is a trickier rollout than the other cell changes, I would also like to ask: How confident are we that this change will give real benefits? What amount of performance improvement would we expect here?
-
I think that generalized mixed-cell-length circuits are probably too hard to do safely, but I'm open to ideas. My first few designs were vulnerable to interesting padding attacks.
↩