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.


On Tue, Jul 12, 2022, at 11:29, Lucas Pardue wrote:
> Hello QUIC WG,
>
> This is an adoption call for draft-kuhn-quic-careful-resume [1]. From 
> the abstract:
>
>    This document discusses careful resumption of congestion control
>    parameters in QUIC with a cautious method that enables faster startup
>    of new connections.
>
> This is an Informational document that explores the notion of "being 
> cautious when using previous values on a new path" set out in RFC 9000 
> [2].
>
> Prior to IETF 113, the authors created draft-kuhn-quic-careful-resume 
> by splitting out the common problem space, considerations (including 
> safety) and possible solutions, from a proposed technical design[3]. 
> The presentation at IETF 113 [4] [5] gave us more detail on 
> draft-kuhn-quic-careful-resume.
>
> The chairs would like to establish if there is interest in adopting the 
> careful resumption work in the QUIC WG. The call will run for 2 weeks, 
> ending on July 25 2022 at 23:59 anywhere on earth[6]. Please respond to 
> this email thread with any comments indicating support or objection. In 
> either case, elucidation of your opinion would be appreciated.
>
> Kind regards
> Lucas & Matt
> QUIC WG Chairs
>
>
> [1] - https://datatracker.ietf.org/doc/draft-kuhn-quic-careful-resume/
> [2] - https://www.rfc-editor.org/rfc/rfc9000.html#section-9.4-2
> [3] - https://www.ietf.org/archive/id/draft-kuhn-quic-0rtt-bdp-11.html
> [4] - 
> https://datatracker.ietf.org/meeting/113/materials/slides-113-quic-0rtt-bdp-00
> [5] - https://youtu.be/yHyv7ay6mIk?t=6850
> [6] - https://time.is/Anywhere_on_Earth

Reply via email to