Re: [auth48] AUTH48: RFC-to-be 9438 <draft-ietf-tcpm-rfc8312bis-15> for your review

[Lynne Bartholomew <[e-mail]>]

Hi, Vidhi.  Thank you for the email.

We have updated this document per your notes below.

We have some follow-up questions for you:

Regarding this item and your reply:

> 2) <!— [rfced] Per the flag from idnits (below), should this document
> include the pre-RFC5378 disclaimer?
> 
> [VG] Ok to grant BCP78 rights to the IETF trust. Have discussed and got approval from all the co-authors of RFC 8312.

Apologies; does this mean "yes" or "no" to adding the pre-RFC5378 disclaimer?

= = = = =

Regarding these two items and your replies:

> 19) <!— [rfced] Section 4.6: xml2rfc yields the following warnings,
> indicating that the following text makes the lines too long for
> both HTML and text output files (PDF is OK):
> 
> [VG] Attached HTML file looks unchanged. I don't see (a), (b) and (c) in it. Although we are fine with the suggestion.
. . .
> 23) <!— [rfced] Section 4.7: xml2rfc yields the following warning
> for the "if cwnd < W and fast convergence enabled," line in
> the graphic just after the second paragraph of the section. This
> warning indicates that the line is too long for the text output:
> 
> [VG] Removing the spaces is fine.


We did not make any updates, because we do not know how to update the corresponding SVG.

= = = = =

Regarding this item and your reply:

> 24) <!— [rfced] Section 4.9: Per the "two types of spurious events"
> sentence in this section, it appears that "spurious fast
> retransmits" and "Spurious loss detected by acknowledgments" refer to
> the same phenomenon. Please confirm that this will be clear to
> readers.
> 
> [VG] This is interesting. To make it more clear, we can replace Spurious loss to Spurious retransmit in the title (4.9.2) as well as in the corresponding text in this section.

We see a total of eight instances of "spurious loss(es)" -- two instances in the section title and six instances in text.  Should all instances of "spurious loss(es)" be replaced with "spurious retransmit(s)"?

= = = = =

Regarding this item (our question 34)b)):

> b) Please let us know how/if the following should be made consistent:
> 
> 1-β / 1 - β
> (Please note that if you wish to make changes, we will need
> you to update the SVG as applicable.)
> 
> e-02 / e-2
> (For example, "1.0e-02" vs. "2.0e-2" in Tables 2 and 3, respectively) -->
> 
> [VG] This is also fine.

Does your reply mean that we should not make any changes?  If consistent expression is desired, please let us know your preference for each.

The latest files are posted here.  Please refresh your browser:

   https://www.rfc-editor.org/authors/rfc9438.txt
   https://www.rfc-editor.org/authors/rfc9438.pdf
   https://www.rfc-editor.org/authors/rfc9438.html
   https://www.rfc-editor.org/authors/rfc9438.xml
   https://www.rfc-editor.org/authors/rfc9438-diff.html
   https://www.rfc-editor.org/authors/rfc9438-rfcdiff.html
   https://www.rfc-editor.org/authors/rfc9438-auth48diff.html

   https://www.rfc-editor.org/authors/rfc9438-xmldiff1.html
   https://www.rfc-editor.org/authors/rfc9438-xmldiff2.html

Thanks again!

RFC Editor/lb


