Subject: [tcpm] Comments on draft-ietf-tcpm-cubic-03

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Sat, 7 Jan 2017 23:50:49 +0000

Hi all,

As individual contributor to TCPM I have read draft-ietf-tcpm-cubic-03. To me, the technical content is by and large ready to move forward.

I have some editorial suggestions, which would in my personal opinion improve the document. Also, I have one question on the interaction of CUBIC with huge buffers.

1/ Abstract

To me the abstract is a bit long and the historical (?) reference to BIC-TCP could easily be moved e.g. to the introduction. A shorter abstract would e.g. be:

   CUBIC is an extension of the current TCP congestion control.  The protocol
   differs from the current TCP standards only in the congestion window
   adjustment function in the sender side.  In particular, it uses a
   cubic function instead of a linear window increase of the current TCP
   standards to improve scalability and stability under fast and long
   distance networks. CUBIC and its predecessor algorithm have been adopted as 
   default by Linux and have been used for many years. This document provides a
   specification of CUBIC to enable third party implementation and 
   to solicit the community feedback through experimentation on the
   performance of CUBIC. This document does not replace the standard TCP
   congestion control [RFC5681].

As the IESG typically reviews the meta-data of documents, I believe an explicit statement on the relationship to RFC5681 would be useful. This would be one potential wording.

The remaining content currently in the abstract could e.g. be added to the Introduction. I assume Linux has switched to CUBIC many years ago, right? So, some wording could be...

   BIC-TCP, a predecessor of CUBIC, has been selected as default TCP congestion
   control algorithm by Linux in the year 2005 and been used for several years
   by the Internet community at large. CUBIC is using a similar window growth function
   as BIC-TCP and is designed to be less aggressive and fairer to TCP in
   bandwidth usage than BIC-TCP while maintaining the strengths of BIC-
   TCP such as stability, window scalability and RTT fairness.

   CUBIC has already been deployed globally by Linux. Through
   extensive testing in various Internet scenarios, we believe that
   CUBIC is safe for testing and deployment in the global Internet.

2/ Section 1.  Introduction

To me the introduction is quite long and covers two different aspects: First, it provides context on the history of CUBIC, and second it provides a (non-normative) overview of the design principle. I believe both could be split into two parts, e.g., with a ToC like this:

   1.  Introduction
   2.  Design principle of CUBIC
   3.  Conventions
   4.  CUBIC Congestion Control
   ...

(There are other options.)

This would just be a reorganization of the text. At least some parts of the current introduction section assume that the reader has a pretty good understanding of congestion control and they are not really introductory, so this is why moving these description to a dedicated "design principles" section could make sense. But, similar like my comment on the abstract, this may be a question of personal preference only.

Nit: Please expand "MIMD" on first use.

3/ Section 4. Discussion

In order to explain the section structure in Section 4, it could perhaps help to refer to RFC 5033 again at the beginning of Section 4.

4/ Section 4.4.  Investigating a Range of Environments

Wouldn't it make sense to mention somewhere in the document, e.g. in Section 4.4, that CUBIC can fill large buffers, in particular large buffers with drop-tail, and that this can increase delay for other connections?

This seems to be an inherent characteristic of high-speed congestion control algorithms only reacting to loss, and it will not matter if proper queue management is in place, but still I wonder if this aspect should be mentioned.

Thanks

Michael

---

From: Lisong Xu <[email-masked]>
Date: Sat, 7 Jan 2017 20:42:24 -0600

Thank you very much, Michael! This is very helpful! We will revise the 
draft according to your editorial suggestions.

Regarding the last question on the interaction of CUBIC with huge 
buffers, yes, CUBIC, as a loss-based (not delay-based) algorithm, fills 
router buffers (large or small) until there is a packet loss. But I 
guess we should not say that CUBIC increases the delay for other 
connections, because that depends on whether other connections are loss 
based or delay based. If other connections are also loss based, they 
themselves also fill router buffers.

Thanks

Lisong

On 1/7/2017 5:50 PM, Scharf, Michael (Nokia - DE) wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Sun, 8 Jan 2017 11:22:01 +0000

Hi Lisong,

One scenario where this could IMHO matter is if CUBIC shares an over-buffered bottleneck link with other app-limited applications. In that case, the other app-limited connections only contribute very little to filling the buffer even if they run a loss-based algorithm, while CUBIC of course does what a loss-based algorithm is expected to do.

This delay increase by full buffers is not a CUBIC specific issue. Reno as a loss-based algorithm obviously has this property, too. Yet, IMHO in high-BDP scenarios CUBIC can fill the buffer much faster, and it backs off less, so I suspect that there can be a difference to Reno, right? But I don't have any own data on the impact on latency to app-limited applications in over-buffered scenarios, so I cannot comment on how relevant the effect really is. And I don't ask for further data on this specific detail.

But somehow I believe it could make sense to remind readers that loss-based congestion control requires proper queue sizing and management. One or two sentences just as a heads-up could be enough. Maybe also an informative reference to RFC 7567. This would probably more target those readers who don't have a strong congestion control background.

Michael (entirely as individual contributor)

> -----Original Message-----
> From: Lisong Xu [mailto:[email-masked]]
> Sent: Sunday, January 08, 2017 3:42 AM
> To: Scharf, Michael (Nokia - DE); [email-masked]
> Cc: [email-masked]
> Subject: Re: [tcpm] Comments on draft-ietf-tcpm-cubic-03
> 
> > As individual contributor to TCPM I have read draft-ietf-tcpm-cubic-03. To
> me, the technical content is by and large ready to move forward.
> >
> > I have some editorial suggestions, which would in my personal opinion
> improve the document. Also, I have one question on the interaction of CUBIC
> with huge buffers.
> >
> >
> > 1/ Abstract
> >
> > To me the abstract is a bit long and the historical (?) reference to BIC-TCP
> could easily be moved e.g. to the introduction. A shorter abstract would e.g.
> be:
> >
> > As the IESG typically reviews the meta-data of documents, I believe an
> explicit statement on the relationship to RFC5681 would be useful. This would
> be one potential wording.
> >
> > The remaining content currently in the abstract could e.g. be added to the
> Introduction. I assume Linux has switched to CUBIC many years ago, right? So,
> some wording could be...
> >
> > To me the introduction is quite long and covers two different aspects:
> First, it provides context on the history of CUBIC, and second it provides a
> (non-normative) overview of the design principle. I believe both could be
> split into two parts, e.g., with a ToC like this:
> >
> >     1.  Introduction
> > This would just be a reorganization of the text. At least some parts of the
> current introduction section assume that the reader has a pretty good
> understanding of congestion control and they are not really introductory, so
> this is why moving these description to a dedicated "design principles"
> section could make sense. But, similar like my comment on the abstract, this
> may be a question of personal preference only.
> >
> > In order to explain the section structure in Section 4, it could perhaps
> help to refer to RFC 5033 again at the beginning of Section 4.
> >
> > Wouldn't it make sense to mention somewhere in the document, e.g. in Section
> 4.4, that CUBIC can fill large buffers, in particular large buffers with drop-
> tail, and that this can increase delay for other connections?
> >
> > This seems to be an inherent characteristic of high-speed congestion control
> algorithms only reacting to loss, and it will not matter if proper queue
> management is in place, but still I wonder if this aspect should be mentioned.
> >
> > Thanks
> >
> > Michael
> >

---

From: Lisong Xu <[email-masked]>
Date: Sun, 8 Jan 2017 14:02:52 -0600

Got it. We will briefly mention that in the draft. Thanks, Michael!

Lisong