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 <[email protected]> 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. >
