Mohamed Boucadair has entered the following ballot position for draft-ietf-quic-multipath-19: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-quic-multipath/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi Yanmei, Yunfei, Quentin, Olivier, Christian, and Mirja, Thank you for the effort put into this document. Thanks also to Adrian Farrel for the OPSDIR and to Christian for engaging and making changes. I checked both the draft and the discussion about the two related PRs. The document is well-written. I like the design as it builds on existing features in the base spec. Please find below some few discussion points: # What is a path? The document says that paths: “refers to the notion of "network path" used in [QUIC-TRANSPORT].” However, section 5.2 says: It is possible to create paths that refer to the same 4-tuple. For example, endpoints might want to create paths that use different Differentiated Service [RFC2475] markings. ## Are we still compliant with the definition in [QUIC-TRANSPORT]? ## As a side note, there is no explicit definition in [QUIC-TRANSPORT](or I missed it). Maybe better to have an explicit definition. Note that MPTCP (RFC8684) has the following: Path: A sequence of links between a sender and a receiver, defined in this context by a 4-tuple of source and destination address/port pairs. Likewise, RFC9897 has the following: Path: A sequence of links between a sender and a receiver, defined in this context by a 4-tuple of the source and destination address and the source and destination ports. This definition follows [RFC8684] and is illustrated in the following two examples for IPv6 and IPv4, which each show a pair of sender IP-address:port and a pair of receiver IP-address:port, which together form the 4-tuple: # Available server addresses The spec says: If the server uses the preferred_address transport parameter, clients cannot assume that the initial server address and the addresses contained in this parameter can be simultaneously used for multipath (Section 9.6.2 of [QUIC-TRANSPORT]). Use of the preferred address with the same local address is considered as a migration event that does not change the path ID. with only clients can initiate new paths per: Note that in this extension, a QUIC server does not initiate the creation of a path, but it has to validate a new path created by a client. and address handling belongs to applications: Addresses and the actual decision to set up or tear down paths are assumed to be handled by the application. Absent at least an option for the client to learn available addresses for multipathing at the server side, the actual use of the extension may be restricted in some cases (e.g., single-addressed client—multi-addressed servers). Unless I’m missing the point of the last excerpt above, I think this is putting a hurdle on applications as they may not control the addresses, but more importantly may lead to each application building its own way to manage address referrals (if the design of the app can accommodate it at the first place). ## Is there a reason why the spec does not offer a parameter for the server to share addresses available for multipathing? ## Can we please better clarify the assumptions around applications? # More operational considerations CURRENT: The operational considerations for QUIC are addressed in [RFC9312]. They also apply to QUIC connections using the extensions defined in this document. An additional complexity is that applications might use a combination of monitored and non-monitored paths, but that complexity already exists when using path migration as defined in [QUIC-TRANSPORT]. ## There are more operational considerations that I think are important to highlight: * need to control the max num of paths (and avoid overloading servers) * need for implementations to offer configuration knobs to restrict the number of active paths per connection * need to support configurable policy for acceptable traffic distribution * remind that (plugged) traffic scheduler need to avoid aggressive use of some resources (cellular in bonding scenarios) while other paths are available. * remind that use of some available paths depends on the user preference/consent. Some decisions may impact the user experience/subscription given that oddly setting the priority/order of paths may lead to unexpected experience (e.g., which is problematic for cases where there are quota per access). This is even exacerbated given that: CURRENT: Note that an endpoint might not follow the peer's advertisements, but these frames are still a clear signal of the peer's preference of path usage. * need for heuristics to decide when to start using multiple paths (short lived connections, etc.) * guard to prevent too frequent adding new paths # When to ignore the PATH_ACK and PTO Recommendations? CURRENT: After the handshake concluded with support for the multipath extension, endpoints SHOULD use PATH_ACK frames instead of ACK frames, including for so far unacknowledged 0-RTT packets using path ID 0. CURRENT: When this specification is used, endpoints SHOULD wait for at least three times the largest Probe Timeout (PTO) (see Section 6.2 of [QUIC-RECOVERY]) among all the paths before initiating a new key update after receiving an acknowledgment that confirms the receipt of the previous key update. Would it be possible to clarify in the text what are the implications of not following these SHOULDs? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Abstract ## Putting aside that create/delete are covered by “manage”, “managing paths using identifiers” is too vague to be useful in an abstarct CURRENT: It proposes a standard way to create, delete, and manage paths using identifiers. ## nit OLD: It proposes a standard way to create NEW: It defines a standard way to create # What’s in scope, what isn’t? Several aspects of multipathing are declared out of scope. These are include mostly in the introduction. I would suggested to have all such statements groped in a specific Section. # Use Case CURRENT: Specifically, while failover between Wi-Fi and mobile networks is a well-known multipath use case, Maybe cite rfc8041#section-2.2 # Redundant behavior Section 2 (Preamble) Endpoints MUST NOT remember the value of the initial_max_path_id transport parameter for use in a subsequent connection. Section 2.1: The initial_max_path_id parameter MUST NOT be remembered for use in a subsequent connection (Section 7.4.1 of [QUIC-TRANSPORT]). Unless I’m missing something subtle here, I suggest to keep the normative behavior only in one place (2.1, typically). # MAX_PATH_ID CURRENT: MAX_PATH_ID frames that do not increase the path limit MUST be ignored. Isn’t allowed that this frame can be received at any time during the connection? If so, wouldn’t that MUST prevent lowering the limit to accommodate local preferences? Cheers, Med
