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

[Lisong Xu <[e-mail]>]

Thank you very much for all the suggestions! We will revise the document and get back to you as early as possible.
Lisong
________________________________
From: [e-mail] <[e-mail]>
Sent: Wednesday, June 21, 2023 7:19 PM
To: Lisong Xu <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: AUTH48: RFC-to-be 9438 <draft-ietf-tcpm-rfc8312bis-15> for your review

Non-NU Email

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://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid4068__;!!PvXuogZ4sRB2p-tU!BXXBKQt3Vc1ASshIM9uDx4wonvLFZGVRFsKHQFO65LZCDgzvqF-GEwRKuF9meJyPevIQwoTKXvHNzUsXnR4$ ) 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://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!PvXuogZ4sRB2p-tU!BXXBKQt3Vc1ASshIM9uDx4wonvLFZGVRFsKHQFO65LZCDgzvqF-GEwRKuF9meJyPevIQwoTKXvHN_1nYtkc$  for more information.) -->


3) <!-- [rfced] Please insert any keywords (beyond those that appear in the
title) for use on <https://urldefense.com/v3/__https://www.rfc-editor.org/search__;!!PvXuogZ4sRB2p-tU!BXXBKQt3Vc1ASshIM9uDx4wonvLFZGVRFsKHQFO65LZCDgzvqF-GEwRKuF9meJyPevIQwoTKXvHNCZKd7Jc$ >. -->


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://urldefense.com/v3/__https://github.com/cabo/kramdown-rfc/issues/196__;!!PvXuogZ4sRB2p-tU!BXXBKQt3Vc1ASshIM9uDx4wonvLFZGVRFsKHQFO65LZCDgzvqF-GEwRKuF9meJyPevIQwoTKXvHNP9mRUp4$ > 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/draft-ietf-tcpm-rfc8312bis-15-LB-test.txt__;!!PvXuogZ4sRB2p-tU!BXXBKQt3Vc1ASshIM9uDx4wonvLFZGVRFsKHQFO65LZCDgzvqF-GEwRKuF9meJyPevIQwoTKXvHNQcPA4Uw$
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/draft-ietf-tcpm-rfc8312bis-15-LB-test.html__;!!PvXuogZ4sRB2p-tU!BXXBKQt3Vc1ASshIM9uDx4wonvLFZGVRFsKHQFO65LZCDgzvqF-GEwRKuF9meJyPevIQwoTKXvHNkDh8lcU$
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/draft-ietf-tcpm-rfc8312bis-15-LB-test.pdf__;!!PvXuogZ4sRB2p-tU!BXXBKQt3Vc1ASshIM9uDx4wonvLFZGVRFsKHQFO65LZCDgzvqF-GEwRKuF9meJyPevIQwoTKXvHNp-CBCak$  -->


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://urldefense.com/v3/__https://www.rfc-editor.org/authors/draft-ietf-tcpm-rfc8312bis-15-LB-test.txt__;!!PvXuogZ4sRB2p-tU!BXXBKQt3Vc1ASshIM9uDx4wonvLFZGVRFsKHQFO65LZCDgzvqF-GEwRKuF9meJyPevIQwoTKXvHNQcPA4Uw$
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/draft-ietf-tcpm-rfc8312bis-15-LB-test.html__;!!PvXuogZ4sRB2p-tU!BXXBKQt3Vc1ASshIM9uDx4wonvLFZGVRFsKHQFO65LZCDgzvqF-GEwRKuF9meJyPevIQwoTKXvHNkDh8lcU$
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/draft-ietf-tcpm-rfc8312bis-15-LB-test.pdf__;!!PvXuogZ4sRB2p-tU!BXXBKQt3Vc1ASshIM9uDx4wonvLFZGVRFsKHQFO65LZCDgzvqF-GEwRKuF9meJyPevIQwoTKXvHNp-CBCak$  -->


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://urldefense.com/v3/__https://www.cs.utexas.edu/ftp/techreports/tr02-39.pdf__;!!PvXuogZ4sRB2p-tU!BXXBKQt3Vc1ASshIM9uDx4wonvLFZGVRFsKHQFO65LZCDgzvqF-GEwRKuF9meJyPevIQwoTKXvHN064dpsE$ > 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://urldefense.com/v3/__https://citeseerx.ist.psu.edu/document?repid=__;!!PvXuogZ4sRB2p-tU!BXXBKQt3Vc1ASshIM9uDx4wonvLFZGVRFsKHQFO65LZCDgzvqF-GEwRKuF9meJyPevIQwoTKXvHNwI6hp1E$
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://urldefense.com/v3/__https://www.cs.utexas.edu/ftp/techreports/tr02-39.ps.gz__;!!PvXuogZ4sRB2p-tU!BXXBKQt3Vc1ASshIM9uDx4wonvLFZGVRFsKHQFO65LZCDgzvqF-GEwRKuF9meJyPevIQwoTKXvHNv3_jQ8M$ >.  -->


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://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*inclusive_language__;Iw!!PvXuogZ4sRB2p-tU!BXXBKQt3Vc1ASshIM9uDx4wonvLFZGVRFsKHQFO65LZCDgzvqF-GEwRKuF9meJyPevIQwoTKXvHNLk-oINE$ >,
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://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!PvXuogZ4sRB2p-tU!BXXBKQt3Vc1ASshIM9uDx4wonvLFZGVRFsKHQFO65LZCDgzvqF-GEwRKuF9meJyPevIQwoTKXvHNaL35Lp8$ ).

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://urldefense.com/v3/__https://trustee.ietf.org/license-info/__;!!PvXuogZ4sRB2p-tU!BXXBKQt3Vc1ASshIM9uDx4wonvLFZGVRFsKHQFO65LZCDgzvqF-GEwRKuF9meJyPevIQwoTKXvHNzYCF4xc$ ).

