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

[Gorry Fairhurst <[e-mail]>]

This is awkward, because the issue of assumptions about the path appears spread over multiple places.

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:
—
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.
—
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.
—
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?
—
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?


-- 
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