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

From: [email-masked]
Date: Wed, 21 Apr 2021 04:14:58 -0700

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-01.txt
	Pages           : 28
	Date            : 2021-04-21

Abstract:
   CUBIC is an extension to the traditional TCP standards.  It differs
   from the traditional TCP standards only in the congestion control
   algorithm on the sender side.  In particular, it uses a cubic
   function instead of the linear window increase function of the
   traditional TCP standards to improve scalability and stability under
   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 [RFC8312].

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-01.html

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

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Lars Eggert <[email-masked]>
Date: Wed, 21 Apr 2021 14:17:33 +0300

Hi,

this revision rolls in all the changes the authors wanted to make to CUBIC. In other words, we believe this could be ready for a WGLC.

Thanks,
Lars

On 2021-4-21, at 14:14, [email-masked] wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Scharf, Michael" <[email-masked]>
Date: Tue, 27 Apr 2021 14:20:20 +0000

Hi Lars, all,

I have read -01, which looks pretty good to me.

Yet, I wonder about one editorial aspect:

In the current version, the abstract, introduction and some later non-normative sections are by and large copied from RFC 8312. While that is perfectly reasonable for a -bis document, I believe the document could be a bit more explicit regarding the new status as PS, even if this would imply some editorial changes as compared to RFC 8312.

As of today, 8312bis is probably one of the most important and most widely deployed TCP standards. But the text is not necessarily written that way, given its origins.

Here are some examples of what comes into my mind:

1/ Abstract:

"CUBIC is an extension to the traditional TCP standards. It differs from the traditional TCP standards only in the congestion control algorithm on the sender side."

IMHO one could also start here with something much more explicit along the lines of "CUBIC is a standard TCP congestion control algorithm [...]".

Personally, I don't like the term "traditional standards" in this context. In fact, after 8312bis will be published as PS, CUBIC may actually become part of what one could consider as "traditional standards". Maybe it would be better to avoid that term altogether? At least, I believe it could be avoided by rewording the abstract.

2/ Introduction: 

The key sentence "It is therefore to be regarded as the current standard for TCP congestion control" comes at the end after a lot of text on the historical background.

An alternative would be to start in the introduction with what CUBIC is as according to this document and why CUBIC is relevant. Obviously, the historical context _is_ important and must be explained in the document. But I am less sure whether the history needs to be at the beginning of the introduction. At least newcomers to congestion control may more care about the content of this Proposed Standard and less about research that resulted in RFC 8312.

3/ Section 5.4:

"CUBIC has been extensively studied by using both NS-2 simulation and testbed experiments, covering a wide range of network environments. More information can be found in [HKLRX06]. Additionally, there is decade-long deployment experience with CUBIC on the Internet."

This is another example where the most important message as of 2021 comes somewhere at the end. Given the experience with CUBIC, one could just start with the last sentence "There is decade-long deployment experience..." and then state something along the lines of "The original CUBIC design has been studied extensively by using both NS-2 simulation and testbed experiments...". Just as a thought.

Probably the existing text in -01 also works in all these cases and this is just about editorial style. But I think we could at least discuss whether some alternative wordings would make sense given the new PS status, in particular for newcomers who may not have read RFC 8312 and don't know its history (and probably never have to once this PS is published).

My 2 cents

Michael (with no hat)

> -----Original Message-----
> From: tcpm <[email-masked]> On Behalf Of Lars Eggert
> Sent: Wednesday, April 21, 2021 1:18 PM
> To: [email-masked]
> Subject: [tcpm] Ready for WGLC? (Re: I-D Action: draft-ietf-tcpm-rfc8312bis-
> 01.txt)
> 
> Hi,
> 
> this revision rolls in all the changes the authors wanted to make to CUBIC. In
> other words, we believe this could be ready for a WGLC.
> 
> Thanks,
> Lars
>

---

From: Lars Eggert <[email-masked]>
Date: Tue, 27 Apr 2021 17:41:13 +0300

Hi,

> Yet, I wonder about one editorial aspect:

<snip>

thank you, I have opened https://github.com/NTAP/rfc8312bis/issues/59 for this.

Lars