Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

A more complete connection migration #1012

Closed
wants to merge 36 commits into from
Closed

A more complete connection migration #1012

Changes from 1 commit
Commits
Show all changes
36 commits
Select commit Hold shift + click to select a range
3b5d429
Initial text for new frame types
ekinnear Dec 4, 2017
24bcd24
Replace ping/pong frame
ekinnear Dec 5, 2017
84266ae
Text for probing and connection migration
ekinnear Dec 5, 2017
ebcf6d5
Text cleanup
tfpauly Dec 5, 2017
9eeabbc
Remove PATH_PROBE frame, cleanup text
tfpauly Dec 5, 2017
95d7f86
Add change log
ekinnear Dec 5, 2017
6b6d18c
Clean up
ekinnear Dec 5, 2017
040ae7b
Additional cleanup
ekinnear Dec 5, 2017
c2f0bde
initial changes
Dec 6, 2017
e8409fc
initial overview and some nits
Dec 6, 2017
1f439d0
wrapped up path probing section
Dec 7, 2017
5320b27
section on committing
Dec 7, 2017
516f010
committing before I start pruning
Dec 8, 2017
da2b65e
first complete pass
Dec 8, 2017
88c4427
change abandon behavior
Dec 8, 2017
54283b8
more structure and some more text
Dec 9, 2017
3a53131
editorial changes and added section on loss detection
Dec 11, 2017
c18d79c
added PING frame back in
Dec 11, 2017
b98920a
ekinnear's comments and some wordsmithing
Dec 12, 2017
160f2a0
Merge pull request #1 from erickinnear/jri-mods
Dec 12, 2017
3e8b841
remove unnecessary normative
Dec 12, 2017
0e366ef
Merge remote-tracking branch 'origin/master' into dev/migration
ekinnear Dec 12, 2017
86fd34f
Merge branch 'master' into dev/migration
ekinnear Feb 6, 2018
d7c9445
sync
Feb 9, 2018
138ed42
first cut at rewrite
Feb 9, 2018
e46264c
sync
Feb 10, 2018
8ebb6ae
complete rewrite
Feb 12, 2018
440db50
nits
Feb 12, 2018
5760cbe
comments
Feb 20, 2018
0706fd9
comments
Mar 7, 2018
b75ea84
sigh. whitespace.
Mar 7, 2018
5378c03
Mike's comments
Mar 7, 2018
30025de
client connection migration
Mar 7, 2018
b956ba8
eric's comments
Mar 8, 2018
be2afd3
comments
Mar 9, 2018
441d6e9
martin comments
Mar 14, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
164 changes: 97 additions & 67 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -233,7 +233,7 @@ retransmissions from those for original transmissions, avoiding TCP's
retransmission ambiguity problem. QUIC acknowledgments also explicitly encode
the delay between the receipt of a packet and its acknowledgment being sent, and
together with the monotonically-increasing packet numbers, this allows for
precise network roundtrip-time (RTT) calculation. QUIC's ACK frames support
precise network round-trip time (RTT) calculation. QUIC's ACK frames support
multiple ACK blocks, so QUIC is more resilient to reordering than TCP with SACK
support, as well as able to keep more bytes on the wire when there is reordering
or loss.
Expand Down Expand Up @@ -1493,18 +1493,53 @@ MAY discard these packets.

### Path Validation {#migrate-validate}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that you should promote this section one level and put it before connection migration generally.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done. I've redone the front matter in this section to flow better as a standalone.


Path validation is used by a server to confirm the client's ownership of a
new address and by a client to establish reachability to the server from a new
local address.
Path validation is used by the migrating endpoint to verify reachability of
its peer from a new local address. Path validation is also used by the peer to
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit:s/its/the or a

verify that the migrating endpoint is able to receive packets sent to that
address. That is, that the packets received from the migrating endpoint do
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"sent to the migrated address" perhaps? The "that" is a bit hard to follow.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

replaced with "sent to its new address". I'm not sure if "its" is confusing; let me know if it is.

not carry a spoofed source address.

To start path validation, an endpoint sends a PATH_CHALLENGE frame containing
Path validation MAY be used at any time by either endpoint. For instance, an
endpoint might check that a peer is still in possession of its address after a
period of quiescence.

