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.
