Hi all, I took a quick re-read of the document and think is very well written and clear. However, I agree with Martin that this (part of the) document doesn’t seem to be QUIC-specific and therefore probably the QUIC group might not be the right place to advance this document.
Just as an editorial note, while the text is clear and well written as II just said, I'm not sure if all this discussion needs to be part of a potential IETF RFC. I think the most important part might be in section 6. Also reading about the "unvalidated" phase, this trigger the association to RFC7661 to me. Given Gorry is an author of both documents, I assume there is a connection. So, couldn't/shouldn't we even re-use the algorithm specified in RFC7661? Mirja On 13.07.22, 14:50, "QUIC on behalf of Martin Thomson" <[email protected] on behalf of [email protected]> wrote: On Wed, Jul 13, 2022, at 19:02, Gorry Fairhurst wrote: > I'm unsure why you think the QUIC protocol is not the best place to > consider such an extension. QUIC has various features that make it a > much easier place to do this type of change - the design of the > transport, the ability to update implementations, and a design which > implies pacing, security, etc. Simple test: if you took "QUIC" out and replaced it with DCCP, the draft would still work. This is a congestion control document, not a QUIC one. Sure, QUIC is a great testbed. I expect that this will work there. It will also work very nicely with TCP. Google was doing something very similar ~10 years ago in TCP, though maybe less measured and careful.