An endpoint MAY bundle PATH_CHALLENGE and PATH_RESPONSE frames with other
frames, as appropriate. For instance, an endpoint may pad a packet carrying a
PATH_CHALLENGE for PMTU discovery, or an endpoint may bundle a PATH_RESPONSE
with its own PATH_CHALLENGE.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add a paragraph disclaiming any suitability for UDP NAT traversal. Though these mechanisms might be effective for the creation of NAT bindings that support NAT traversal, the expectation is that one or other peer (typically the server) is able to receive packets without first having sent a packet on that path. Effective NAT traversal needs additional synchronization mechanisms that are not provided here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added, PTAL.


#### Initiation

To initiate path validation, an endpoint sends a PATH_CHALLENGE frame containing
a payload that is hard to guess on the path to be validated.

On receiving a PATH_CHALLENGE frame, the peer MUST immediately respond by
echoing the data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame.
The PATH_RESPONSE MUST be sent on the same path: from the same local address on
which the PATH_CHALLENGE was received, to the same remote address from which the
PATH_CHALLENGE was received.
An endpoint MAY send additional PATH_CHALLENGE frames to handle packet loss,
but is subject to the following limit to avoid excessive network load: an
endpoint SHOULD NOT send a PATH_CHALLENGE more frequently than it would a client
INITIAL, ensuring that connection migration is no more load on a new path than
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Packet names are title-cased, not all-caps. Also, I'd drop the colon lead-up.

...but to avoid excessive network load, an endpoint SHOULD NOT... an Initial packet. This ensures that....

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

establishing a new connection.

The endpoint MUST use fresh random data in every PATH_CHALLENGE frame so that it
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here we indicate that this should be random data, but above we just said "hard to guess" -- I know we took out the note about what's considered hard to guess, but perhaps we should still include a note in the above paragraph that it's random?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added "random" to the sentence above

can associate the peer's response with the causative PATH_CHALLENGE.


#### Response

On receiving a PATH_CHALLENGE frame, an endpoint MUST respond immediately by
echoing the data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame,
with the following stipulation. Since a PATH_CHALLENGE may be sent from a
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"might be" - there's no permission involved here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, right. I'm always confused between may and might. This is a good way to think about it. Done.

spoofed address, an endpoint MAY limit the rate at which it sends PATH_RESPONSE
frames and MAY silently discard PATH_CHALLENGE frames that would cause it to
respond at a higher rate.

Path validation tests both directions of a path. To ensure reachability in both
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Path validation tests that packets can be both sent to and received from a peer."

The implication I got from reading this text was that a single validation process (CHALLENGE/RESPONSE) was sufficient for both peers to be satisfied that the path is good. That's not the case: both endpoints need to do their own challenge.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done.

directions, the PATH_RESPONSE MUST be sent on the same path as the triggering
PATH_CHALLENGE: from the same local address on which the PATH_CHALLENGE was
received, to the same remote address from which the PATH_CHALLENGE was received.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and port, I presume?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

an address is defined above as IP and/or port



#### Completion

The new address is not considered valid until a PATH_RESPONSE frame containing
the same payload is received, even if the packet containing the PATH_CHALLENGE
Expand All @@ -1520,55 +1555,45 @@ The PATH_RESPONSE frame MUST be received on the same local address from which
the corresponding PATH_CHALLENGE was sent. If a PATH_RESPONSE frame is received
on a different local address than the one from which the PATH_CHALLENGE was
sent, path validation is considered to have failed, even if the data matches
that sent in the PATH_CHALLENGE.

Thus, the endpoint considers the path to be valid when a PATH_RESPONSE frame is
received on the same path with the same payload as the PATH_CHALLENGE frame.
that sent in the PATH_CHALLENGE. Thus, the endpoint considers the path to be
valid when a PATH_RESPONSE frame is received on the same path with the same
payload as the PATH_CHALLENGE frame.

The endpoint MAY send additional PATH_CHALLENGE frames to handle packet loss,
but is subject to the following limit to avoid excessive network load: an
endpoint SHOULD NOT send more than one PATH_CHALLENGE frame in 200ms. This
limit is approximately equivalent to the network load due to a new connection,
and is based on the initial Handshake Timeout defined in {{QUIC-RECOVERY}}.

The endpoint MUST use fresh random data in every PATH_CHALLENGE frame so that it
can associate the peer's response with the causative PATH_CHALLENGE.
#### Abandonment

