Re: [auth48] [EXTERNAL] AUTH48: RFC-to-be 9406 <draft-ietf-tcpm-hystartplusplus-14> for your review

[Lynne Bartholomew <[e-mail]>]

Hi, Yi.  Thank you for your prompt reply!

We have updated this document per your notes below.

A couple quick follow-up items for you:

It appears that our question 4)b) (re. not finding "cssBaselineMinRtt" mentioned in any other RFC) was answered by this reply to question 5):

>> 5) <!-- [rfced] Section 4.2:  We defined "ECN" as "Explicit Congestion
>> Notification" for ease of the reader.  If this definition is
>> incorrect, please provide the correct definition of "ECN".
>> 
>> Original:
>>  If loss or ECN-marking is observed anytime during standard slow start
>>  or CSS, enter congestion avoidance by setting ssthresh to current
>>  cwnd.
>> 
>> Currently:
>>  If loss or Explicit Congestion Notification (ECN) marking is observed
>>  at any time during standard slow start or CSS, enter congestion
>>  avoidance by setting the ssthresh to the current cwnd. -->
> 
> It's referred a few paragraphs below.
> 
> In "For CSS rounds where at least N_RTT_SAMPLE RTT samples have been obtained, check if current round's minRTT drops below baseline indicating that HyStart exit was spurious:", the word, "baseline" refers to cssBaselineMinRtt. I suggest we change the line to "For CSS rounds where at least N_RTT_SAMPLE RTT samples have been obtained, check if current round's minRTT drops below the baseline, cssBaselineMinRtt, indicating that HyStart exit was spurious:"?

First, apologies for not spotting this earlier and asking about it:  Should "HyStart exit" be "HyStart++ exit"?

Second, please let us know if our expansion of "ECN" as "Explicit Congestion Notification" is correct.  If it's not correct, please let us know how it should be defined.

= = = = =

The latest files are posted here (please refresh your browser):

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

   https://www.rfc-editor.org/authors/rfc9406-alt-diff.html
   https://www.rfc-editor.org/authors/rfc9406-xmldiff1.html
   https://www.rfc-editor.org/authors/rfc9406-xmldiff2.html
   https://www.rfc-editor.org/authors/rfc9406-alt-diff.html

Thanks again!

RFC Editor/lb

