Hi Gorry, I will check/reply to the rest of the comments later but quickly a clarification on the last one:
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. GF: I think I understand that this is: 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. A receiver will ignore this frame for other IDs [RFC9000]. [MK2] No, if a NEW_CONNECTION_ID frame is received, it is interpreted as a CID for path ID 0. I believe we say this at least once explicitly in the draft. Mirja From: Gorry Fairhurst <go...@erg.abdn.ac.uk> Organisation: UNIVERSITY OF ABERDEEN Date: Tuesday, 18. March 2025 at 11:31 To: Mirja Kuehlewind <mirja.kuehlew...@ericsson.com>, "draft-ietf-quic-multipath.auth...@ietf.org" <draft-ietf-quic-multipath.auth...@ietf.org> Cc: QUIC WG <quic@ietf.org> Subject: Re: A few comments on draft-ietf-quic-multipath-13 On 17/03/2025 14:53, Mirja Kuehlewind wrote: 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. So, that's fine with me!! But there are a bunch of good comment about normative language. See below See GF: below. From: Gorry Fairhurst <go...@erg.abdn.ac.uk><mailto: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"<mailto:draft-ietf-quic-multipath.auth...@ietf.org> <draft-ietf-quic-multipath.auth...@ietf.org><mailto:draft-ietf-quic-multipath.auth...@ietf.org> Cc: Gorry Fairhurst <go...@erg.abdn.ac.uk><mailto:go...@erg.abdn.ac.uk>, QUIC WG <quic@ietf.org><mailto:quic@ietf.org> Subject: A few comments on draft-ietf-quic-multipath-13 Resent from: <alias-boun...@ietf.org><mailto:alias-boun...@ietf.org> Resent to: <olivier.bonavent...@uclouvain.be><mailto:olivier.bonavent...@uclouvain.be>, <huit...@huitema.net><mailto:huit...@huitema.net>, <miaoji....@alibaba-inc.com><mailto:miaoji....@alibaba-inc.com>, <mirja.kuehlew...@ericsson.com><mailto:mirja.kuehlew...@ericsson.com>, <quentin.deconi...@umons.ac.be><mailto:quentin.deconi...@umons.ac.be>, <yunfei...@uber.com><mailto: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 GF: Thanks, this would work. 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. GF: Would it be easier if there was a marker for the IANA in the text so it clear what need to do? 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. GF: OK 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 decide 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. GF: I'm OK with the longer explantion you give, but this is really hard to parse in the I-D. The sentence is very long, and I now recognise the importance of the decision to use a path and then the need to validate before using this. I do think that needs to be clearer. 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. GF: OK 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. GF: I think the "but" confused me, and also the comintaion two sentences - did I understand this finally as something like: The receiver can receive a connection ID associated with a used Path ID on a different 4-tuple (e.g., due to NAT rebinding). This causes the receiver to initiate path validation (specified in Section 9.3 of [QUIC-TRANSPORT] which MUST use a new connection ID for the same Path ID ). 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 GF: Thanks 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"” GF: OK, I don't see a particular advantage in readability from switching between the two forms - so I'd personally prefer to discuss protocol operation using one term, ( I do agree they have the same result ). 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. GF: Understood this as it "MAY" close, I just wanted to be sure I had read this correctly. 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. GF: I see, I didn't associate the text for the various parts of the receiver algorithm. The text seems OK. 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. GF: Perhaps say "open path" ? - and if possible say "for rubustness" or something else to explain why this is so? 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. GF: I was curIous only on the SHOULD NOT... 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. GF: Please ignore. Section 6.3 NiT: /This lower/This is lower/ [MK] Fixed as part 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? GF: I was digging on this because I was uncomfortable, but then I realised I didn't really understand the discomfort. RFC9000 defines "min_rtt as the sender's estimate of the minimum RTT observed for a given network path over a period of time." Shouldn't therefore min RTT be per path? 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 the 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. [GF] So be it. 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. GF: I think I understand that this is: 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. A receiver will ignore this frame for other IDs [RFC9000]. Best wishes, Gorry Thanks, Gorry
