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 <[email protected]>
*Organisation: *UNIVERSITY OF ABERDEEN
*Date: *Thursday, 13. March 2025 at 13:26
*To: *"[email protected]"
<[email protected]>
*Cc: *Gorry Fairhurst <[email protected]>, QUIC WG <[email protected]>
*Subject: *A few comments on draft-ietf-quic-multipath-13
*Resent from: *<[email protected]>
*Resent to: *<[email protected]>,
<[email protected]>, <[email protected]>,
<[email protected]>, <[email protected]>,
<[email protected]>
*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
