On 7/11/2022 7:07 PM, Martin Thomson 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.
The draft started as the definition of a QUIC extension which peers
could use to inform the other peer of what they remembered of previous
connections. After discussion, it was agreed to split that "QUIC
Extension" draft in two, one concentrating on the general issue of
reusing what was remembered, and the other specifying QUIC extensions if
needed. This further evolved in concentrating on the principles of
reusing prior knowledge, because QUIC extensions that pass information
to the peer are only useful if the server can trust the client (and vice
versa).
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.
I have implemented it in a symmetric way, with each peer able to
remember the data gathered in previous connection. A client that
regularly upload data to a server would benefit from that. But yes, this
could be better stated.
* 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.
That's actually where the draft has the strongest links with the QUIC
WG. The better heuristics need better data, which can only come from
observing the early stages of the connection. There are interactions
with ACK mechanisms, delayed ACK strategy, etc. It is much easier to
experiment and describe that concretely, in terms of protocol
mechanisms, rather than in the abstract.And it practice it is much
easier to experiment with QUIC than with TCP.
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.
We have all heard these statistics showing that a vast majority of
connections never exit slow start. That means there will be pressure on
engineers to make slow start faster. If we do not step up and specify
the good way to do this, we can be pretty sure that multiple
implementations will use the easy way instead.
Of course, I am not saying that the current draft has the final say on
the matter. Asking for adoption is also asking for feedback from a wider
group than the current authors.
-- Christian Huitema