*  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://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!PvXuogZ4sRB2p-tU!BXXBKQt3Vc1ASshIM9uDx4wonvLFZGVRFsKHQFO65LZCDgzvqF-GEwRKuF9meJyPevIQwoTKXvHNPi78F-0$ >.

*  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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!PvXuogZ4sRB2p-tU!BXXBKQt3Vc1ASshIM9uDx4wonvLFZGVRFsKHQFO65LZCDgzvqF-GEwRKuF9meJyPevIQwoTKXvHNMc-McEg$

    *  The archive itself:
       https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!PvXuogZ4sRB2p-tU!BXXBKQt3Vc1ASshIM9uDx4wonvLFZGVRFsKHQFO65LZCDgzvqF-GEwRKuF9meJyPevIQwoTKXvHNEfeauP4$

    *  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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9438.xml__;!!PvXuogZ4sRB2p-tU!BXXBKQt3Vc1ASshIM9uDx4wonvLFZGVRFsKHQFO65LZCDgzvqF-GEwRKuF9meJyPevIQwoTKXvHNiWrqgug$
  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9438.html__;!!PvXuogZ4sRB2p-tU!BXXBKQt3Vc1ASshIM9uDx4wonvLFZGVRFsKHQFO65LZCDgzvqF-GEwRKuF9meJyPevIQwoTKXvHNsZcvtIk$
  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9438.pdf__;!!PvXuogZ4sRB2p-tU!BXXBKQt3Vc1ASshIM9uDx4wonvLFZGVRFsKHQFO65LZCDgzvqF-GEwRKuF9meJyPevIQwoTKXvHN7xdu-Kk$
  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9438.txt__;!!PvXuogZ4sRB2p-tU!BXXBKQt3Vc1ASshIM9uDx4wonvLFZGVRFsKHQFO65LZCDgzvqF-GEwRKuF9meJyPevIQwoTKXvHNmcb4sVI$

Diff file of the text:
  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9438-diff.html__;!!PvXuogZ4sRB2p-tU!BXXBKQt3Vc1ASshIM9uDx4wonvLFZGVRFsKHQFO65LZCDgzvqF-GEwRKuF9meJyPevIQwoTKXvHNxgvIthk$
  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9438-rfcdiff.html__;!!PvXuogZ4sRB2p-tU!BXXBKQt3Vc1ASshIM9uDx4wonvLFZGVRFsKHQFO65LZCDgzvqF-GEwRKuF9meJyPevIQwoTKXvHN1x38iAE$  (side by side)

Diff of the XML:
  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9438-xmldiff1.html__;!!PvXuogZ4sRB2p-tU!BXXBKQt3Vc1ASshIM9uDx4wonvLFZGVRFsKHQFO65LZCDgzvqF-GEwRKuF9meJyPevIQwoTKXvHNhCl_2rE$

XMLv3 file that is a best effort to capture v3-related format updates
only:
  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9438.form.xml__;!!PvXuogZ4sRB2p-tU!BXXBKQt3Vc1ASshIM9uDx4wonvLFZGVRFsKHQFO65LZCDgzvqF-GEwRKuF9meJyPevIQwoTKXvHN8G3GUE0$


Tracking progress
-----------------

The details of the AUTH48 status of your document are here:
  https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9438__;!!PvXuogZ4sRB2p-tU!BXXBKQt3Vc1ASshIM9uDx4wonvLFZGVRFsKHQFO65LZCDgzvqF-GEwRKuF9meJyPevIQwoTKXvHNjSTJzGk$

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