The endpoint SHOULD abandon path validation after sending some number of
PATH_CHALLENGE frames or after some time has passed. When setting this timer,
implementations are cautioned that the new path could have a longer roundtrip
time than the original. The endpoint may receive packets containing other frames
during this period, but a PATH_RESPONSE frame with appropriate data is required
for the path validation to succeed.
implementations are cautioned that the new path could have a longer round-trip
time than the original. Again, to avoid excessive network load, an endpoint
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: "Again," is unnecessary.

SHOULD NOT send more PATH_CHALLENGE frames than it would a client INITIAL,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same issue with "Initial" as at ~1519. BTW, double check that you actually need near-identical text both places?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point -- I don't think I need it here. The earlier text is adequate. Removed.

ensuring that connection migration is no more load on a new path than
establishing a new connection.

Path validation using the PATH_CHALLENGE frame MAY be used at any time by
either endpoint. For instance, an endpoint might check that a peer is still in
possession of its address after a period of quiescence.

An endpoint MAY bundle PATH_CHALLENGE and PATH_RESPONSE frames with other
frames, as appropriate. For instance, an endpoint may pad a packet carrying a
PATH_CHALLENGE for PMTU discovery, or an endpoint may bundle a PATH_RESPONSE
with its own PATH_CHALLENGE.
The endpoint may receive packets containing other frames during this period, but
a PATH_RESPONSE frame with appropriate data is required for the path validation
to succeed.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this mean packets on the new path or on the old path? What are we trying to indicate here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant to say other packets might be received on the new path, but they are not adequate for validation. Fixed up sentence.



### Initiating Connection Migration {#initiating-migration}

A client MAY initiate connection migration to a new local address in one of two
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This "MAY" seems superfluous, particularly since the first way also has a MAY. I'd either lower-case it, "can", or "A client initiates...." Also, I don't know that I'd frame these as two "ways" of migrating. Ultimately, the client migrates by sending data from the new address/port. A client MAY probe for reachability first, if it has the opportunity.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good suggestions. I've made restructured a bit so that it flows as you suggest instead of "two ways".

ways.

The client may immediately migrate the connection by sending all packets from
the new local address. Receiving acknowledgments for this data serves as proof
of the server's reachability from the new address. Note that since
The client MAY immediately migrate the connection by sending all packets from
the new local address. Since the server's address is validated during
connection establishment, receiving acknowledgments for this data serves as
proof of the server's reachability from the new address. Note that since
acknowledgments may be received on any path, return reachability on the new path
is not established. To establish return reachability on the new path, a client
MAY concurrently initiate path validation {{migrate-validate}} on the new path.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This paragraph has too many ideas for me. Here's a breakdown:

You want to say that a client can initiate migration to a new address at any time. You also should point out that the basic functions are potentially usable for server migration, but that is not supported due to not having a means of avoid glare.

The point about paths being validated (for both server and client) belongs elsewhere, likely in the introduction of the validation section.

Same again for the point about acknowledgments. Receiving data (including acknowledgments) does not provide proof of return routeability (too low entropy).

So that leaves one idea in the first paragraph: who can do it, and what it is for.

Move the bit about concurrent path validation to a new paragraph.

Overall, I think that needs to be crisper than this and structuring this differently might help.

Give the migrating endpoint three sections:

  • Speculative probing. Why you might do it, and how you do it. Maybe also what the reaction should be, so that this is self-contained.

  • The voluntary migration an endpoint makes when it is aware of what it is doing. This happens when an endpoint is aware that it is using a new address. In this case, we should mandate path validation and a new congestion state (absent some heuristics about continuity). Path validation might be concurrent with the change, particularly if the old path is gone, so this might appear to be involuntary at the server, but this is logically distinct.

  • The involuntary migration (NAT rebinding) needs a section of its own too.

The peer of the migrating endpoint reacts differently, because the concurrent validation looks like involuntary migration to it. Note - as you do - that it can tell between a speculative probe and actual migration by the presence of frames other than PATH_CHALLENGE in packets on the new path. Then say that speculative probes don't trigger migration. After that, the only thing you need to say is that send rate is limited until the path challenge is successful, and the congestion state is reset (absent continuity heuristics again - repetition of this theme suggests a section that you can point to and include some of the nuance) after it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's chat about this tomorrow.


Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is PATH_RESPONSE more strict than ACK's from just sending data wrt. local and remote addresses?

