Subject: [tcpm] I-D Action: draft-ietf-tcpm-rfc8312bis-06.txt

From: [email-masked]
Date: Wed, 26 Jan 2022 01:12:50 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF.

        Title           : CUBIC for Fast and Long-Distance Networks
        Authors         : Lisong Xu
                          Sangtae Ha
                          Injong Rhee
                          Vidhi Goel
                          Lars Eggert
	Filename        : draft-ietf-tcpm-rfc8312bis-06.txt
	Pages           : 35
	Date            : 2022-01-26

Abstract:
   CUBIC is a standard TCP congestion control algorithm that uses a
   cubic function instead of a linear congestion window increase
   function to improve scalability and stability over fast and long-
   distance networks.  CUBIC has been adopted as the default TCP
   congestion control algorithm by the Linux, Windows, and Apple stacks.

   This document updates the specification of CUBIC to include
   algorithmic improvements based on these implementations and recent
   academic work.  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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc8312bis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tcpm-rfc8312bis-06.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc8312bis-06

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: Lars Eggert <[email-masked]>
Date: Wed, 26 Jan 2022 12:49:42 +0200

Hi,

this -06 version rolls in all the changes requested during (and after) WGLC ended.

I'll leave it up to the chairs to decide if another WGLC is warranted or the document can progress as-is.

Thanks,
Lars

> On 2022-1-26, at 11:12, [email-masked] wrote:
> 
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 27 Jan 2022 00:02:43 -0800

Hi Lars,

Thanks for updating the draft.
There seems to be lots of discussions and updates. So, if possible, I think
it would be great if there's highlights for the major updates.

Also, I am wondering if https://github.com/NTAP/rfc8312bis/issues/135 has
been solved completely.
Have we decided to leave this part as it is? We don't need any texts here
or are there any future plans?

Thanks,
--
Yoshi

---

From: Vidhi Goel <[email-masked]>
Date: Thu, 27 Jan 2022 16:34:55 -0800

Hi Yoshi,

> There seems to be lots of discussions and updates. So, if possible, I think it would be great if there's highlights for the major updates.
We provided the summary during IETF 112. And have a couple more changes. Here is the combined summary:
Create new subsections for spurious timeouts and spurious loss via ACK
Clarify meaning of "application-limited" in Section 5.8
Brief discussion of convergence in Section 5.6
Add more test results to Section 5 and update some references
Change wording around setting ssthresh
Updates [RFC 5681] to allow CUBIC’s more aggressive sending behavior Recommend Hystart++ for slow-start to avoid overshoot 
Extra care must be taken so that end of slow start and the first multiplicative decrease work well together 
In case of packet loss (only), sender MAY use PRR [RFC 6937] to reduce sending rate 
CUBIC, like Reno has slow adaptation in wireless environments 
Proper queue sizing and management can mitigate risk of high queuing delay as CUBIC fills buffer faster than Reno. 
Reduce cwnd in response to ECE until it reaches 1 MSS and then use retransmit timer with exponential backoff 
Use FlightSize instead of cwnd after a congestion event
For rate-limited apps, recommend RFC 7661 to mitigate the issue of 
FlightSize being significantly smaller than cwndSome implementations currently use cwnd and may continue to do so 
Fix a bug in average CUBIC window equation in Discussion Rephrase text around spurious retransmission detection algorithms 
CUBIC’s response to sudden increase and decrease in capacity due to transient events 
Replace ACK by “new ACK” wherever applicable and define it clearly Rename AIMD (TCP) -> Reno 
Moved "MUST NOT" requirement about app-limited period from discussion to main congestion avoidance section
We also add diff to Appendix in the draft. https://www.ietf.org/archive/id/draft-ietf-tcpm-rfc8312bis-06.html#name-evolution-of-cubic <https://www.ietf.org/archive/id/draft-ietf-tcpm-rfc8312bis-06.html#name-evolution-of-cubic>

> Also, I am wondering if https://github.com/NTAP/rfc8312bis/issues/135 <https://github.com/NTAP/rfc8312bis/issues/135> has been solved completely. 
> Have we decided to leave this part as it is? We don't need any texts here or are there any future plans?
We have discussed internally and decided to leave it as is. The justification is - there is already large scale deployment of CUBIC in the field with Beta_cubic = 0.7. We had added the below line to the draft as a caution. To change B_cubic for so many deployments, it would require a lot of experimental data and perhaps even some deployment experience. Such a change would be categorized as a research initiative before it makes it to an IETF draft.

A side effect of setting βcubic to a value bigger than 0.5 is slower convergence. We believe that while a more adaptive setting of βcubic could result in faster convergence, it will make the analysis of CUBIC much harder.

Thanks,
Vidhi

> On Jan 27, 2022, at 12:02 AM, Yoshifumi Nishida <[email-masked]> wrote:
> 
> Hi Lars,
> 
> There seems to be lots of discussions and updates. So, if possible, I think it would be great if there's highlights for the major updates.
> 
> Also, I am wondering if https://github.com/NTAP/rfc8312bis/issues/135 <https://github.com/NTAP/rfc8312bis/issues/135> has been solved completely. 
> Have we decided to leave this part as it is? We don't need any texts here or are there any future plans?
> 
> Thanks,
> --
> Yoshi
> 
> 
> On Wed, Jan 26, 2022 at 2:50 AM Lars Eggert <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
> > On 2022-1-26, at 11:12, [email-masked] <mailto:[email-masked]> wrote:
> > 
> > 
> > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc8312bis/ <https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc8312bis/>
> > 
> > https://www.ietf.org/archive/id/draft-ietf-tcpm-rfc8312bis-06.html <https://www.ietf.org/archive/id/draft-ietf-tcpm-rfc8312bis-06.html>
> > 
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc8312bis-06 <https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc8312bis-06>
> > 
> > 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 31 Jan 2022 23:43:12 -0800

Hello,

After some discussions among chairs, we decided to run the 2nd WGLC on
draft-ietf-tcpm-rfc8312bis in consideration of the importance of the draft.
We'll be grateful if you could send your feedback to the ML. The WGLC runs
until *Feb 11*.

If interested, you can check in-depth past discussions in the following URL.
https://github.com/NTAP/rfc8312bis/

Thank you so much!
--
tcpm co-chairs