> On Jun 26, 2023, at 12:39 PM, Vidhi Goel <vidhi_goel=[e-mail]> wrote:
> 
> Dear Editors,
> 
> Thank you for the detailed comments. We have internally reviewed all the points and I am replying on behalf of all co-authors.
> 
> 1) <!— [rfced] Errata: It appears to us that Erratum ID 4068
> (https://www.rfc-editor.org/errata/eid4068) was never addressed.
> Please review, and let us know if any changes as related to "new
> data" are needed.
> 
> [VG]
> Section 4.1
> 
> OLD:
> _segments_acked_: Number of MSS-sized segments acked when a "new ACK"
> is received, i.e., an ACK that cumulatively acknowledges the delivery
> of new data.
> 
> NEW:
> _segments_acked_: Number of MSS-sized segments acked when a "new ACK"
> is received, i.e., an ACK that cumulatively acknowledges the delivery
> of previously unacknowledged data.
> 
> 2) <!— [rfced] Per the flag from idnits (below), should this document
> include the pre-RFC5378 disclaimer?
> 
> [VG] Ok to grant BCP78 rights to the IETF trust. Have discussed and got approval from all the co-authors of RFC 8312.
> 
> 3) <!— [rfced] Please insert any keywords (beyond those that appear in the
> title) for use on <https://www.rfc-editor.org/search>. 
> 
> [VG] Congestion control, large BDP, window scalability, RTT fairness
> 
> 4) <!— [rfced] Abstract: Although idnits output (pasted below)
> indicates that the original text "could be OK", we updated the text
> to make it clear that this document obsoletes RFC 8312 and updates
> RFC 5681. Please let us know any objections.
> 
> [VG] No Objections
> 
> 5) <!— [rfced] Section 1: Are "TCP-Reno" (RFCs 3481, 4015, 9331, and
> 9332, as well as one instance in this document), "TCP-RENO"
> (RFC 8312), and "Reno TCP" (approx. 20 RFCs) all interchangeable
> terms?
> We also see that RFC 8312 appears to be the only RFC that uses
> "TCP-NewReno" and that several RFCs use either "TCP NewReno" or
> (TCP) "New Reno".
> Also, we do not see "NewReno" mentioned in RFC 6675, except where it
> cites RFC 6582. Will this particular citation be clear to readers?
> 
> [VG] Yes, this citation will be clear to the readers.
> 
> 6) <!— [rfced] Section 1: Please clarify the meaning of "as part of
> [RFC5681] standard".
> 
> [VG] Ok to use the suggested text under Possibly.
> 
> 7) <!— [rfced] Section 3.1: We found this sentence difficult to
> follow. If the suggested text is not correct, please clarify how
> many items are listed in this sentence.
> 
> [VG] Suggested text looks good.
> 
> 8) <!— [rfced] Sections 3.3 and subsequent: We had trouble following
> the use of "independent of" and "independently of" in this document
> (whether the phrases refer to a verb or a noun). Please review, and
> let us know if any changes are needed.
> 
> [VG] Suggested text looks good.
> 
> 9) <!— [rfced] Section 3.3: Should "quadratical" be "quadratic" here?
> The only published RFC to date that uses "quadratical" is RFC 8312.
> 
> [VG] Yes, quadratic is better
> 
> 10) <!— [rfced] Section 4: "stages of the CUBIC congestion controller"
> reads oddly. Are some words missing?
> 
> [VG] It does read odd, we can change it to "stages of CUBIC congestion controller" if that sounds better.
> 
> 11) <!— [rfced] Section 4.1: "the number of bytes acknowledged in
> Figure 4" reads oddly. If the suggested text is not correct,
> please clarify.
> 
> [VG] Suggestion looks good.
> 
> 12) <!— [rfced] Sections 4.1.1 and subsequent: Per your request,
> please note that we ran the kramdown-rfc-clean-svg-ids tool to fix
> the issue related to duplicate SVG ids. If you have any questions,
> please see <https://github.com/cabo/kramdown-rfc/issues/196> for
> details regarding the behavior of this tool as related to the
> "xmldiff" output files. -->
> 
> [VG] ok.
> 
> 13) <!— [rfced] Sections 4.1.2 and subsequent: For consistency, and to
> avoid possible issues in output files, should "W_cubic" have a
> leading underscore, per the other variables?
> 
> [VG] For consistency that would make sense. But I think Lars asked to get these underscores fixed in a different email. 
> His suggestion was to wait for the fix to #596, so that the underscores will be removed by xml2rfc.
> 
> 14) <!— [rfced] Sections 4.2 and 4.6: We could not see what mechanisms
> are discussed in Section 3.1. Will it be easy for readers to find
> the mechanisms in question in the text of Section 3.1? Could
> "detected by mechanisms described in" be changed to "detected as
> described in”?
> 
> [VG] I think readers can find the relevant text in section 3.1. And the suggestion to change "detected by mechanisms described in" be changed to "detected as described in" works.
> 
> 15) <!— [rfced] Section 4.5: We are finding "it" and "CUBIC is very
> careful in this region" difficult to follow. If the suggested text
> is not correct, could this text be clarified in some other way?
> 
> [VG] Suggested text is not correct for this one.
> OLD:
> Unless it is overridden by the AIMD window increase, CUBIC is very
> careful in this region.
> 
> NEW:
> Unless the cwnd is overridden by the AIMD window increase,
> CUBIC will behave cautiously when operating in this region.
> 
> 16) <!— [rfced] Section 4.6: The only mention of "multiplicative
> decrease factor" that we see in RFC 5681 is as follows:
> 
> [VG] Multiplicative Decrease is a very common term, often referred as AIMD in RFCs. It should be clear.
> 
> 17) <!— [rfced] Section 4.6: This text was confusing, in that it
> appears that [RFC7661] and not the mechanisms describe how to manage
> and use _cwnd_ and _ssthresh_. Also, RFC 7661 appears to discuss
> multiple mechanisms. We updated the text accordingly. Please note,
> however, that it is not clear whether or not one mechanism in
> particular should be specified in the third sentence.
> 
> [VG] Provided suggestion sounds good.
> 
> 18) <!— [rfced] Section 4.6: Should "uses _cwnd_ to calculate new
> values for _cwnd_ ..." be "uses a _cwnd_ _value_ to calculate new
> values for _cwnd_ ..." per the text just previous to this sentence?
> 
> [VG] Yes
> 
> 19) <!— [rfced] Section 4.6: xml2rfc yields the following warnings,
> indicating that the following text makes the lines too long for
> both HTML and text output files (PDF is OK):
> 
> [VG] Attached HTML file looks unchanged. I don't see (a), (b) and (c) in it. Although we are fine with the suggestion.
> 
> 20) <!— [rfced] Section 4.6: Should "more than one round-trip" be
> "more than one round trip" or "more than one RTT"?
> 
> [VG] "more that one RTT" sounds better.
> 
> 21) <!— [rfced] Sections 4.6 and 5.5: These sentences seem to indicate
> that ECN-Echo ACKs cause the congestion events rather than detect
> or indicate them. May we update as suggested, along the lines of
> "congestion event detected by duplicate acknowledgments (ACKs)" in
> Section 3.1?
> 
> [VG] Yes, suggested text looks good.
> 
> 22) <!— [rfced] Section 4.6: We see "retransmit timer" in RFC 3168
> but no mention of "exponential". Will this citation be clear to
> readers?
> 
> [VG] This is an interesting one. Retransmit timer implicitly uses backoff when ACKs are not received or in this case, the sender keeps receiving ECE signals. So, this should be clear to the readers.
> 
> 23) <!— [rfced] Section 4.7: xml2rfc yields the following warning
> for the "if cwnd < W and fast convergence enabled," line in
> the graphic just after the second paragraph of the section. This
> warning indicates that the line is too long for the text output:
> 
> [VG] Removing the spaces is fine.
> 
> 24) <!— [rfced] Section 4.9: Per the "two types of spurious events"
> sentence in this section, it appears that "spurious fast
> retransmits" and "Spurious loss detected by acknowledgments" refer to
> the same phenomenon. Please confirm that this will be clear to
> readers.
> 
> [VG] This is interesting. To make it more clear, we can replace Spurious loss to Spurious retransmit in the title (4.9.2) as well as in the corresponding text in this section.
> 
> 25) <!— [rfced] Section 4.10: Please confirm that the missing
> underscores in the current text output will not be problematic
> in the text output when this document is published. The HTML and PDF
> outputs look as expected, but the text output here is currently
> missing one trailing underscore ("_cwnd_prior ") and one leading
> underscore (" cwnd_").
> 
> [VG] This is similar to issue #13 where we want to get rid of trailing and leading underscores. If that is not possible, then we would want the missing trailing underscore ("_cwnd_prior ") and one leading underscore (" cwnd_").
> 
> 26) <!— [rfced] Section 5.10: Does "to the congestion control at the
> sender" mean "to congestion control settings at the sender", "to
> congestion control at the sender", or something else? (In other
> words, please clarify "the congestion control".)
> 
> [VG] It should be “to congestion control at the sender”
> 
> 27) <!— [rfced] Section 6: This sentence was difficult to follow due to
> comma usage. We updated as follows. If this is incorrect, please
> clarify.
> 
> [VG] Provided suggestion is good.
> 
> 28) <!—[rfced] For the following reference, would it be easier for the
> reader if a direct link was provided to the technical report
> instead of a link to the gzip file? We found that the report at
> <https://www.cs.utexas.edu/ftp/techreports/tr02-39.pdf> only
> provides the Introduction. Please let us know if you would like
> to leave the URL as is or use a direct URL that points to the
> complete report (note that the complete report can be accessed
> directly here: https://citeseerx.ist.psu.edu/document?repid=
> rep1&type=pdf&doi=1828bdcef118b02d3996b8e00b8aaa92b50abb0f).
> 
> [VG] I think we should point to the complete report using the URL provided above.
> 
> 29) <!— [rfced] Original Appendices B.20 and B.21 (now Appendices A.1
> and A.2): The current Appendix A.1 does not appear to contain any
> relevant information beyond what is already provided in the Abstract
> and Introduction (i.e., moving to the Standards Track), and it does
> not seem relevant to the evolution of CUBIC. May we remove this
> section?
> 
> [VG] Original Appendix B included B.1 to B.20 which showed evolution of Cubic bis draft. Without B.1 to B.19, B.20 (now A.1) itself doesn’t provide any information. Ok to remove B.20 (A.1) if we can’t keep B.1 to B.19
> 
> Also, should "differences between the original paper and [RFC8312]"
> be "differences between the original paper, [RFC8312], and this
> document"?
> 
> [VG] Regarding B.21 (now A.2), this only covers differences between the original paper and RFC8312. I don’t think it includes things we have added in CUBIC-bis.
> 
> Possibly:
> Appendix A. Evolution of CUBIC since the Original Paper -->
> [VG] Fine with this title change as well.
> 
> 30) <!— [rfced] Original Appendix B.21 (currently Appendix A.2):
> 
> a) Although we see "CUBIC multiplication decrease factor" on Page 6
> of RFC 8312, we see "CUBIC Decrease Factor" (title of Section 3.4),
> "multiplicative window decrease factor", and "CUBIC multiplicative
> decrease factor" used elsewhere in this document.
> 
> RFC 8312 also uses "multiplicative window decrease factor" and
> "multiplicative decrease factor" in its text.
> 
> Should these distinctions be explained for readers?
> [VG] There is no distinction between "CUBIC multiplication decrease factor" or "CUBIC Decrease Factor" or ""multiplicative window decrease factor". The right term is "CUBIC multiplicative decrease factor" taking multiplication decrease from MD of AIMD. We can make this consistent in the draft.
> 
> b) "beta__cubic_ * _W_max_" was difficult for us to find in
> RFC 8312. Will readers easily find this equation, or would it
> be helpful to change it to "_W_max*β__cubic", per
> "W_max*beta_cubic" (Sections 4.1 and 4.2 of RFC 8312)?
> 
> [VG] A * B is same as B * A. I think readers can easily find beta_cubic * W_max in RFC 8312.
> 
> 31) <!— [rfced] Appendix C: Does "substituting _K_ with Figure 12 in
> Figure 9" mean "substituting _K_ from Figure 9 with _K_ from
> Figure 12" or something else? Please clarify.
> 
> [VG] This can be written as “substituting _K_ from Figure 12 in Figure 9”
> 
> 
> 32) <!— [rfced] Acknowledgments: We found this comment at the end of
> the section in the XML file: "Anyone else to acknowledge?"
> Please let us know if other names should be added. -->
> 
> [VG] No one else needs to be added.
> 
> 33) <!— [rfced] Please review the "Inclusive Language" portion of the
> online Style Guide at
> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
> and let us know if any changes are needed.
> 
> [VG] I believe Lars had reviewed this before and no changes are needed.
> 
> 34) <!— [rfced] Please let us know if any changes are needed for the
> following:
> 
> a) The following terms were used inconsistently in this document.
> We chose to use the latter forms. Please let us know any objections.
> 
> Fast Convergence / fast convergence (per RFC 8312 and per more
> common usage in post-6000 published RFCs)
> 
> RTT fairness / RTT-fairness (per RFC 8312; also per
> "TCP-friendliness" in RFC 8312)
> 
> [VG] This is fine.
> 
> b) Please let us know how/if the following should be made consistent:
> 
> 1-β / 1 - β
> (Please note that if you wish to make changes, we will need
> you to update the SVG as applicable.)
> 
> e-02 / e-2
> (For example, "1.0e-02" vs. "2.0e-2" in Tables 2 and 3, respectively) -->
> 
> [VG] This is also fine.
> 
> 
> Let us know if there are further comments.
> 
> Thanks,
> Vidhi
> 
> 
>> On Jun 21, 2023, at 5:19 PM, [e-mail] wrote:
>> 
>> Authors,
>> 
>> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
>> 
>> 1) <!-- [rfced] Errata: It appears to us that Erratum ID 4068
>> (https://www.rfc-editor.org/errata/eid4068) was never addressed.
>> Please review, and let us know if any changes as related to "new
>> data" are needed.
>> 
>> Original (Section 4.1):
>> _segments_acked_: Number of MSS-sized segments acked when a "new ACK"
>> is received, i.e., an ACK that cumulatively acknowledges the delivery
>> of new data. -->
>> 
>> 
>> 2) <!-- [rfced] Per the flag from idnits (below), should this document
>> include the pre-RFC5378 disclaimer?
>> 
>> - The document seems to lack a disclaimer for pre-RFC5378 work, but may
>>   have content which was first submitted before 10 November 2008.  If you
>>   have contacted all the original authors and they are all willing to grant
>>   the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
>>   this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
>>   (See the Legal Provisions document at
>>   https://trustee.ietf.org/license-info for more information.) -->
>> 
>> 
>> 3) <!-- [rfced] Please insert any keywords (beyond those that appear in the
>> title) for use on <https://www.rfc-editor.org/search>. -->
>> 
>> 
>> 4) <!-- [rfced] Abstract:  Although idnits output (pasted below)
>> indicates that the original text "could be OK", we updated the text
>> to make it clear that this document obsoletes RFC 8312 and updates
>> RFC 5681.  Please let us know any objections.
>> 
>> Original:
>> Based on the extensive deployment experience with
>> CUBIC, it also moves the specification to the Standards Track,
>> obsoleting RFC 8312.  This also requires updating RFC 5681, to allow
>> for CUBIC's occasionally more aggressive sending behavior.
>> 
>> Currently:
>> Based on the extensive deployment experience with
>> CUBIC, this document also moves the specification to the Standards
>> Track and obsoletes RFC 8312.  This document also updates RFC 5681,
>> to allow for CUBIC's occasionally more aggressive sending behavior.
>> 
>> idnits output:
>> - The draft header indicates that this document obsoletes RFC8312, but the
>>    abstract doesn't seem to directly say this.  It does mention RFC8312
>>    though, so this could be OK.
>> 
>> - The draft header indicates that this document updates RFC5681, but the
>>    abstract doesn't seem to directly say this.  It does mention RFC5681
>>    though, so this could be OK. -->
>> 
>> 
>> 5) <!-- [rfced] Section 1:  Are "TCP-Reno" (RFCs 3481, 4015, 9331, and
>> 9332, as well as one instance in this document), "TCP-RENO"
>> (RFC 8312), and "Reno TCP" (approx. 20 RFCs) all interchangeable
>> terms?
>> 
>> We also see that RFC 8312 appears to be the only RFC that uses
>> "TCP-NewReno" and that several RFCs use either "TCP NewReno" or
>> (TCP) "New Reno".
>> 
>> Also, we do not see "NewReno" mentioned in RFC 6675, except where it
>> cites RFC 6582.  Will this particular citation be clear to readers?
>> 
>> Original:
>> This problem is equally applicable to all Reno-style standards and their
>> variants, including TCP-Reno [RFC5681], TCP-NewReno
>> [RFC6582][RFC6675], SCTP [RFC9260], TFRC [RFC5348], and QUIC
>> congestion control [RFC9002], which use the same linear increase
>> function for window growth. -->
>> 
>> 
>> 6) <!-- [rfced] Section 1:  Please clarify the meaning of "as part of
>> [RFC5681] standard".
>> 
>> Original:
>> Additionally, CUBIC
>> recommends the HyStart++ algorithm [I-D.ietf-tcpm-hystartplusplus]
>> for slow start, which allows for cwnd increases of more than SMSS
>> bytes for incoming acknowledgments during slow start, while this
>> behavior is not allowed as part of [RFC5681] standard.
>> 
>> Possibly:
>> Additionally, CUBIC recommends the HyStart++ algorithm
>> [RFC9406] for slow start, which allows for cwnd increases of more
>> than SMSS bytes for incoming acknowledgments during slow start, while
>> this behavior is not allowed as part of the standard behavior
>> prescribed by [RFC5681]. -->
>> 
>> 
>> 7) <!-- [rfced] Section 3.1:  We found this sentence difficult to
>> follow.  If the suggested text is not correct, please clarify how
>> many items are listed in this sentence.
>> 
>> Original:
>> After a window reduction in response to a congestion event detected
>> by duplicate ACKs, Explicit Congestion Notification-Echo (ECN-Echo,
>> ECE) ACKs [RFC3168], TCP RACK [RFC8985] or QUIC loss detection
>> [RFC9002], CUBIC remembers the congestion window size at which it
>> received the congestion event and performs a multiplicative decrease
>> of the congestion window.
>> 
>> Suggested:
>> After a window reduction in response to a congestion event detected
>> by duplicate ACKs, Explicit Congestion Notification-Echo (ECN-Echo
>> (ECE)) ACKs [RFC3168], RACK-TLP for TCP [RFC8985], or QUIC loss
>> detection [RFC9002], CUBIC remembers the congestion window size at
>> which it received the congestion event and performs a multiplicative
>> decrease of the congestion window. -->
>> 
>> 
>> 8) <!-- [rfced] Sections 3.3 and subsequent:  We had trouble following
>> the use of "independent of" and "independently of" in this document
>> (whether the phrases refer to a verb or a noun).  Please review, and
>> let us know if any changes are needed.
>> 
>> Original:
>> Specifically, CUBIC maintains a window increase rate independent of
>> RTTs outside the Reno-friendly region, and thus flows with different
>> RTTs have similar congestion window sizes under steady state when
>> they operate outside the Reno-friendly region.
>> ...
>> CUBIC always ensures a linear throughput ratio independent of the
>> loss environment.
>> ...
>> CUBIC flows with the
>> same RTT always converge to the same throughput independent of
>> statistical multiplexing, thus achieving intra-algorithm fairness.
>> ...
>> This is true
>> independently of the level of statistical multiplexing on the link.
>> 
>> Perhaps:
>> Specifically, CUBIC maintains a window increase rate that is
>> independent of RTTs outside the Reno-friendly region, and thus
>> flows with different RTTs have similar congestion window sizes
>> under steady state when they operate outside the Reno-friendly
>> region.
>> ...
>> CUBIC always ensures a linear throughput ratio that is independent
>> of the loss environment.
>> ...
>> CUBIC flows with the
>> same RTT always converge to the same throughput independently of
>> statistical multiplexing, thus achieving intra-algorithm fairness.
>> ...
>> This is true and is
>> independent of the level of statistical multiplexing on the link. -->
>> 
>> 
>> 9) <!-- [rfced] Section 3.3:  Should "quadratical" be "quadratic" here?
>> The only published RFC to date that uses "quadratical" is RFC 8312.
>> 
>> Original:
>> While there is
>> no consensus on the optimal throughput ratio for different RTT flows,
>> over wired Internet paths, use of a linear throughput ratio seems
>> more reasonable than equal throughputs (i.e., the same throughput for
>> flows with different RTTs) or a higher-order throughput ratio (e.g.,
>> a quadratical throughput ratio of Reno in synchronous loss
>> environments). -->
>> 
>> 
>> 10) <!-- [rfced] Section 4:  "stages of the CUBIC congestion controller"
>> reads oddly.  Are some words missing?
>> 
>> Original:
>> This section discusses how the congestion window is updated during
>> the different stages of the CUBIC congestion controller. -->
>> 
>> 
>> 11) <!-- [rfced] Section 4.1:  "the number of bytes acknowledged in
>> Figure 4" reads oddly.  If the suggested text is not correct,
>> please clarify.
>> 
>> Original:
>> Implementations can use bytes to express window sizes, which would
>> require factoring in the maximum segment size wherever necessary and
>> replacing _segments_acked_ with the number of bytes acknowledged in
>> Figure 4.
>> 
>> Suggested:
>> Implementations can use bytes to express window sizes, which would
>> require factoring in the MSS wherever necessary and replacing
>> _segments_acked_ (Figure 4) with the number of acknowledged bytes. -->
>> 
>> 
>> 12) <!-- [rfced] Sections 4.1.1 and subsequent:  Per your request,
>> please note that we ran the kramdown-rfc-clean-svg-ids tool to fix
>> the issue related to duplicate SVG ids.  If you have any questions,
>> please see <https://github.com/cabo/kramdown-rfc/issues/196> for
>> details regarding the behavior of this tool as related to the
>> "xmldiff" output files. -->
>> 
>> 
>> 13) <!-- [rfced] Sections 4.1.2 and subsequent:  For consistency, and to
>> avoid possible issues in output files, should "W_cubic" have a
>> leading underscore, per the other variables?
>> 
>> Original:
>> W_cubic(_t_): The congestion window in segments at time _t_ in
>> seconds based on the cubic increase function, as described in
>> Section 4.2.
>> ...
>> _target_: Target value of congestion window in segments after the
>> next RTT, that is, W_cubic(_t_ + _RTT_), as described in Section 4.2.
>> ...
>> To summarize, CUBIC computes both W_cubic(_t_) and _W_est_ (see
>> Section 4.3) on receiving a new ACK in congestion avoidance and
>> chooses the larger of the two values.
>> ...
>> When receiving a new ACK in
>> congestion avoidance (where _cwnd_ could be greater than or less than
>> _W_max_), CUBIC checks whether W_cubic(_t_) is less than _W_est_.
>> ...
>> Section 4.2 requires that _t_ in Figure 1 does
>> not include application-limited periods, such as idle periods,
>> otherwise W_cubic(_t_) might be very high after restarting from these
>> periods. -->
>> 
>> 
>> 14) <!-- [rfced] Sections 4.2 and 4.6:  We could not see what mechanisms
>> are discussed in Section 3.1.  Will it be easy for readers to find
>> the mechanisms in question in the text of Section 3.1?  Could
>> "detected by mechanisms described in" be changed to "detected as
>> described in"?
>> 
>> Original:
>> During congestion avoidance, after a congestion event is detected by
>> mechanisms described in Section 3.1, CUBIC uses a window increase
>> function different from Reno.
>> ...
>> When a congestion event is detected by mechanisms described in
>> Section 3.1, CUBIC updates _W_max_ and reduces _cwnd_ and _ssthresh_
>> immediately as described below. -->
>> 
>> 
>> 15) <!-- [rfced] Section 4.5:  We are finding "it" and "CUBIC is very
>> careful in this region" difficult to follow.  If the suggested text
>> is not correct, could this text be clarified in some other way?
>> 
>> Original:
>> Unless it is overridden by the AIMD window increase, CUBIC is very
>> careful in this region.
>> 
>> Suggested (assuming that "it" refers to the convex region):
>> Unless the convex region is overridden by the AIMD window increase,
>> CUBIC will behave cautiously when operating in this region. -->
>> 
>> 
>> 16) <!-- [rfced] Section 4.6:  The only mention of "multiplicative
>> decrease factor" that we see in RFC 5681 is as follows:
>> 
>> "Additional early  work in additive-increase, multiplicative-decrease
>> congestion control is given in [CJ89]."
>> 
>> Also, we do not see the words "multiplicative" or "decrease" in
>> RFC 6675.
>> 
>> Will these citations be clear to readers?
>> 
>> Original:
>> The parameter β__cubic_ SHOULD be set to 0.7, which is different from
>> the multiplicative decrease factor used in [RFC5681] (and [RFC6675])
>> during fast recovery. -->
>> 
>> 
>> 17) <!-- [rfced] Section 4.6:  This text was confusing, in that it
>> appears that [RFC7661] and not the mechanisms describe how to manage
>> and use _cwnd_ and _ssthresh_.  Also, RFC 7661 appears to discuss
>> multiple mechanisms.  We updated the text accordingly.  Please note,
>> however, that it is not clear whether or not one mechanism in
>> particular should be specified in the third sentence.
>> 
>> If anything is incorrect, please provide clarifying text.
>> 
>> Original:
>> To avoid such suboptimal performance, the mechanisms
>> described in [RFC7661] can be used.  These describe how to manage and
>> use _cwnd_ and _ssthresh_ during a rate-limited Interval, and how to
>> update _cwnd_ and _ssthresh_ after congestion has been detected.  The
>> mechanism defined in [RFC7661] is safe to use even when _cwnd_ is
>> greater than the receive window, because it validates _cwnd_ based on
>> the amount of data acknowledged by the network in an RTT, which
>> implicitly accounts for the allowed receive window.
>> 
>> Currently:
>> To avoid such suboptimal performance, the mechanisms
>> described in [RFC7661] can be used.  [RFC7661] describes how to
>> manage _cwnd_ and _ssthresh_ during a rate-limited interval, and how
>> to update _cwnd_ and _ssthresh_ after congestion has been detected.
>> The mechanisms defined in [RFC7661] are safe to use even when _cwnd_
>> is greater than the receive window, because they validate _cwnd_
>> based on the amount of data acknowledged by the network in an RTT,
>> which implicitly accounts for the allowed receive window. -->
>> 
>> 
>> 18) <!-- [rfced] Section 4.6:  Should "uses _cwnd_ to calculate new
>> values for _cwnd_ ..." be "uses a _cwnd_ _value_ to calculate new
>> values for _cwnd_ ..." per the text just previous to this sentence?
>> 
>> Original (the previous two sentences are included for context):
>> Such measures are important to prevent a CUBIC sender from using an
>> arbitrarily high cwnd _value_ when calculating new values for
>> _ssthresh_ and _cwnd_ when congestion is detected.  This might not be
>> as robust as the mechanisms described in [RFC7661].
>> 
>> A QUIC sender that uses _cwnd_ to calculate new values for _cwnd_ and
>> _ssthresh_ after detecting a congestion event is REQUIRED to apply
>> similar mechanisms [RFC9002].
>> 
>> Suggested:
>> A QUIC sender that uses a _cwnd_ _value_ to calculate new values for
>> _cwnd_ and _ssthresh_ after detecting a congestion event is REQUIRED
>> to apply similar mechanisms [RFC9002]. -->
>> 
>> 
>> 19) <!-- [rfced] Section 4.6:  xml2rfc yields the following warnings,
>> indicating that the following text makes the lines too long for
>> both HTML and text output files (PDF is OK):
>> 
>> draft-ietf-tcpm-rfc8312bis-15.xml(2064): Warning: Artwork too wide,
>> reducing indentation from 0 to 0
>> draft-ietf-tcpm-rfc8312bis-15.xml(1739): Warning: Artset too wide,
>> reducing indentation from 0 to 0
>> draft-ietf-tcpm-rfc8312bis-15.xml(1738): Warning: Figure too wide,
>> reducing indentation from 3 to 0
>> ...
>> draft-ietf-tcpm-rfc8312bis-15.xml(2064): Warning: Too long line found
>> (L678), 2 characters longer than 72 characters: 
>>       ⎨max(ssthresh, 2)    reduction on loss, cwnd is at least 2 MSS
>> draft-ietf-tcpm-rfc8312bis-15.xml(2064): Warning: Too long line found
>> (L679), 1 characters longer than 72 characters: 
>> cwnd =      ⎩max(ssthresh, 1)    reduction on ECE, cwnd is at least 1 MSS
>> 
>> Note:  Line numbers are approximate, due to the addition of inline
>> questions.
>> 
>> Would it be possible to update as follows?  We tested the update
>> suggested below and found that it corrects the issue in the text
>> output.  However, we do not know how to make the update in the
>> corresponding SVG.
>> 
>> Original:
>> ...
>>            ⎨max(ssthresh, 2)    reduction on loss, cwnd is at least 2 MSS
>> cwnd =      ⎩max(ssthresh, 1)    reduction on ECE, cwnd is at least 1 MSS
>> ssthresh =  max(ssthresh, 2)     ssthresh is at least 2 MSS
>> 
>> Possibly (assuming that the spacing before "(a)", "(b)", and "(c)"
>>  would not be difficult to manage in the SVG):
>> ...
>>            ⎨max(ssthresh, 2)  (a)
>> cwnd =      ⎩max(ssthresh, 1)  (b)
>> ssthresh =  max(ssthresh, 2)   (c)
>> 
>> (a)  reduction on loss, cwnd is at least 2 MSS
>> (b)  reduction on ECE, cwnd is at least 1 MSS
>> (c)  ssthresh is at least 2 MSS
>> 
>> If you would like to view the test output files (partially edited; not
>> to be used elsewhere), please see the following:
>> 
>> https://www.rfc-editor.org/authors/draft-ietf-tcpm-rfc8312bis-15-LB-test.txt
>> https://www.rfc-editor.org/authors/draft-ietf-tcpm-rfc8312bis-15-LB-test.html
>> https://www.rfc-editor.org/authors/draft-ietf-tcpm-rfc8312bis-15-LB-test.pdf -->
>> 
>> 
>> 20) <!-- [rfced] Section 4.6:  Should "more than one round-trip" be
>> "more than one round trip" or "more than one RTT"?
>> 
>> Original:
>> A side effect of setting β__cubic_ to a value bigger than 0.5 is that
>> packet loss can happen for more than one round-trip in certain cases,
>> but it can work efficiently in other cases, for example, when
>> HyStart++ is used along with CUBIC or when the sending rate is
>> limited by the application. -->
>> 
>> 
>> 21) <!-- [rfced] Sections 4.6 and 5.5:  These sentences seem to indicate
>> that ECN-Echo ACKs cause the congestion events rather than detect
>> or indicate them.  May we update as suggested, along the lines of
>> "congestion event detected by duplicate acknowledgments (ACKs)" in
>> Section 3.1?
>> 
>> Original:
>> Note that CUBIC MUST continue to reduce _cwnd_ in response to
>> congestion events due to ECN-Echo ACKs until it reaches a value of 1
>> MSS.
>> ...
>> After reducing the sending rate to one packet per RTT in
>> response to congestion events due to ECN-Echo ACKs, CUBIC then
>> exponentially increases the transmission timer for each packet
>> retransmission while congestion persists.
>> 
>> Suggested:
>> Note that CUBIC MUST continue to reduce _cwnd_ in response to
>> congestion events detected by ECN-Echo ACKs until it reaches a
>> value of 1 MSS.
>> ...
>> After reducing the sending rate to one packet per RTT in
>> response to congestion events detected by ECN-Echo ACKs, CUBIC then
>> exponentially increases the transmission timer for each packet
>> retransmission while congestion persists. -->
>> 
>> 
>> 22) <!-- [rfced] Section 4.6:  We see "retransmit timer" in RFC 3168
>> but no mention of "exponential".  Will this citation be clear to
>> readers?
>> 
>> Original (the previous sentence is included for context):
>> If congestion events indicated by ECN-Echo ACKs persist, a
>> sender with a _cwnd_ of 1 MSS MUST reduce its sending rate even
>> further.  It can achieve that by using a retransmission timer with
>> exponential backoff, as described in [RFC3168]. -->
>> 
>> 
>> 23) <!-- [rfced] Section 4.7:  xml2rfc yields the following warning
>> for the "if  cwnd < W     and fast convergence enabled," line in
>> the graphic just after the second paragraph of the section.  This
>> warning indicates that the line is too long for the text output:
>> 
>> draft-ietf-tcpm-rfc8312bis-15.xml(2402): Warning: Artwork too wide,
>> reducing indentation from 3 to 0
>> 
>> Note:  The line number is approximate, due to the addition of inline
>> questions.
>> 
>> Would it be possible to remove three spaces, as follows?  We tested
>> the update suggested below and found that it corrects the issue in
>> the text output.  However, we do not know how to make the update in
>> the corresponding SVG.
>> 
>> Original:
>> ...
>> if  cwnd < W     and fast convergence enabled,
>> 
>> Possibly:
>> if  cwnd < W  and fast convergence enabled,
>> 
>> If you would like to view the test output files (partially edited; not
>> to be used elsewhere), please see the following:
>> 
>> https://www.rfc-editor.org/authors/draft-ietf-tcpm-rfc8312bis-15-LB-test.txt
>> https://www.rfc-editor.org/authors/draft-ietf-tcpm-rfc8312bis-15-LB-test.html
>> https://www.rfc-editor.org/authors/draft-ietf-tcpm-rfc8312bis-15-LB-test.pdf -->
>> 
>> 
>> 24) <!-- [rfced] Section 4.9:  Per the "two types of spurious events"
>> sentence in this section, it appears that "spurious fast
>> retransmits" and "Spurious loss detected by acknowledgments" refer to
>> the same phenomenon.  Please confirm that this will be clear to
>> readers.
>> 
>> Original:
>> For TCP, there are two types of spurious events - spurious timeouts
>> and spurious fast retransmits.
>> ...
>> 4.9.1.  Spurious timeout
>> ...
>> 4.9.2.  Spurious loss detected by acknowledgments -->
>> 
>> 
>> 25) <!-- [rfced] Section 4.10:  Please confirm that the missing
>> underscores in the current text output will not be problematic
>> in the text output when this document is published.  The HTML and PDF
>> outputs look as expected, but the text output here is currently
>> missing one trailing underscore ("_cwnd_prior ") and one leading
>> underscore (" cwnd_").
>> 
>> Original:
>> In this special case, CUBIC sets _cwnd_prior =
>> cwnd_ and switches to congestion avoidance.
>> 
>> Should the XML be changed as follows?
>> 
>> Currently:
>> <em>cwnd<sub>prior</sub> = cwnd</em>
>> 
>> Possibly:
>> <em>cwnd<sub>prior</sub></em> = <em>cwnd</em> -->
>> 
>> 
>> 26) <!-- [rfced] Section 5.10:  Does "to the congestion control at the
>> sender" mean "to congestion control settings at the sender", "to
>> congestion control at the sender", or something else?  (In other
>> words, please clarify "the congestion control".)
>> 
>> Original:
>> CUBIC requires only changes to the congestion control at the sender,
>> and it does not require any changes at receivers. -->
>> 
>> 
>> 27) <!-- [rfced] Section 6:  This sentence was difficult to follow due to
>> comma usage.  We updated as follows.  If this is incorrect, please
>> clarify.
>> 
>> Original:
>> Specifically, changing the window computation on the
>> sender may allow an attacker, through dropping or injecting ACKs (as
>> described in [RFC5681]), to either force the CUBIC implementation to
>> reduce its bandwidth, or to convince it that there is no congestion
>> when congestion does exist, and use the CUBIC implementation as an
>> attack vector against other hosts.
>> 
>> Currently:
>> Specifically, changing the window computation on the
>> sender may allow an attacker, through dropping or injecting ACKs (as
>> described in [RFC5681]), to either force the CUBIC implementation to
>> reduce its bandwidth or convince it that there is no congestion when
>> congestion does exist, and to use the CUBIC implementation as an
>> attack vector against other hosts. -->
>> 
>> 
>> 28) <!--[rfced] For the following reference, would it be easier for the
>> reader if a direct link was provided to the technical report
>> instead of a link to the gzip file?  We found that the report at
>> <https://www.cs.utexas.edu/ftp/techreports/tr02-39.pdf> only
>> provides the Introduction.  Please let us know if you would like
>> to leave the URL as is or use a direct URL that points to the
>> complete report (note that the complete report can be accessed
>> directly here: https://citeseerx.ist.psu.edu/document?repid=
>> rep1&type=pdf&doi=1828bdcef118b02d3996b8e00b8aaa92b50abb0f).
>> 
>> Original:
>> [GV02]     Gorinsky, S. and H. Vin, "Extended Analysis of Binary
>>                 Adjustment Algorithms", Technical Report TR2002-29,
>>                 Department of Computer Sciences, The University of
>>                 Texas at Austin, 11 August 2002,
>>                 <https://www.cs.utexas.edu/ftp/techreports/tr02-39.ps.gz>.  -->
>> 
>> 
>> 29) <!-- [rfced] Original Appendices B.20 and B.21 (now Appendices A.1
>> and A.2):  The current Appendix A.1 does not appear to contain any
>> relevant information beyond what is already provided in the Abstract
>> and Introduction (i.e., moving to the Standards Track), and it does
>> not seem relevant to the evolution of CUBIC.  May we remove this
>> section?
>> 
>> Also, should "differences between the original paper and [RFC8312]"
>> be "differences between the original paper, [RFC8312], and this
>> document"?
>> 
>> Original:
>> Appendix B.  Evolution of CUBIC
>> 
>> B.1.  Since draft-ietf-tcpm-rfc8312bis-14
>> ...
>> B.20.  Since RFC8312
>> 
>>    *  converted to Markdown and xml2rfc v3
>> 
>>    *  updated references (as part of the conversion)
>> 
>>    *  updated author information
>> 
>>    *  various formatting changes
>> 
>>    *  move to Standards Track
>> ...
>> B.21.  Since the Original Paper
>> 
>>    CUBIC has gone through a few changes since the initial release
>>    [HRX08] of its algorithm and implementation.  This section highlights
>>    the differences between the original paper and [RFC8312].
>> 
>> Possibly:
>> Appendix A.  Evolution of CUBIC since the Original Paper -->
>> 
>> 
>> 30) <!-- [rfced] Original Appendix B.21 (currently Appendix A.2):
>> 
>> a) Although we see "CUBIC multiplication decrease factor" on Page 6
>> of RFC 8312, we see "CUBIC Decrease Factor" (title of Section 3.4),
>> "multiplicative window decrease factor", and "CUBIC multiplicative
>> decrease factor" used elsewhere in this document.
>> 
>> RFC 8312 also uses "multiplicative window decrease factor" and
>> "multiplicative decrease factor" in its text.
>> 
>> Should these distinctions be explained for readers?
>> 
>> Original:
>> For example, beta__cubic_ in the original paper was the window
>> decrease constant while [RFC8312] changed it to CUBIC
>> multiplication decrease factor.
>> 
>> b) "beta__cubic_ * _W_max_" was difficult for us to find in
>> RFC 8312.  Will readers easily find this equation, or would it
>> be helpful to change it to "_W_max*β__cubic", per
>> "W_max*beta_cubic" (Sections 4.1 and 4.2 of RFC 8312)?
>> 
>> Original:
>> With this change, the current
>> congestion window size after a congestion event in [RFC8312] was
>> beta__cubic_ * _W_max_ while it was (1-beta__cubic_) * _W_max_ in
>> the original paper. -->
>> 
>> 
>> 31) <!-- [rfced] Appendix C:  Does "substituting _K_ with Figure 12 in
>> Figure 9" mean "substituting _K_ from Figure 9 with _K_ from
>> Figure 12" or something else?  Please clarify.
>> 
>> Original (the period (".") has been added to the end of the sentence):
>> The average CUBIC window size _AVG_W_cubic_ can be obtained by
>> substituting _K_ with Figure 12 in Figure 9 -->
>> 
>> 
>> 32) <!-- [rfced] Acknowledgments:  We found this comment at the end of
>> the section in the XML file:  "Anyone else to acknowledge?"
>> Please let us know if other names should be added. -->
>> 
>> 
>> 33) <!-- [rfced] Please review the "Inclusive Language" portion of the
>> online Style Guide at
>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
>> and let us know if any changes are needed.
>> 
>> Note that our script did not flag any words in particular, but this
>> should still be reviewed as a best practice. -->
>> 
>> 
>> 34) <!-- [rfced] Please let us know if any changes are needed for the
>> following:
>> 
>> a) The following terms were used inconsistently in this document.
>> We chose to use the latter forms.  Please let us know any objections.
>> 
>> Fast Convergence / fast convergence (per RFC 8312 and per more
>>   common usage in post-6000 published RFCs)
>> 
>> RTT fairness / RTT-fairness (per RFC 8312; also per
>>   "TCP-friendliness" in RFC 8312)
>> 
>> b) Please let us know how/if the following should be made consistent:
>> 
>> 1-β / 1 - β
>>   (Please note that if you wish to make changes, we will need
>>   you to update the SVG as applicable.)
>> 
>> e-02 / e-2
>>   (For example, "1.0e-02" vs. "2.0e-2" in Tables 2 and 3, respectively) -->
>> 
>> 
>> Thank you.
>> 
>> RFC Editor/lb/kc
>> 
>> 
>> On Jun 21, 2023, at 5:16 PM, [e-mail] wrote:
>> 
>> *****IMPORTANT*****
>> 
>> Updated 2023/06/21
>> 
>> RFC Author(s):
>> --------------
>> 
>> Instructions for Completing AUTH48
>> 
>> Your document has now entered AUTH48.  Once it has been reviewed and 
>> approved by you and all coauthors, it will be published as an RFC.  
>> If an author is no longer available, there are several remedies 
>> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>> 
>> You and you coauthors are responsible for engaging other parties 
>> (e.g., Contributors or Working Group) as necessary before providing 
>> your approval.
>> 
>> Planning your review 
>> ---------------------
>> 
>> Please review the following aspects of your document:
>> 
>> *  RFC Editor questions
>> 
>>  Please review and resolve any questions raised by the RFC Editor 
>>  that have been included in the XML file as comments marked as 
>>  follows:
>> 
>>  <!-- [rfced] ... -->
>> 
>>  These questions will also be sent in a subsequent email.
>> 
>> *  Changes submitted by coauthors 
>> 
>>  Please ensure that you review any changes submitted by your 
>>  coauthors.  We assume that if you do not speak up that you 
>>  agree to changes submitted by your coauthors.
>> 
>> *  Content 
>> 
>>  Please review the full content of the document, as this cannot 
>>  change once the RFC is published.  Please pay particular attention to:
>>  - IANA considerations updates (if applicable)
>>  - contact information
>>  - references
>> 
>> *  Copyright notices and legends
>> 
>>  Please review the copyright notice and legends as defined in
>>  RFC 5378 and the Trust Legal Provisions 
>>  (TLP – https://trustee.ietf.org/license-info/).
>> 
>> *  Semantic markup
>> 
>>  Please review the markup in the XML file to ensure that elements of  
>>  content are correctly tagged.  For example, ensure that <sourcecode> 
>>  and <artwork> are set correctly.  See details at 
>>  <https://authors.ietf.org/rfcxml-vocabulary>.
>> 
>> *  Formatted output
>> 
>>  Please review the PDF, HTML, and TXT files to ensure that the 
>>  formatted output, as generated from the markup in the XML file, is 
>>  reasonable.  Please note that the TXT will have formatting 
>>  limitations compared to the PDF and HTML.
>> 
>> 
>> Submitting changes
>> ------------------
>> 
>> To submit changes, please reply to this email using ‘REPLY ALL’ as all 
>> the parties CCed on this message need to see your changes. The parties 
>> include:
>> 
>>  *  your coauthors
>> 
>>  *  [e-mail] (the RPC team)
>> 
>>  *  other document participants, depending on the stream (e.g., 
>>     IETF Stream participants are your working group chairs, the 
>>     responsible ADs, and the document shepherd).
>> 
>>  *  [e-mail], which is a new archival mailing list 
>>     to preserve AUTH48 conversations; it is not an active discussion 
>>     list:
>> 
>>    *  More info:
>>       https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>> 
>>    *  The archive itself:
>>       https://mailarchive.ietf.org/arch/browse/auth48archive/
>> 
>>    *  Note: If only absolutely necessary, you may temporarily opt out 
>>       of the archiving of messages (e.g., to discuss a sensitive matter).
>>       If needed, please add a note at the top of the message that you 
>>       have dropped the address. When the discussion is concluded, 
>>       [e-mail] will be re-added to the CC list and 
>>       its addition will be noted at the top of the message. 
>> 
>> You may submit your changes in one of two ways:
>> 
>> An update to the provided XML file
>> — OR —
>> An explicit list of changes in this format
>> 
>> Section # (or indicate Global)
>> 
>> OLD:
>> old text
>> 
>> NEW:
>> new text
>> 
>> You do not need to reply with both an updated XML file and an explicit 
>> list of changes, as either form is sufficient.
>> 
>> We will ask a stream manager to review and approve any changes that seem
>> beyond editorial in nature, e.g., addition of new text, deletion of text, 
>> and technical changes.  Information about stream managers can be found in 
>> the FAQ.  Editorial changes do not require approval from a stream manager.
>> 
>> 
>> Approving for publication
>> --------------------------
>> 
>> To approve your RFC for publication, please reply to this email stating
>> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
>> as all the parties CCed on this message need to see your approval.
>> 
>> 
>> Files 
>> -----
>> 
>> The files are available here:
>>  https://www.rfc-editor.org/authors/rfc9438.xml
>>  https://www.rfc-editor.org/authors/rfc9438.html
>>  https://www.rfc-editor.org/authors/rfc9438.pdf
>>  https://www.rfc-editor.org/authors/rfc9438.txt
>> 
>> Diff file of the text:
>>  https://www.rfc-editor.org/authors/rfc9438-diff.html
>>  https://www.rfc-editor.org/authors/rfc9438-rfcdiff.html (side by side)
>> 
>> Diff of the XML: 
>>  https://www.rfc-editor.org/authors/rfc9438-xmldiff1.html
>> 
>> XMLv3 file that is a best effort to capture v3-related format updates 
>> only: 
>>  https://www.rfc-editor.org/authors/rfc9438.form.xml
>> 
>> 
>> Tracking progress
>> -----------------
>> 
>> The details of the AUTH48 status of your document are here:
>>  https://www.rfc-editor.org/auth48/rfc9438
>> 
>> Please let us know if you have any questions.  
>> 
>> Thank you for your cooperation,
>> 
>> RFC Editor
>> 
>> --------------------------------------
>> RFC9438 (draft-ietf-tcpm-rfc8312bis-15)
>> 
>> Title            : CUBIC for Fast and Long-Distance Networks
>> Author(s)        : L. Xu, S. Ha, I. Rhee, V. Goel, L. Eggert, Ed.
>> WG Chair(s)      : Yoshifumi Nishida, Michael Tüxen, Ian Swett
>> 
>> Area Director(s) : Martin Duke, Zaheduzzaman Sarker
>> 
>> 
>> 
>