I have only skimmed through the draft but I am wary of using cached values for things like `cwnd` for the reasons that the draft talks about in Section 3.2. The draft says the sender should validate path properties to match it with previous connections but that is not an easy thing and doing it with RTT is surely not enough. IMO, it might be better to not use dst cache at all due to the dynamic nature of networks and maybe work on a way to make slow start a little bit faster than doubling the cwnd.
Vidhi > On Jul 12, 2022, at 4:04 PM, Rui Cunha Paulo > <[email protected]> wrote: > > On Jul 11, 2022, at 19:07, Martin Thomson <[email protected]> wrote: >> >> More seriously, this isn't the right group to be standardizing this sort of >> thing. Maybe this new congestion control working group might, but this >> isn't specific to QUIC. If there were a need for an extension of some sort >> in QUIC (there isn't, Section 9 explains why), then maybe we could take that >> work on once the other work is more mature. >> >> Otherwise, I don't think that the document is quite ready. The split is >> appreciated, but I'm seeing a lot of troubling indications. Just from a >> quick skim, this is what I see: >> >> * The design is asymmetric. Lots of talk about servers being the ones to >> apply this logic, but none about clients. >> >> * The actual logic beyond the four high-level states (these are fine) is >> extraordinarily vague. >> >> * The way in which topology changes are detected is unlikely to be good; >> better heuristics are needed. >> >> I'm not saying that people can't do what is suggested. The overall >> structure of what is being suggested here is good. I just think that it is >> isn't ready to take this step. And if it does, the QUIC WG isn't where it >> should be stepping. > > Agree with Martin about quicwg not being the right place for this. I > understand that it tries to explain how to trust the advertised values but > that is not specific to QUIC. You can even do the same with a TLS extension > and TCP. I think a better approach is to define how we can safely resume > transport control state and then explain how it could be done in QUIC, TCP, > or TCP/TLS and what are the drawbacks.