Should there be a rate limit on how often a migration can take place? It might stress the peer, and gaps in packet numbers can be a DoS on the peers implementation (I know gaps are up for discussion, but if/when there are gaps...)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PATH_CHALLENGE/PATH_RESPONSE is used for reachability tests, to ensure that the reverse path works fine, before migrating data. Sending Data is a bit more aggressive, where the sender is "committing" to the new path without testing it. That said, you raise a good point. I've changed some text here.

Alternatively, the client may probe for server reachability from the new local
Alternatively, the client could probe for server reachability from the new local
address first using path validation {{migrate-validate}} and migrate the
connection to the new address at a later time. Failure of path validation
simply means that the new local address is not usable for this connection and
should not be fatal to the connection when alternative local addresses are
available.
connection to the new address later. Failure of path validation simply means
that the new local address is not usable for this connection. Failure to
validate a path does not cause the connection to end unless there are no valid
alternative paths available.

A client migrating to a new local address SHOULD use a new connection ID for
packets sent from that address, see {{migration-linkability}} for further
Expand All @@ -1581,8 +1606,8 @@ finished and the client has 1-RTT keys.
### Responding to Connection Migration

A server may receive a packet from a new client address at any time during the
connection after the handshake is complete. If the packet is decryptable, the
client may be either probing from a new address or migrating immediately, as
connection after the handshake is complete. If the packet is authenticated, the
client might be either probing from a new address or migrating immediately, as
described in {{initiating-migration}}.

#### Responding to a Client Probe
Expand Down Expand Up @@ -1617,21 +1642,23 @@ In response to such a packet, the server MUST start sending subsequent packets
to this client address and MUST initiate path validation to verify client
ownership of the unvalidated address.

A server MAY skip validation of a client address that it considers to be already
valid.
A server MAY skip validation of a client address if it has been seen recently or
if the server has reasonable certainty that the new address is the result of a
NAT rebinding.

Note that the server MAY send data to an unvalidated client address, but it MUST
protect against potential attacks as described in {{address-spoofing}} and
{{on-path-spoofing}}.

If a non-probing packet is received from a new client address but with a packet
number that is not the largest seen thus far, the server must process the packet
as usual, but it MUST ignore this client address under the assumption that it is
not the client's most recent address.
number that is not the largest seen thus far, it is likely that it is a
reordered packet sent from an older client address. The server processes this
packet as usual, but it MUST ignore this client address under the assumption
that it is not the client's most recent address.

After verifying a new client address, the server SHOULD update any address
validation tokens ({{address-validation}}) that it has issued to the client if
those are no longer valid based on the changed address.
After verifying a new client address, the server SHOULD send new address
validation tokens ({{address-validation}}) to the client if the current ones
will not be adequate to validate the new client address.


### Handling Address Spoofing by a Client {#address-spoofing}
Expand All @@ -1647,10 +1674,13 @@ server MUST immediately validate the client's new address to confirm the
client's possession of the new address.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I worry that people may be confused by the perceived conflict between this and:

A server MAY skip validation of a client address if it has been seen recently or
if the server has reasonable certainty that the new address is the result of a
NAT rebinding.

Can we resolve that somehow?

Perhaps we could say above:

A server MAY consider validation to be complete for a client address that has been 
seen recently or if the server has reasonable certainty that the new address is the 
result of a NAT rebinding.

Or something to that effect (maybe A server MAY deem a client address to be valid to echo the next paragraph here).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I've rephrased some things here and added an explicit sentence calling out that a server SHOULD NOT apply this limit when it is not validating the client address.


Until a client's address is deemed valid, the server MUST limit the rate at
which it sends data to this address. The server MUST NOT send more than 4 * MSS
bytes per estimated initial RTO period (as defined in {{QUIC-RECOVERY}}). In
the absence of this limit, the server risks being used for a denial of service
attack against an unsuspecting victim.
which it sends data to this address. The server MUST NOT send more than a
minimum congestion window's worth of data per estimated RTO period (as defined
in {{QUIC-RECOVERY}}). In the absence of this limit, the server risks being
used for a denial of service attack against an unsuspecting victim. Note that
since the server will not have any round-trip time estimates to the new address,
the RTO period is likely to be estimated based on the default initial RTT (see
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"SHOULD be" not "likely to be"

I think that this text belongs in the section that deals with handling of migrations by the non-migrating peer.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done. I've simply moved this and the section below into the section above (Responding to Connection Migration).

{{QUIC-RECOVERY}}).


