Thanks Gorry! Very helpful! However, note that we are currently working on a mayor editorial pass which you can see on github. Therefore some of the things below are already gone. But there are a bunch of good comment about normative language. See below
From: Gorry Fairhurst <go...@erg.abdn.ac.uk> Organisation: UNIVERSITY OF ABERDEEN Date: Thursday, 13. March 2025 at 13:26 To: "draft-ietf-quic-multipath.auth...@ietf.org" <draft-ietf-quic-multipath.auth...@ietf.org> Cc: Gorry Fairhurst <go...@erg.abdn.ac.uk>, QUIC WG <quic@ietf.org> Subject: A few comments on draft-ietf-quic-multipath-13 Resent from: <alias-boun...@ietf.org> Resent to: <olivier.bonavent...@uclouvain.be>, <huit...@huitema.net>, <miaoji....@alibaba-inc.com>, <mirja.kuehlew...@ericsson.com>, <quentin.deconi...@umons.ac.be>, <yunfei...@uber.com> Resent date: Thursday, 13. March 2025 at 13:26 Thank you for writing this detailed I-D, it is a while since I have reviewed this draft. I read it on my journey towards Bangkok and the current I-D appears to me to be very developed and clear, but I do have a few comments and just a few concerns about things that I think might be underspecified, see below. Section 1 Editorial: /also the port numbers/ … and other selectors such as the DSCP. [MK] This sentence is gone. Section 1.1 Each bullet deserves a fullstop - please add some stops. Proposal is to remove this section (see PR #504 https://github.com/quicwg/multipath/pull/504) Section 1.2 Path identifier and “Path ID” are both used after the definition of Path ID.Could we move to use only Path ID? [MK] I tried to use Path identifier as the term and Path ID as the field, but I also had this on my list to double-check and maybe only use Path ID. I will check and opened an editorial issue: https://github.com/quicwg/multipath/issues/510 Section 2 The section uses the words the “current version” … . What is the intention when published? [MK] This should be replaced by the RFC editor with the IANA signed number. Section 3. OLD: However, establishment of additional paths from any local address to other peer addresses (e.g carried by peer’s preferred_address) is valid immediately. - This reads odd, could we write something like: However, establishment of additional paths from any local address to other peer addresses (e.g carried by a peer’s preferred_address) is immediately valid . [MK] I already changed this sentence in my edit pass (see PR #506 https://github.com/quicwg/multipath/pull/506) remove the “any local address” as that is not needed. You only changed the “immediately valid”, right? I think we already fixed that somehow. OLD: After receiving packets from the client on a new path, if the server decides to use the new path, the server MUST validate the peer's address before sending any data packets as described in (Section 8.2 of [QUIC-TRANSPORT]), unless it has previously validated the 4-tuple used for that path. - I found this confusing, is this better? : After receiving packets from the client on a new path, a server can decides to use the new path. The server MUST validate the peer's address before sending any data packets as described in (Section 8.2 of [QUIC-TRANSPORT]), unless it has previously validated the 4-tuple that is used for that path. [MK] I wouldn’t want to split this up into two sentences because the point is only if you plan to actually use the path meaning actually sending packets yourself, you have to validate. That’s what we discussed extensively in some meeting and this is the wording we had at the end, so I’s rather keep it as it. OLD: Similarly after a successful handshake, endpoints SHOULD also use the PATH_NEW_CONNECTION_ID frame to provide new connection IDs for Path ID 0 and, respectively, the PATH_RETIRE_CONNECTION_ID frame to retire connection IDs for Path ID 0. - what happens if this SHOULD is not obeyed? [MK] Nothing. This is just a recommendation. We also discussed this extensively and we could agree to MUST, so we keep this as a (normative) preference. OLD: In such a case, the receiver reacts as specified in Section 9.3 of [QUIC-TRANSPORT] by initiating path validation but MUST use a new connection ID for the same Path ID. - What does a receiver do if this MUST is not obeyed? [MK] In you don’t use the same Path ID it’s not migration; it is opening a new path. If the server would try to open a new path, that’s actually not allowed, but that’s already part of RFC9000. OLD: To avoid issues when clients make the "wrong" choice, a server should issue a token that is capable of validating any of the previously validated addresses. Further guidance on token usage can be found in Section 8.1.3 of [QUIC-TRANSPORT]. - Why is this optional if it could break things: Is this a place where the Spec could say “SHOULD”? [MK] Yes, I think this was an oversight and I fixed this already in PR #507 https://github.com/quicwg/multipath/pull/507/files Concern: OLD: If an endpoint starts using a path that was marked as "standby" by its peer because it has detected issues on the paths marked as "available", it is RECOMMENDED to update its own path state signaling such that the peer avoids using the broken path. - why do you choose recommended rather than SHOULD, these seems like a protocol definition. [MK] My understanding is that these are equivalent and it just a matter of sentence structure. See RFC2119: “SHOULD This word, or the adjective "RECOMMENDED"” OLD: An endpoint that detects a path breakage can also explicitly close the path by sending a PATH_ABANDON frame (see Section 3.3) in order to - “can also” is this really MAY? [MK] This is not a recommendation or instruction, but a statement. When and how to decide to close a path is really a local decision and the protocol in this spec actually intends to not give any guidance about this part of muitpath usage. Section 3.3 - can we be more explicit about what the receiver does (discard, process, etc) if the peer does receive packets after a path close. [MK] I thought this is actually discussed in section 3.3.1 (Avoiding Spurious Stateless Resets). However, it’s the same that happens in RFC900 if you receive a packet with an unknow CID. Concern: OLD: PATH_ABANDON frames can be sent on any path, not only the path that is intended to be closed. It is RECOMMENDED to send the PATH_ABANDON frames on another path, especially if connectivity on the to-be- abandoned path is expected to be broken. - I thought and think I am unsure about what is intended. How does this relate to an active and inactive paths? I do wonder if some sort of guidance on how to do this is needed? [MK] If you close a path (and not the whole connection), you need at least one more open path. However, we don’t give any guidance on which of these open paths to send the path_abandon. Why should we? Note that an active path (ID) is any path that is smaller than the max path ID. However, if we actually use the path by sending packets, we made sure we used the word “open” in the draft. OLD: Over a given path, both endpoints use connection IDs associated to a given Path ID. To initiate a path, each endpoint needs to advertise at least one connection ID for a given Path ID to its peer. Endpoints SHOULD NOT introduce discontinuity in the issuing of Path IDs through their connection ID advertisements as path initiation requires available connection IDs for the same Path ID on both sides. - I think I understand, but I would like text to be sure. - I can see about conservative of IDs, but is there more than simply not wasting the space? - I’m trying to understand what breaks if the SHOULD NOT is not obeyed. [MK] I also noted that with the recommendation above to send CIDs for all active Path ID. This advise is actually less needed, however, it might be still good to have it. This is to avoid the case where e.g. may path ID is 3 and e.g. only path 0 is open but one peer send only CIDs for path 1 and the other only for path 2. In this case each peer has issued one unused CID but because you need to use the same path ID to open a new path, you can’t open a new path. So to answer you question in short: you risk that you can’t open a new path, however, it does break the protocol. Section 5 - I liked the examples. I think these examples are informative, if they are cam we say so at the start of section 5, so there is no chance of a double definition from this section. - Would it make sense to provide the examples after all the definitions? It certainly would have made reading easier for me. [MK] Yes I’m moved them already in latest version on github. Section 6 - I liked the implementation considerations a lot. I think (?) this is informative, can we say so at the start of section 6? [MK] Yes we can say that explicitly. Section 6.2 NiT: /also send/also sends/ [MK] I don’t find this. Can you give me the whole sentence. Section 6.3 NiT: /This lower/This is lower/ [MK] Fixed a spart of #509 https://github.com/quicwg/multipath/pull/509/files Concern: OLD: It might be prudent for nodes to remember the path over which the PATH_ACK that produced the minimum RTT was received, and to restart the minimum RTT computation if that path is abandoned. - I am glad this is noted. - Some might say that was an oversight in QUIC, that the minRTT is not current for a path, i.e. if the path properties change with time, the minRTT is never increased- however, my comment here is that the QUIC sender could actually just reset the minRTT periodically or better still reset this based on a minimum filter for several periods of time. My point is at least some QUIC implementations do not preserve the minRTT for the whole connection. [MK] I think that is an issue for RFC9000. Or do you think anything is needed here? Concern: OLD: To avoid this pitfall, endpoints could adopt a simple coordination rule, such as only letting the client initiate closure of duplicate paths, or perhaps relying on the application protocol to decide which paths should be closed. - At the end of section 6 I see teh above worrying text. Why does the protocol not provide a recommendation in RFC2119 language that would avoid at least part of the misery from uncoordinated abandons? - I don’t see why this is only written as advice, rather than specified by the WG. [MK] We discussed this in the group and decided that we only want to give no normative guidance and leave it to the implementation or application. Section 7.4: OLD: Note that the NEW_CONNECTION_ID frame can only be used to issue or retire connection IDs for the initial path with Path ID 0. What is the required protocol action if the NEW CONNECTION ID frame is received with path ID 0? [MK] Nothing. RFC9000 still applies. However, for other path ID than 0 you can only use the new frames. Best wishes, Gorry
