[quicwg/base-drafts] Section 9.4 of Transport contains transport and congestion control functions (#2654)

[Gorry Fairhurst <[e-mail]>]

To me, section 9.4 contains a mixture of transport and congestion control functions (choice of path parameters - RTO, window, etc). The abstract suggests that these are a part of a different I-D. I also have comments on the intention for dealing with path changes:
---
Section 9.4:
NiT: “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.”
- To be clear, does this reset require setting the CC to the initial value for a connection? I think so.
—
CC:   “An endpoint MUST NOT return to the send rate used for the previous
   path unless it is reasonably sure that the previous send rate is
   valid for the new path. “
- This is a congestion control semantic. (I’m surprised this is a part of QUIC transport, rather than the CC & recovery draft). I think the normal transport assumption is that a change of path implies a loss of congestion state and other path CC parameters. This is therefore a “significant” departure from conventional approaches considered safe - extending this to “reasonably sure”. How do people quantify reasonably sure, where is the information to say that the connection should not use the Initial window?
---
CC: “if the new path capacity is significantly reduced, ultimately this relies on the congestion controller responding to congestion signals and reduce send rates appropriately.” 
-  I’d suggest this could be a significant change too what has been practice with TCP CC? And it would often not be a huge performance implication to initialise IW and build from there.
---
CC:   “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. “
- I think the transport I-D should not make these claims, because this also seems like a CC decision. I actually do not understand this specific claim, as currently presented.
---


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