Document: draft-ietf-quic-multipath Title: Managing multiple paths for a QUIC connection Reviewer: Carsten Bormann Review result: Ready with Nits
[Insert ARTART boilerplate here] This specification builds on QUIC's capabilities for connection migration to use multiple paths simultaneously for a single connection. It provides a mechanism for managing state necessary for running the QUIC protocol with multiple concurrent paths, but deliberately leaves address discovery, scheduling of packets over multiple paths, and congestion control out of scope. It is refreshing to see that the mechanism for multipath is being specified before the obvious blanks (congestion control, scheduling) can be filled in in a normative way. The word “application” occurs about a dozen times, often in constructs such as “suit the needs of the application”. For example, the "[...]decision to setup or tear down paths are assumed to be handled by the application" (introduction). This reader expects some considerable innovation in how these needs and decisions are communicated to the QUIC implementation, or, where the application is in control, modulated by the state of the QUIC implementation. ## General editorial In some places, the document is heavy on passive usage. On the passive sentences, it is not always clear to a new reader who the actor is, or whether the verb is actually used as an adjective (e.g., see last sentence of 3.1.2). ## Minor 2.1: Path ID is supposed to be an unsigned integer < 2**32, but then 2.4 talks about the “least significant 32 bits of path_id”. (It is also confusing that the term “value” is used for both the type, which is a 60-bit number during the experiment phase, and the value of the transport parameter.) 3.2.1: Is the “maximum path ID limit” discussed here related to initial_max_path_id/MAX_PATH_ID? Is the “active path limit” the same thing? 4.7 has a “maximum path ID that was allowed” — by whom? (Maybe it would be worth to introduce clear terms for the most recently unilaterally declared [ignoring non-monotonic MAX_PATH messages] and the combined value state.) This reader does not understand how concurrent allocation on the shared number space of path IDs is managed. Do the peer applications have to run some protocol to agree on how which path ID is used for what? What happens when this protocol and the protocol specified here run out of sync? Who controls the parameters (e.g., diffserv markings) used with a specific path ID? 4.3 and elsewhere (3 times): s/monotonically increasing/strictly increasing/ 5.4: What is “connection control” in this context? 6: When the allocations are inserted into the registry, the specification links need to mention the RFC number (RFC XXXX). 7.2: Where QUIC has arrived at rather heavy normative amplification limits (good!), this section is at the level of “might consider”. (Maybe we need to understand potential attacks more before they can be effectively mitigated, but this looks like it is introducing a period of instability.) ## Nits A couple dozen nits are addressed in https://github.com/quicwg/multipath/pull/628 (This includes internally consistent spelling for "acknowledgements", using the spelling from RFC 7322.) 7.3: “This specification changes the AEAD calculation”: I hope not. It changes the calculation of the *input* to the AEAD.