> On Apr 28, 2023, at 8:54 PM, Yi Huang <[e-mail]> wrote:
> 
> Hi Lynne,
> 
> Thanks a lot for reviewing and editing the doc. I have inlined our answers.
> 
> Thanks,
> Yi
> 
> 
> From: Lynne Bartholomew <[e-mail]>
> Sent: Thursday, April 27, 2023 3:22 PM
> To: [e-mail] <[e-mail]>; Yi Huang <[e-mail]>; Matt Olson <[e-mail]>
> Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail]<[e-mail]>; Martin Duke <[e-mail]>; [e-mail] <[e-mail]>
> Subject: [EXTERNAL] Re: AUTH48: RFC-to-be 9406 <draft-ietf-tcpm-hystartplusplus-14> for your review
>  [Some people who received this message don't often get email from [e-mail]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> Authors,
> 
> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
> 
> 1) <!-- [rfced] Document title, Abstract, and Introduction:  As the term
> "HyStart" has not been used in any published RFCs to date and the
> word "hybrid" is not used in this document, would it be helpful to
> define HyStart++ for readers?
> 
> Original:
>  HyStart++: Modified Slow Start for TCP
> ...
>  This document describes HyStart++, a simple modification to the slow
>  start phase of congestion control algorithms.
> ...
>  HyStart++ uses increase in round-trip delay as a signal to exit slow
>  start before potential packet loss occurs as a result of overshoot.
>  This is one of two algorithms specified in [HyStart].
> 
> Perhaps:
>  HyStart++: Modified "Hybrid Start" Slow Start Algorithm for TCP
> ...
>  This document describes HyStart++, a simple modification to the
>  "Hybrid Start" slow start phase of congestion control algorithms.
> ...
>  HyStart++, which is a modified "Hybrid Start" slow start algorithm,
>  uses an increase in round-trip delay as a signal to exit slow
>  start before potential packet loss occurs as a result of
>  overshoot.  This is one of two algorithms specified in [HyStart]. -->
> 
> How about in the introduction we modify seocnd para as:
> HyStart++ builds upon Hybrid Start (HyStart) originally described in [HyStart]. HyStart++ uses increase in round-trip delay as a signal to exit slow start before potential packet loss occurs as a result of overshoot.
> 
> 
> 2) <!-- [rfced] Section 1:  In this current text, "This is one of two
> algorithms" appears to refer to HyStart++.  However, we do not see
> HyStart++ mentioned anywhere in [HyStart].  Also, we only see one
> algorithm defined in [HyStart]:  "We propose a new slow start
> algorithm, called Hybrid Start (HyStart) ...").
> 
> How can this text be clarified for readers?  For example, would
> "[HyStart] specifies two algorithms (a "Delay Increase" algorithm and
> an "Inter-Packet Arrival" algorithm) to be run in parallel to detect
> that the sending rate has reached capacity" from Section 4.1 also
> apply to this text here in Section 1?
> 
> Original (the previous sentence and the next sentence are included
>    for context):
>  HyStart++ uses increase in round-trip delay as a signal to exit slow
>  start before potential packet loss occurs as a result of overshoot.
>  This is one of two algorithms specified in [HyStart].  After the slow
>  start exit, a new Conservative Slow Start (CSS) phase is used to
>  determine whether the slow start exit was premature and to resume
>  slow start. -->
> 
> To be clear, Hystart++ itself is not mentioned in [HyStart]. Hystart++ uses the "delay increase" algorithm in [Hystart] for detecting a safe exit point for slow start. Can we just rephrase " This is one of two algorithms specified in [HyStart]" to "This is one of two algorithms specified in [HyStart] for finding a safe exit point for slow start."?
> 
> 3) <!-- [rfced] Please review the "type" attribute of each sourcecode
> element in the XML file to ensure correctness.  If you would like to
> make any changes and the current list of preferred values for "type"
> as listed on <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fmaterials%2Fsourcecode-types.txt&data=05%7C01%7Chuanyi%40microsoft.com%7C73de45faeaf34e130dc408db476df1e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638182309821549529%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ZHxQm5SgbEgqu3gKQ%2B%2B2btvwFYM4BRf7xXaQ8do6ng8%3D&reserved=0>
> does not contain an applicable type, then feel free to let us know.
> Also, it is acceptable to leave the "type" attribute not set. -->
> 
> Can we just not set the "type" attribute? The pseudocode doesn't map to a real programming language.
> 
> 4) <!-- [rfced] Section 4.2:
> 
> a) The following two lines are too long for the text output.  We get
> the following warning:
> 
> Warning: Too long line found (L207), 7 characters longer than 72 characters:
>      Compute an RTT Threshold clamped between MIN_RTT_THRESH and MAX_RTT_THRESH
> Warning: Too long line found (L208), 20 characters longer than 72 characters:
>      RttThresh = max(MIN_RTT_THRESH, min(lastRoundMinRTT / MIN_RTT_DIVISOR, MAX_RTT_THRESH))
> 
> Please let us know where line breaks should be placed.
> 
> Original (the line break after "DIVISOR," is introduced by
>   our Terminal-window-line-length constraint):
>  Compute a RTT Threshold clamped between MIN_RTT_THRESH and MAX_RTT_THRESH
>  RttThresh = max(MIN_RTT_THRESH, min(lastRoundMinRTT / MIN_RTT_DIVISOR, MAX_RTT_THRESH))
> 
> Possibly:
>  Compute an RTT Threshold clamped between MIN_RTT_THRESH and
>    MAX_RTT_THRESH
>  RttThresh = max(MIN_RTT_THRESH,
>    min(lastRoundMinRTT / MIN_RTT_DIVISOR, MAX_RTT_THRESH))
> 
> b) We do not see "cssBaselineMinRtt" used in any RFC.  Will this
> parameter be clear to readers?
> 
> Original:
>  cssBaselineMinRtt = currentRoundMinRTT
> ...
>  if (currentRoundMinRTT < cssBaselineMinRtt)
>    cssBaselineMinRtt = infinity -->
> 
> I think we can remove "Compute an RTT Threshold clamped between MIN_RTT_THRESH and MAX_RTT_THRESH" as it's just an explanation of the following line, which is clear enough. The suggested line break looks good to me.
> 
> 5) <!-- [rfced] Section 4.2:  We defined "ECN" as "Explicit Congestion
> Notification" for ease of the reader.  If this definition is
> incorrect, please provide the correct definition of "ECN".
> 
> Original:
>  If loss or ECN-marking is observed anytime during standard slow start
>  or CSS, enter congestion avoidance by setting ssthresh to current
>  cwnd.
> 
> Currently:
>  If loss or Explicit Congestion Notification (ECN) marking is observed
>  at any time during standard slow start or CSS, enter congestion
>  avoidance by setting the ssthresh to the current cwnd. -->
> 
> It's referred a few paragraphs below.
> 
> In "For CSS rounds where at least N_RTT_SAMPLE RTT samples have been obtained, check if current round's minRTT drops below baseline indicating that HyStart exit was spurious:", the word, "baseline" refers to cssBaselineMinRtt. I suggest we change the line to "For CSS rounds where at least N_RTT_SAMPLE RTT samples have been obtained, check if current round's minRTT drops below the baseline, cssBaselineMinRtt, indicating that HyStart exit was spurious:"?
> 
> 6) <!-- [rfced] Section 5:  We changed "As of February 2023" to "At the
> time of this writing".  If this is incorrect, please provide
> clarifying text.
> 
> Original:
>  As of February 2023, HyStart++ as described in this document has been
>  default enabled for all TCP connections in the Windows operating
>  system for over two years with pacing disabled and an actual L = 8.
> 
> Currently:
>  At the time of this writing, HyStart++ as described in this document
>  has been default enabled for all TCP connections in the Windows
>  operating system for over two years with pacing disabled and an
>  actual L = 8. -->
> Correct
> 
> 
> 7) <!-- [rfced] Section 5:  Will the meaning of "HyStart++ draft 01" be
> clear to readers?  If not, please provide clarifying text.
> 
> Original:
>  In an A/B test where we compare HyStart++ draft 01 to traditional
>  slow start across a large Windows device population, out of 52
>  billion TCP connections, 0.7% of connections move from 1 RTO to 0
>  RTOs and another 0.7% connections move from 2 RTOs to 1 RTO with
>  HyStart++. -->
> 
> I would say we remove draft 01, as its not useful to the reader to implement an earlier version of the algorithm:
> 
> "In an A/B test where we compared an implementation of HyStart++ (based on an earlier draft of this document) to traditional
>  slow start across a large Windows device population,"
> 
> 8) <!-- [rfced] Please review the "Inclusive Language" portion of the
> online Style Guide at
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7C01%7Chuanyi%40microsoft.com%7C73de45faeaf34e130dc408db476df1e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638182309821549529%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=982ERXWUABgjaW%2BQGKjEcWi%2BpeBtYjpA1RB6B3uhZFw%3D&reserved=0>,
> and let us know if any changes are needed.
> 
> In addition, please consider whether "traditional" should be updated
> for clarity.  In this document, could "standard slow start" (as seen
> in Section 4.2) be used instead of "traditional slow start"?
> 
> While the NIST website
> (<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.nist.gov%2Fnist-research-library%2Fnist-technical-series-publications-author-instructions%23table1&data=05%7C01%7Chuanyi%40microsoft.com%7C73de45faeaf34e130dc408db476df1e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638182309821549529%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=nlBhIy3XhAP4uwZNmZewQdHsGnAWBlHMheEYrpp5OOE%3D&reserved=0>)
> indicates that this term is potentially biased, it is also ambiguous.
> "Tradition" is a subjective term, as it is not the same for everyone. -->
> 
> Agreed. Standard slow start is better.
> 
> 9) <!-- [rfced] The following terms were used inconsistently in this
> document.  We chose to use the latter forms.  Please let us know any
> objections.
> 
>  Hystart++ (6 instances) / HyStart++ (23 instances) (per [HyStart])
>  INFINITY (1 instance) / infinity (11 instances) -->
> 
> The latter forms are better, HyStart++ and infinity.
> 
> Thank you.
> 
> RFC Editor/lb
> 
> > On Apr 27, 2023, at 3:12 PM, [e-mail] wrote:
> >
> > *****IMPORTANT*****
> >
> > Updated 2023/04/27
> >
> > 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ffaq%2F&data=05%7C01%7Chuanyi%40microsoft.com%7C73de45faeaf34e130dc408db476df1e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638182309821549529%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=LXK%2Fpal2bI1pqYsUpbaUNEKD%2BXmsb3B6tf0S2b0kC48%3D&reserved=0).
> >
> > 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustee.ietf.org%2Flicense-info%2F&data=05%7C01%7Chuanyi%40microsoft.com%7C73de45faeaf34e130dc408db476df1e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638182309821549529%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=fJ9nlsPh7xgRTsdyOFA%2BD1sMjgYnLXbkh%2Br8DV9iTmU%3D&reserved=0).
> >
> > *  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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthors.ietf.org%2Frfcxml-vocabulary&data=05%7C01%7Chuanyi%40microsoft.com%7C73de45faeaf34e130dc408db476df1e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638182309821549529%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=j8JycJ0VUQSFORiTU3gF58fUv5rasu3kG2FMY6c8%2FS0%3D&reserved=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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2USxIAe6P8O4Zc&data=05%7C01%7Chuanyi%40microsoft.com%7C73de45faeaf34e130dc408db476df1e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638182309821549529%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=hJYA4G2%2FHmlAnyZM00rh3B2P5ATQODYAYz8m2K45msM%3D&reserved=0
> >
> >     *  The archive itself:
> >        https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C01%7Chuanyi%40microsoft.com%7C73de45faeaf34e130dc408db476df1e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638182309821549529%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=f%2BChoG67GMTUZT9s%2F27E3XvrHA%2Bjh9oq%2FGLQDgnYqAo%3D&reserved=0
> >
> >     *  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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9406.xml&data=05%7C01%7Chuanyi%40microsoft.com%7C73de45faeaf34e130dc408db476df1e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638182309821549529%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=U3kUXZ0eHEDhoFvGjz84%2BKlyRlsiza8grmWfm0KzF%2FY%3D&reserved=0
> >   https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9406.html&data=05%7C01%7Chuanyi%40microsoft.com%7C73de45faeaf34e130dc408db476df1e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638182309821549529%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=x7%2FdUttnUgxSov6%2BZYVY5C95lYrqY40NMpYzRmh1mJo%3D&reserved=0
> >   https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9406.pdf&data=05%7C01%7Chuanyi%40microsoft.com%7C73de45faeaf34e130dc408db476df1e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638182309821549529%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=WudsxQfxgyuZnyGwBdWgVJq83DHNRUs4EyetvCy0aoM%3D&reserved=0
> >   https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9406.txt&data=05%7C01%7Chuanyi%40microsoft.com%7C73de45faeaf34e130dc408db476df1e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638182309821549529%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=DyAzGd%2BYpW0HB%2FyNe1bAG3msNFyluGTRx0ZkSq4fGUY%3D&reserved=0
> >
> > Diff files of the text:
> >   https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9406-diff.html&data=05%7C01%7Chuanyi%40microsoft.com%7C73de45faeaf34e130dc408db476df1e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638182309821549529%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=TFjSioC0V%2BLtH947ayiNEihLky4IlXisbqq2tlc46qc%3D&reserved=0
> >   https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9406-rfcdiff.html&data=05%7C01%7Chuanyi%40microsoft.com%7C73de45faeaf34e130dc408db476df1e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638182309821549529%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=TdmwiA3bAIUS9SljCALieGD%2FTMqNaQtzQH3VJrEXvNY%3D&reserved=0 (side by side)
> >
> > For your convenience, we have also created an alt-diff file that will allow you to
> > more easily view changes where text has been deleted or moved:
> >   https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9406-alt-diff.html&data=05%7C01%7Chuanyi%40microsoft.com%7C73de45faeaf34e130dc408db476df1e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638182309821549529%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=m11A7UHM4rb%2FR%2F0a4lfdK5xH%2BE5WBfrUdwGf7Xub7Pk%3D&reserved=0
> >
> > Diffs of the XML:
> >   https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9406-xmldiff1.html&data=05%7C01%7Chuanyi%40microsoft.com%7C73de45faeaf34e130dc408db476df1e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638182309821549529%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ugDlvcNCgDY63hwykdojY%2B%2BodSXWxjGlRXx0eEygCF8%3D&reserved=0
> >   https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9406-xmldiff2.html&data=05%7C01%7Chuanyi%40microsoft.com%7C73de45faeaf34e130dc408db476df1e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638182309821705745%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=MzyUG3hxeQGQOfr7wi5RMLj7SulPS%2Fnr6%2FwAbr%2Fjt8Q%3D&reserved=0
> >
> > The following files are provided to facilitate creation of your own
> > diff files of the XML.
> >
> > Initial XMLv3 created using XMLv2 as input:
> >   https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9406.original.v2v3.xml&data=05%7C01%7Chuanyi%40microsoft.com%7C73de45faeaf34e130dc408db476df1e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638182309821705745%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2F3dDWqUzElWbxSfX7GlwijCLg27bmEKiLOfp2R%2BisHI%3D&reserved=0
> >
> > XMLv3 file that is a best effort to capture v3-related format updates
> > only:
> >   https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9406.form.xml&data=05%7C01%7Chuanyi%40microsoft.com%7C73de45faeaf34e130dc408db476df1e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638182309821705745%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=3cABJdh5BCwlFFVX9WajpB%2F5LuivZq9nPQbIs2Gd2kE%3D&reserved=0
> >
> >
> > Tracking progress
> > -----------------
> >
> > The details of the AUTH48 status of your document are here:
> >   https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9406&data=05%7C01%7Chuanyi%40microsoft.com%7C73de45faeaf34e130dc408db476df1e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638182309821705745%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=DY%2Few5kQ4cAVvhBYzoCsIvWDTqoPFOnUkzA7X1aP15s%3D&reserved=0
> >
> > Please let us know if you have any questions.
> >
> > Thank you for your cooperation.
> >
> > RFC Editor
> >
> > --------------------------------------
> > RFC9406 (draft-ietf-tcpm-hystartplusplus-14)
> >
> > Title            : HyStart++: Modified Slow Start for TCP
> > Author(s)        : P. Balasubramanian, Y. Huang, M. Olson
> > WG Chair(s)      : Yoshifumi Nishida, Michael Tüxen, Ian Swett
> >
> > Area Director(s) : Martin Duke, Zaheduzzaman Sarker
> >