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

[Gorry Fairhurst <[e-mail]>]

On 10/02/2025 14:13, Mirja Kuehlewind wrote:
>
> Hi all,
>
> sorry for my slightly late review. I think this document is very clear 
> and ready for publication. I only have one high-level comment that 
> could maybe need some additional clarification and a few minor and 
> fully editorial comments below.
>
Thanks Mirja for reading  this - it really helps to have people offering 
comments !!!

I've just posted rev -13, to try to address the WGLC comments so far.

> I think it is not fully clear what is meant exactly by “normal rules 
> for the current congestion controller“ e.g. here:
>
>    *  Validating Phase (Updating CWND): The CWND is updated using the
>       normal rules for the current congestion controller, this typically
>       allows CWND to be increased for each received acknowledgement that
>       indicates a packet has been successfully sent across the path.
>
> Is that meant to be Slow Start behavior or Congestion Avoidance. More 
> generally I think the document could be more explicit about slow 
> start, e.g. if you detect congestion during validation and exit into 
> normal mode, this means going into congestion avoidance because 
> congestion would have ended slow start. However, would be good to 
> spell this out clearly.
>
Yes well this is harder than it should be. So first, I did add more text 
on whether this is SS or CA.

Safe Retreat is actually odd. The problem is that the loss that triggers 
congestion could have been an arbitrary overload of the path - it's not 
just a x2 overshoot as in SS. That requires a large reduction, based on 
the partial knowledge the sender has at the time when congetsion is 
detected.

Long answer: Even when all the loss is recovered, the sender still does 
not know whether it used capacity which would have fairly been someone 
elses, hence we reset ssthresh on exit to the detected bottleneck rate, 
but still allow ss to grow the cwnd towards that bottleneck rate, in 
case there are other flows also sharing that bottleneck.

> Related to this, this doc says in the intro:
>
> “The present document specifies a CC mechanism, called Careful Resume,…”
>
> I think this is more confusing than helpful. It really doesn’t place 
> any congestion control. It rather can be used together with all kinds 
> of congestion controls.
>
I see it as a mechanism, not an algorithm (with many mechanisms and 
rules) - but usage of language varies, so I tried to adapt the text a 
little in rev -13.
>
> Some more editorial comments:
>
> I find some of the information in sec 4 a bit random or even 
> redundant. Especially section 4.5.  on Implementation Notes for using 
> BBR seems suddenly very detailed and I would have more likely expected 
> that in the appendix. Also on BBR in general: of course it is good to 
> mention in various places, because it’s quite different than 
> loss-based congestion control, however, maybe it would be better to 
> generalize this and talk about rate-based congestion control more in 
> general and name BBR only as an example.**
>
I'm really grateful to all those who helped accumulate this guidance for 
BBR, but I see what you say and I have gathered much more of the 
BBR-specific text in one place as an appendix as you suggest. I 
personally like it better this way, but I'm OK if people see better ways 
to present this.
>
> One minor editorial comment in Sec 1.5 (and also 4.2 actually):
>
> „e.g., using the recommended maximum IW for the first
>
>       RTT of transmitting data [RFC9000].“
>
> I think this should be RFC9002, and potentially also RFC6928.
>
Indeed it should be section 7.2 of RFC9002; and also RFC 6928, I'll 
check next PR (which likely will be soon).
>
> Also there are 2-3 places in the document where it talks about QUIC 
> specifically. However, I wonder if it really should only talk about 
> QUIC in these places or also say something about TCP as well.
>
OK. I think I have fixed in the next PR.
>
> And one nit in section 4.2 (if not already corrected):
>
> A sender also verifies that the initial data was acknowledged.
>    (i.e., loss could otherwise could be indicative of persistent
>    congestion).
>
> -> Remove “.” before the bracket; and two times “could” in the brackets.
>
Thanks - now fixed in the PR.
>
> Mirja
>
I'll try to work out how to handle the comments we haver received on 
qlog and then make another rev.

Gorry

> *From: *Zaheduzzaman Sarker <[e-mail]>
> *Date: *Wednesday, 29. January 2025 at 18:45
> *To: *Marten Seemann <[e-mail]>
> *Cc: *tsvwg <[e-mail]>
> *Subject: *[tsvwg] Re: WGLC for Convergence of Congestion Control from 
> Retained State (draft-ietf-tsvwg-careful-resume)
>
> Hi all,
>
> Marten will be on vacation when this last call will end and Gorry is 
> an author of this document, he need to recuse from making consensus 
> call here. With that I am extending this last call for one more week.
>
> There were some promises to review this document and I haven’t seen 
> much feedback/ review yet, so please use this extra week to send your 
> comments/ issues/ support.
>
> // Zahed
>
> On Sun, 19 Jan 2025 at 15:25, Marten Seemann <[e-mail]> 
> wrote:
>
>     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)
>