In my response to Christian Huitema, I suggest a design that fully supports client-side zero-length connection IDs but only uses multiple PN spaces. In addition to (noticeably) reduced complexity, it has these advantages:
1. Support for full use of ECN also for paths with zero-length connection IDs 2. Enabling (or at least simplifying) hardware offload when using zero-length connection IDs /me ________________________________ From: Yanmei Liu <[email protected]><mailto:[email protected]> To: mailing-lists.ietf.quic Subject: Heads up -- unifying of multipath options. Date: Wed, 15 Jun 2022 12:12:16 +0200 (Central European Summer Time) Hi everyone, As a member of the mpquic-authors group, we’re really open for different ideas and suggestions, and this could help to draw a conclusion on whether or not we should merge PR #103<https://github.com/quicwg/multipath/pull/103>, and publish these changes in a new version(-02) before IETF 114. As an individual, I’d like to express a little about why I support the effort for the unified proposal. For the following reasons: * As we could analyze from mechanism and experience data, multiple PN spaces take the best efficiency of ACK frames because of less ACK range holes. For scenarios which use non-zero Connection IDs, it’s clear that choose multiple pn space solution would get better performance. * For scenarios which use zero-length Connection IDs, the natural way to support multi-path is to use single PN space under all paths. PR #103<https://github.com/quicwg/multipath/pull/103> is the combination of the most valuable part for both single and multiple PN space solutions. We could get best ACK efficiency and support zero-length Connection IDs at the same time. Besides, we don’t have the risk of failure for interop test (this could happen if 2 endpoints choose to support different PN space solutions in the current version -01). In the unified version, we could distinguish these situations with the CID in the packet header. Please feel free to let us know your opinions. Best regards, Yanmei
