>
>
>
>> 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.
