Intel's Manasi Deval is interested in hardware acceleration of QUIC, certainly including crypto offload.
For this to work, there needs to be some indication of CID length in short headers. Alternatives are not viable.
1) Requiring a single CID length to work with the hardware is not compatible with many CID encoding schemes, unless that number is uncomfortably large (i.e. 18)
2) Specifying a minimum CID length for HW offload would allow disaggregation, but doesn't help find the packet number, which is important for decryption
3) A prefix matching approach (match bytes in succession until you find only one CID in the table that matches) can work, but is uneconomical for large tables.
One possibility is to make it part of the base standard.
However, to minimize that pain and keep CIDs completely opaque in the general case, another approach is to make it part of QUIC-LB. This views the crypto offload as another kind of "trusted middlebox". The encoding scheme could include four bits in plaintext that encodes the length. Given the minimum lengths in QUIC-LB, we could even get away with three bits if we disallowed a couple of otherwise legal values.
We might reduce the cost a bit by putting config rotation in the reserved bits of the first byte (thus unprotecting them), though that's a somewhat separate issue.
Intel's Manasi Deval is interested in hardware acceleration of QUIC, certainly including crypto offload.
For this to work, there needs to be some indication of CID length in short headers. Alternatives are not viable. 1) Requiring a single CID length to work with the hardware is not compatible with many CID encoding schemes, unless that number is uncomfortably large (i.e. 18) 2) Specifying a minimum CID length for HW offload would allow disaggregation, but doesn't help find the packet number, which is important for decryption 3) A prefix matching approach (match bytes in succession until you find only one CID in the table that matches) can work, but is uneconomical for large tables.
One possibility is to make it part of the base standard.
However, to minimize that pain and keep CIDs completely opaque in the general case, another approach is to make it part of QUIC-LB. This views the crypto offload as another kind of "trusted middlebox". The encoding scheme could include four bits in plaintext that encodes the length. Given the minimum lengths in QUIC-LB, we could even get away with three bits if we disallowed a couple of otherwise legal values.
We might reduce the cost a bit by putting config rotation in the reserved bits of the first byte (thus unprotecting them), though that's a somewhat separate issue.