Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More Connection ID Space #2736

Open
martinduke opened this issue May 21, 2019 · 8 comments

Comments

@martinduke
Copy link
Contributor

commented May 21, 2019

Although it is quite late in the day for this objection, I find that we already bumping up against the limits of the 18 byte connection ID.

Inevitably, this touches on some issues we're exploring in the quic-load-balancers draft, which isn't adopted, and many of you are no doubt happily ignoring.

There are basically three uses of the 144 bits of CID entropy in QUIC-LB:

  1. Server ID encoding -- as there are only so many servers one might have, 16 bits is usually enough for this.
  2. "Private" server entropy -- the load balancer doesn't care what the bits are, but they're protected by crypto. The server created and encrypted the CID, so it can use this for its local purposes, but no one else can. The amount of this depends, but if you're using a 256-bit block cipher it's something like 240 bits -- plenty
  3. "Public" entropy -- not encrypted, these bits are readable by anyone who is familiar with the encoding scheme. With a 16 B encryption block, we have only 16 bits to play with here.

QUIC-LB is already taking 2 of these last bits for config rotation, which allows server pools to incrementally deploy new CID keys or encoding schemes. So we're down to 14 bits.

The public entropy is useful for a growing pile of trusted hardware devices that are presumably not going to perform CID decryption. On f5 boxes, we have a hardware disaggregator for the many dataplane processors and threads that are operating. Today, we'd use perhaps 8 of the bits, but in future architectures even 14 might not quite be enough.

And now, having chatting with Manasi Deval from Intel after her Prague talk about hardware offload, I'm fairly sure we're going to need 4 to cheaply encode the connection ID length, at least for servers that want to use this service.

If we ever wanted a solution that allowed multiple tiers of load balancing, which is not currently in scope for QUIC-LB, we don't have nearly enough space.

While I think that existing use cases can just barely make do with what we have, it is a bad sign if something in the invariants is already constraining use cases.

Offline in London, we've circulated a number of possible approaches to this, but the first-order discussion is a willingness to reopen the invariants. If so, there are a couple of solutions that won't break existing load balancer deployments.

I'm happy to write a PR if this is the consensus.

@ianswett

This comment has been minimized.

Copy link
Contributor

commented May 22, 2019

#1570 is a past issue about 1, 2, and 3 byte CIDs.

@ekr

This comment has been minimized.

Copy link
Collaborator

commented May 22, 2019

The two obvious encodings are:

uint8 cid_len
opaque cid[cid_len];
varint cid_len
opaque cid[cid_len]

@mnot mnot added the design label May 22, 2019

@MikeBishop

This comment has been minimized.

Copy link
Contributor

commented May 22, 2019

Both consume the same size for any currently-sane CID, but making path elements consume varints seems cruel.

@kazuho

This comment has been minimized.

Copy link
Member

commented May 22, 2019

I prefer retaining the current design, with the exception that CIDL is mapped to 4,6,8,...,34 bytes instead of 4,5,6,...,18 bytes.

@ekr

This comment has been minimized.

Copy link
Collaborator

commented May 22, 2019

Leading byte
Version
DCID len
DCID
SCID len
SCID
...
@martinthomson

This comment has been minimized.

Copy link
Member

commented May 22, 2019

You mean opaque cid<0..255>;. But I think that we need opaque cid<0, m..n>; where m > 0 and n < 256.

@ekr

This comment has been minimized.

Copy link
Collaborator

commented May 22, 2019

@martinthomson Those are the same thing, but I didn't want to make people consume TLS encoding i this bug :)

@mnot

This comment has been minimized.

Copy link
Member

commented May 22, 2019

Discussed in London; support in the room for doing this. @martinduke to make a PR.

@mnot mnot added this to Design Issues in Late Stage Processing May 22, 2019

@martinduke martinduke referenced a pull request that will close this issue May 22, 2019

Open

Allow longer CIDs #2749

@mnot mnot added the proposal-ready label Jun 11, 2019

@mnot mnot moved this from Design Issues to Consensus Emerging in Late Stage Processing Jun 11, 2019

@mnot mnot moved this from Consensus Emerging to Consensus Call issued in Late Stage Processing Jun 12, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.