Re: [quicwg/base-drafts] Path Migration makes unjustified assumptions about a new path. (#2909)

[Eric Kinnear <[e-mail]>]

We've summarized some discussion for these above, but to go through the resolution plan for concrete changes for each one:

----

> Section 9.4 of draft-ietf-quic-transport :
> 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
> congestion control or RTT estimation for the new path.
> GF: That would be fine IF the new path were a separate CC context, which I am not yet clear whether it is, read on:

The intent here was that either (a) you only ever have a singe CC context and you reset it for each path, or (b) you have a CC context for each path, in which case each context is strongly tied to a path and you don't need to reset anything. We require that everyone does at least (a), while not preventing folks who want to do extra work for a potential performance gain from doing (b).

Addressing this in a PR:
```
Packets sent on the old path MUST NOT contribute to congestion control or 
RTT estimation for the new path.
```
They *can* contribute to the CC/RTT estimation for the old path if it's still around and you're willing to maintain that state, which is why this (mistakenly) was a SHOULD.

----
> —
> Section 9.4 of draft-ietf-quic-transport :
> On confirming a peer's ownership of its new address, an endpoint
> SHOULD immediately reset the congestion controller and round-trip
> time estimator for the new path.
> GF: Why not MUST? - because I think this is a new path, I think it can only be should if something > can confirm this is the same set of network-devices and classifiers on the path. I don't know how > you would know that, and I don't like the guess.
> —

Yes, this should be a MUST, because the CC/RTT for that path has to be reset for a new address, either by making a new one for the new path and keeping the old one around for the old path, or by resetting your single one.

This is now a MUST in the current editor's copy.

----
> draft-ietf-quic-transport :
> For instance, a change in the client's port
> number is likely indicative of a rebinding in a middlebox and not a
> complete change in path.
> GF: So. maybe this is the guess, and I don't believe it! In a world of ECMP and other methods, this > needs to be treated as a potential change of path.
> —

A very good point! This is now:
```
For instance, an endpoint might infer that a change in
only the client's port number is indicative of a NAT rebinding, meaning that the
new path is likely to have similar bandwidth and round-trip time. However, this
determination will be imperfect.  If the determination is incorrect, the
congestion controller and the RTT estimator are expected to adapt to the new
path.  Generally, implementations are advised to be cautious when using previous
values on a new path.
```

This seems to address the need for caution here.

----
> Section 9.4 of draft-ietf-quic-transport:
> While multiple paths might be used during connection migration, a
> single congestion control context and a single loss recovery context
> (as described in [QUIC-RECOVERY]) may be adequate.
> GF: Well it could if the paths WERE known to be identical, but how would an endpoint guarantee that? Section 9.2 of QUIC transport seems to suggest the CC is reset for the new path, which I would agree with, but which part of QUIC recovery says that?
> —

This is intended to say that you aren't required to maintain additional per-path state, it's adequate to reset it for each path.

In recovery, the section entitled "Handshakes and New Paths" discusses initial values to use on a new path. In general, recovery seems to be an instance of CC/LR, so if transport instructed you to toss out the old one and make a new one, you'd be using initial values, etc. as specified in recovery.

Transport does *require* that you reset CC/RTT a few paragraphs above (as noted in your previous comment):
```
On confirming a peer's ownership of its new address, an endpoint MUST
immediately reset the congestion controller and round-trip time estimator for
the new path to initial values (see Sections A.3 and B.3 in {{QUIC-RECOVERY}})
unless it has knowledge that a previous send rate or round-trip time estimate is
valid for the new path.
```

----
> draft-ietf-quic-recovery:
> For instance, an
> endpoint might delay switching to a new congestion control context
> until it is confirmed that an old path is no longer needed (such as
> the case in Section 9.3.3).
> GF: This seems underspecified and novel to me. I think it may b quite OK to continue using the old path and the old CC, for a while. Same question: is this implying the two paths share a single CC > and is there some real mechanism to detect that they are really the same set of network devices on path?

I don't think we're trying to specify a new mechanism to determine equality of paths across a network. The intent here is to recommend that an endpoint be a little bit cautious about throwing out its state before it knows it's really going to be sticking with the new path.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2909#issuecomment-545655532