Ballot for draft-ietf-ccwg-ratelimited-increase
Discuss
Yes
No Objection
Recuse
No Record
Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
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).
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.
---
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.
----------------------------------------------------------------------
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.
---
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.
Many thanks to Marc Blanchet for the ARTART review.
Thanks for your work done in this document and for addressing my [previous DISCUSS ballot](https://mailarchive.ietf.org/arch/msg/ccwg/vXz4pQU7D4et8K9RbQWdoBA4cck/)
Thanks to the authors and the WG for their work on this document. Like Roman, I am unable to understand how this document is updating all those listed transport protocol RFCs. My best reference was Appendix B which (unfortunately is going to get removed before publication!) holds the text that get the closest to the impact/change. From my reading of that text as someone not familiar with the protocol, it seems like only DCCP (RFC4341) and TCP CC (RFC5681) are really updated and the others have tackled this already? I've never seen a document that is updating another but not specifically saying what is being updated. Is this covered in some non-obvious way? I would have filed this as something to DISCUSS but I don't know if I would be able to hold such a discussion. Also, I would expect RFC4341 to have been a normative reference if this document were indeed updating it, but I cannot be sure if it is updating that ...
This document’s abstract, but not in the body of the document, asserts that: This document specifies how transport protocols increase their congestion window when the sender is rate-limited, and updates RFC 4341, RFC 5681, RFC 9002, RFC 9260, and RFC 9438. What is not clearly states is how to specifically merge this guidance into the existing text in any of the referenced documents.
I support Mahesh's DISCUSS and the multiple ADs that call out the same thing. The draft needs to specify what text it is updating for each RFC it is updating, or it isn't updating them. I do not see any issues with the technical content of the document once this is straightened out.
I was an editor of this document.