### Handling Address Spoofing by an On-path Attacker {#on-path-spoofing}
Expand All @@ -1669,21 +1699,21 @@ a new client address fails. If the server has no state about the last validated
client address, it MUST close the connection silently and discard any further
packets received from the client for this connection.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does this tie in to the closure/draining states described elsewhere? Does the server enter draining? Can it send Stateless Reset?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good q. I've changed it so that the server basically discards all connection state, leaving subsequent packets to be treated generically. That is, the server could send Stateless Resets in response. I think this is reasonable.


We note that receipt of packets with higher packet numbers from the legitimate
client address will trigger another connection migration. This will cause the
validation of the address of the spurious migration to be abandoned.
Receipt of packets with higher packet numbers from the legitimate client address
will trigger another connection migration. This will cause the validation of
the address of the spurious migration to be abandoned.


### Loss Detection and Congestion Control
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This section is good. I worry a little that the pattern of acknowledgments triggered by this will leak information about what is going on, but I don't have a good solution for that here.


The capacity available on the new path might not be the same as the old path.
Packets sent on the old path SHOULD NOT contribute to the state of the
congestion control and RTT estimation on the new path. If it is using a single
congestion controller and roundtrip time estimator, the client SHOULD reset them
prior to sending any non-probing packets from a new local address.
congestion controller and round-trip time estimator, the client SHOULD reset
them prior to sending any non-probing packets from a new local address.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed earlier, I think it would make sense to add a text like:
"Only packets sent on the new path contribute to the state of the congestion control and RTT estimation on that path."

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I like Marcus suggestion here. The text seems to presuppose an implementation approach(a single congestion controller that's reset), opposed to specifying the correct behavior.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And the same below for servers, as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Modified this text.

After successful validation of the client's new address, the server SHOULD reset
its congestion controller and roundtrip time estimator prior to sending any
its congestion controller and round-trip time estimator prior to sending any
further non-probing packets.

An endpoint MUST NOT restore its send rate unless it is reasonably sure that the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: restore -> return to ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed up sentence too

Expand All @@ -1696,7 +1726,7 @@ signals and reducing send rates appropriately.

There may be apparent reordering at the receiver when an endpoint sends data and
probes from/to multiple addresses during the migration period, since the two
resulting paths may have different rountrip times. A receiver of packets on
resulting paths may have different round-trip times. A receiver of packets on
multiple paths will still send ACK frames covering all received packets.

An endpoint MAY use a single congestion control context and a single loss
Expand Down Expand Up @@ -1829,9 +1859,9 @@ state to draining, but it otherwise has no impact.
An endpoint could receive packets from a new source address, indicating a
connection migration ({{migration}}), while in the closing period. An endpoint
in the closing state MUST strictly limit the number of packets it sends to this
new address since the address is not validated (see {{migrate-validate}}). A
server in the closing state MAY instead choose to discard packets received from
a new source address.
new address until the address is validated (see {{migrate-validate}}). A server
in the closing state MAY instead choose to discard packets received from a new
source address.


### Idle Timeout
Expand Down Expand Up @@ -3553,7 +3583,7 @@ tradeoff between resource commitment and overhead when determining how large a
limit is advertised.

A receiver MAY use an autotuning mechanism to tune the frequency and amount that
it increases data limits based on a roundtrip time estimate and the rate at
it increases data limits based on a round-trip time estimate and the rate at
which the receiving application consumes data, similar to common TCP
implementations.

Expand Down Expand Up @@ -3599,7 +3629,7 @@ entire round trip.
For smooth operation of the congestion controller, it is generally considered
best to not let the sender go into quiescence if avoidable. To avoid blocking a
sender, and to reasonably account for the possibiity of loss, a receiver should
send a MAX_DATA or MAX_STREAM_DATA frame at least two roundtrips before it
send a MAX_DATA or MAX_STREAM_DATA frame at least two round trips before it
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Should it be round-trips as it is elsewhere?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's "round-trip time" or "round trip" elsewhere (I think, I'll make it consistent separately)

expects the sender to get blocked.

A sender sends a single BLOCKED or STREAM_BLOCKED frame only once when it
Expand Down