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

[Ketan Talaulikar <[e-mail]>]

Hi Gorry/co-authors,

Thanks a lot for those changes. They fully address my comments and
concerns. I find this document to now be much easier to follow for those
(like me) who are not steeped in the transport protocol congestion
management field.

Thanks,
Ketan


On Tue, Aug 11, 2026 at 1:31 PM Gorry Fairhurst <[e-mail]>
wrote:

> On 11/08/2026 05:08, Mahesh Jethanandani wrote:
>
> Hi Gorry,
>
> Clearing my DISCUSS. New Section 4 does what I was asking for — each
> updated RFC gets its own subsection in body text saying what changes,
> independent of Appendix B. Moving to No Objection.
>
> Two things worth a look before this goes to the RFC Editor, neither of
> which I'd hold the DISCUSS over:
>
> Section 4.2 (RFC 5681) doesn't name a section, unlike 4.1/4.3/4.4/4.5.
> RFC 5681 Section 3.1 is where the slow-start and congestion-avoidance
> rules you're amending actually live — naming it would make the set of
> five subsections consistent.
>
> That has been done now in
> https://github.com/ietf-wg-ccwg/draft-ietf-ccwg-ratelimited-increase/pull/111/changes
>
>
> Appendix A's Round 4 looks like it wasn't fully updated when the
> example was reworked to one-ACK-per-packet: the header still reads
> "Received 10 ACKs (N=2000)" but twenty ACK lines follow it, each for
> N=1000, and "ACK for 19000" appears twice in a row. Rounds 2 and 3
> have the same stale "(N=2000)" in their headers. Given how much of
> Appendix A changed between -06 and -08, another pass over it seems
> warranted.
>
> Mea culpa. I focussed on the contents, not headers. Corrected in:
>
>
> https://github.com/ietf-wg-ccwg/draft-ietf-ccwg-ratelimited-increase/pull/111/changes
>
> I will check the contents again though!
>
>
> Also, since you confirmed RFC 7661 is intentionally Informative: the
> shepherd write-up's answer to question 17 still calls it "a normative
> reference to RFC 7661" — worth a correction so it doesn't mislead whoever
> consults it next.
>
> I updated (the WG Chairs are likely not available).
>
>
> Thanks again for turning this around.
>
> And thanks for taking this up, the document is better for these changes.
> We expect to publish a new revision as soon as my co-editors check and
> approve the changes.
>
> Gorry
>
>
> On Aug 5, 2026, at 8:29 AM, Gorry Fairhurst <[e-mail]>
> <[e-mail]> wrote:
>
> 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>
> <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>
> <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)
>
>
>
> Mahesh Jethanandani
> [e-mail]
>
>
>
>
>
>
>
>