Re: Call for Adoption: Careful resumption of congestion control from retained state with QUIC

[Christian Huitema <[e-mail]>]

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