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.
Section 1.1
Each bullet deserves a fullstop - please add some stops.
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?
Section 2
The section uses the words the “current version” … . What is the
intention when published?
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 .
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.
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?
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?
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”?
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.
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?
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.
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?
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.
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.
Section 6
- I liked the implementation considerations a lot. I think (?) this is
informative, can we say so at the start of section 6?
Section 6.2
NiT: /also send/also sends/
Section 6.3
NiT: /This lower/This is lower/
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.
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.
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?
Best wishes,
Gorry
