[tsvwg] Re: WGLC for Convergence of Congestion Control from Retained State (draft-ietf-tsvwg-careful-resume)

[Marten Seemann <[e-mail]>]

This one slipped through the cracks, but better late than never — this
email officially marks the end of the WGLC.

Thanks to everyone who took the time to read the draft and share feedback,
and thanks to the authors for incorporating the input and publishing an
updated version.

On Sat, 15 Mar 2025 at 21:31, Gorry Fairhurst <[e-mail]> wrote:

> On 15/03/2025 17:23, Kazuho Oku wrote:
>
> Hello,
>
> I know it's really late but I finally had a chance to read -15 (the most
> recent version). I see lots of improvements from -12, -15 looks really
> great. Thank you for all the efforts.
>
> When reading -15, I had the following questions floating inside my head. I
> could very well be missing something, or it could be the case that the same
> question has already been asked and answered. If so, please forgive me for
> the noise.
>
> These are good points.
>
>
> Section 3.1:
> > If the measured CWND is less than four times the Initial Window (IW) a
> sender can choose to not save the CC parameters, because the additional
> actions associated with performing Careful Resume for a small CWND would
> not justify its use.
>
> Isn't it two times, assuming that RTT is known during connection
> establishment?
>
> I think the benefit comes when the saved_cwnd is x4, i.e., the jump_cwnd >
> 2 *IW.
>
>
> Section 3.6:
>
> This section talks about RTO, but QUIC does not have RTO. QUIC uses Probe
> Timeouts (PTOs) instead; see RFC 9002 Section 4.7.  Considering that the
> I-D gives specific advices to QUIC implementers in other sections, it might
> make sense to refer to PTO here.
>
> Yes, to make this better suited to QUIC, I suggest:
>
> "A sender that experiences persisent congestion (e.g., a Retransmission
> Time Out, RTO, expiry in TCP) ceases to use Careful Resume."
>
>
> Section 4.1:
>
> > At the end of slow start, the CWND can be significantly larger than
> needed to fully utilise the path (i.e., a CWND overshoot). It is
> inappropriate to use an overshoot in the CWND as a basis for estimating the
> capacity. In most cases, the CWND will converge to a stable value after
> several more RTTs. One mitigation could be to set the saved_cwnd based on
> the flight_size, or an averaged CWND.
>
> I-D suggests the use of flight_size, but doesn’t flight_size share the
> same problem? I think what we might want to suggest here is to use the
> confirmed pipe size (i.e., CWND / 2) if the connection is closed during
> Slow Start.
>
> I suggest:
>
> One mitigation when a connection is in Slow Start could be to set the
> saved_cwnd based on the validated pipe size (i.e., CWND / 2).
>
> Thanks again, do let me know if these changes would address your comments,
>
> Gorry
>
>
> 2025年1月19日(日) 21:25 Marten Seemann <[e-mail]>:
>
>> This email starts a 2 week WG Last Call call to determine if the
>> following TSVWG ID is ready to publish:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-careful-resume/
>>
>> This document targets Proposed Standard.
>>
>> The WGLC will conclude on February 2, 2025.
>>
>> Please do read the draft, and send any comments/concerns to the TSVWG
>> mailing list, including notes on whether these are ready to publish (or
>> send an email directly to the chairs).
>>
>> Best wishes,
>> Gorry and Marten
>> (tsvwg co-chairs)
>>
>
>
> --
> Kazuho Oku
>
>
>