[CCWG] Re: Mahesh Jethanandani's Discuss on draft-ietf-ccwg-ratelimited-increase-06: (with DISCUSS and COMMENT)

[Gorry Fairhurst <[e-mail]>]

Mahesh,

The editors have worked on a new revision of the I-D, please could you 
see if this addresses your concerns, or if some additional work is still 
needed. Some responses to comments are included below, see "GF:".


On 03/08/2026 18:50, Mahesh Jethanandani via Datatracker wrote:
> Mahesh Jethanandani has entered the following ballot position for
> draft-ietf-ccwg-ratelimited-increase-06: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ccwg-ratelimited-increase/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> I support Ketan's and Roman's COMMENTs and want to raise it to a DISCUSS questioning how this
> document actually updates RFC 4341, RFC 5681, RFC 9002, RFC 9260, and RFC
> 9438. I think it is worth a discussion to understand why is it that the only place in
> the document that states, per updated RFC, what changes are in
> Appendix B -- and Appendix B is explicitly marked for removal before publication.
>
> Outside of Appendix B, Section 3.2.1 speaks to rate-based and cwnd-based
> algorithms in general terms, and Section 1 only relates this document to CWV
> [RFC7661] in general terms; neither one says, per RFC, what text is affected.
>
> I'd ask the authors to move the substance of the per-RFC Assessment
> subsections -- or at least the operative sentence of each, out of
> Appendix B and into body text (Section 1 or
> a new section).
GF: We understood this to require a different approach from the original 
I-D and we agree. We have added a new section. Each of the updated RFCs 
are written slightly differently, but were possible we have sought to 
identify the text to be updated, please check the latest revision.
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Appendix A, worked example pseudocode:
>
> 415 >   Received 2 ACKs; maxFS=10000, if (cwnd<2*maxFS) {cwnd +=ACK'ed}
> 416 >     ACK for  2000 ACK'ed=2000 : cwnd+= 2000; cwnd=12000
> 417 >     ACK for  4000 ACK'ed=2000 : cwnd+= 2000; cwnd=14000
>
> This pseudocode (repeated at lines 433, 451, and 481) doesn't implement the
> same rule as Section 3's formula:
>
> 200 >   cwnd_new = cwnd + min (N, SMSS)
> 201 >   cwnd = min(cwnd_new, 2*maxFS)
>
> Section 3 always clamps to the cap via min(), so cwnd can never exceed
> limit(maxFS) even when an increment would carry it past the boundary. The
> appendix's "if (cwnd<2*maxFS) {cwnd+=ACK'ed}" instead gates the entire
> increment on a strict less-than test: if cwnd is even 1 byte under the cap,
> the full ACK'ed amount is added, which can carry cwnd past the cap when the
> increment doesn't land exactly on the boundary. The worked example never
> exposes this because every increment in it happens to align exactly with the
> cap (cwnd reaches the cap precisely on an ACK boundary in each round). I'd
> suggest rewriting the pseudocode as "cwnd = min(cwnd + ACK'ed, 2*maxFS)" to
> match Section 3 and avoid an implementer copying the appendix's version
> literally and overshooting the cap.

GF: Thanks. Well spotted, that was entirely my mistake and text has now 
been updated. We also have changed the example a little, to avoid 
introducing behaviours that were specific to QUIC and TCP. I hope this 
new appendix text is useful and better understood.

>
> ---
>
> 357 >   6.2.  Informative References
> ...
> 380 >   [RFC7661]  Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating
> 381 >              TCP to Support Rate-Limited Traffic", RFC 7661,
> 382 >              DOI 10.17487/RFC7661, October 2015,
> 383 >              <https://www.rfc-editor.org/rfc/rfc7661>.
>
> The shepherd write-up's answer to question 17 states "The document has a
> normative reference to RFC 7661, which is Experimental," and Lars Eggert's
> TSVART review of -03 flagged the resulting DOWNREF as missing from the Last
> Call and the DOWNREF registry. But -06, as quoted above, lists RFC 7661
> under Informative References, not Normative. Given the Terminology section's
> two new definitions, each cite RFC 7661 as their basis, I can see why the
> categorization has been changing across versions. Could the shepherd or
> authors confirm which is correct for -06? If Informative is correct, the
> DOWNREF concern is moot, and the shepherd write-up should be updated to say
> so; if RFC 7661 should in fact be Normative, the DOWNREF registry step Lars
> flagged still needs to happen.

GF: We can confirm this citation is not normative. RFC7661 is 
complimentary but is not changed by this update.

We will request the Shepherd to ammend the document write-up.

>
> ----------------------------------------------------------------------
> NIT
> ----------------------------------------------------------------------
>
> All comments below are about very minor potential issues that you may
> choose to address in some way - or ignore - as you see fit. Some were
> flagged by automated tools (via
> https://github.com/larseggert/ietf-reviewtool) so there will likely
> be some false positives. There is no need to let me know what you did
> with these suggestions.
>
> 4 > Updates: RFC4341, RFC5681, RFC9002, RFC9260,                T. Henderson
> 5 >          RFC9438 (if approved)                  University of Washington
>
> The shepherd write-up's nit list already caught this: the Updates line
> should list bare RFC numbers (4341, 5681, 9002, 9260, 9438), not "RFC4341"
> etc. Still present in -06.
>
> ---
GF: Ah, also my mistake. This ought to be fixed in the updated I-D.
>
> 366 >   [RFC2861]  Handley, M., Padhye, J., and S. Floyd, "TCP Congestion
> 367 >              Window Validation", RFC 2861, DOI 10.17487/RFC2861, June
> 368 >              2000, <https://www.rfc-editor.org/rfc/rfc2861>.
>
> RFC 2861 is obsoleted by RFC 7661. The document is not referenced anywhere
> and since the document already cites RFC 7661 elsewhere, why keep this obsoleted
> reference.
>
GF: This was a historic citation to the DCCP specification that relied 
on the approach in RFC2861 within the survey of implementations. That 
"survey work" in the appendix was original input to CCWG and has been 
removed in the final version of the I-D. This reference no longer appears.

Best wishes from

Gorry, Mohit and Michael

(Editors)