Please don't mix two separate issues, Header Protection and mixing of
the DCID sequence number in the IV when doing multipath. The latter is
for ensuring the uniqueness of the nonce when using separate number
spaces for each path. It does make hardware offload more complex, but
not in the same way as Header Protection.
We did discuss the impact of adding 32 more bits in the IV on hardware
encryption last year, before deciding to abandon the "simple multipath"
option and go for the "number space per DCID" option. At the time, the
impact on hardware encryption was considered manageable.
-- Christian Huitema
On 3/8/2023 2:02 PM, Ian Swett wrote:
Speaking as an individual, I would like to see this discussed more in the
QUIC WG, possibly in Yokohama.
Header Protection/PNE definitely helps with ossification, but when compared
with highly optimized and sometimes non-standard networking protocols, QUIC
without PNE is a huge improvement. In a datacenter environment,
ossification is a concern, but it's rarely due to the wire image.
Ian
On Wed, Mar 8, 2023 at 8:02 AM Boris Pismenny <borispisme...@gmail.com>
wrote:
What I want to add is that you should consider multipath QUIC when you
design your hardware. It affects the AEAD nonce generation.
Regular, unipath, QUIC sets the top 34 bits of the packet number to zero
when generating the nonce. In the upcoming multipath extension, the top 32
bits can be set to non-zero values.
https://www.rfc-editor.org/rfc/rfc9001.html#name-aead-usage
https://www.ietf.org/archive/id/draft-ietf-quic-multipath-03.html#name-packet-protection-for-quic
-
Thanks for the pointers, I've encountered multi-path QUIC on another
discussion about QUIC offload (
https://github.com/microsoft/quic-offloads/issues/9#issuecomment-1305823308
<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-88d69ea0099e1120&q=1&e=e27b5977-1b4e-4703-957b-3236511a2976&u=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fquic-offloads%2Fissues%2F9%23issuecomment-1305823308>).
IIUC, the main challenge with multipath will be to synchronize receive side
NIC offloads when two NICs are being used in parallel to carry the same
flow's packet number space.
There will only be separate packet number spaces for each path in the
upcoming version of the multipath draft. Then I guess you will not have the
problem you mention above. If you still would, why is this not a problem
with regular unipath QUIC?
Indeed, this can also happen with unipath QUIC. In both cases, it is
probably not the common case. But, if it does happen, it will make
offloading more challenging.
