Congestion Control must be per-path (following [QUIC-TRANSPORT])？

[nandsky]

As described in Section 1. Introduction:

• Congestion Control must be per-path (following [QUIC-TRANSPORT]) which usually also requires per-path RTT measurements

But what RFC 9000 9.4. Loss Detection and Congestion Control says:

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]) could be adequate. 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 described in Section 9.3.3).

In my option, it is necessary to maintain a CC state machine per path, but rfc 9000 does not require that?

[yfmascgy]

It is often necessary to have separate CCs when you want to use multiple paths for concurrent transmission. If the paths' bottlenecks are not shared, it is very likely that one path is congested while the other is not. In the case of a share bottleneck , coupled CC may be used, but you still need CC state per path. For our experience, coupled CC did not perform well so we generally use non-coupled CC per path.

[mirjak]

RFC9000 allows to not reset the cc on migration if you are rather certain that the path actually didn't change. This is also still allowed in the multipath extension because in this case it's a migration event and not a new path. I don't see a conflict.

[mirjak]

It seems like no action is needed here.