CUBIC for Fast Long-Distance Networks
draft-ietf-tcpm-cubic-07

[Ballot comment]
I'm a confused by the fact that this draft claims to specify CUBIC, but also cites another document for CUBIC. Which is the authoritative definition? If the answer is "that other document", then some words to clarify that would be helpful.

I gather CUBIC is not an acronym? If correct, why spell it in all-caps?

[Ballot comment]
I'm really glad to see this specification entering IESG Evaluation.

I have a few comments, but most are editorial or (at most) about improving clarity.

In this text,

  In a smaller BDP network where Standard TCP flows are
  working well, the absolute amount of the window decrease at a loss
  event is always smaller because of the multiplicative decrease.

I got lost on "always smaller" than what - than Standard TCP? Or CUBIC? Or something else?

Nit: Is "weithed" "weighted", or is it something else?

In 4.7.  Timeout

  In case of timeout, CUBIC follows the standard TCP to reduce cwnd,
  but sets ssthresh using beta_cubic (same as in Section 4.5).

should "standard TCP" be "Standard TCP"? I wasn't watching for other occurrences of "standard TCP", but I noticed a bunch of them.

In this text,

  CUBIC MUST employ a slow start algorithm, when the cwnd is no more
  than ssthresh.  Among the slow start algorithms, CUBIC MAY choose the
  standard TCP slow start [RFC5681] in general networks, or the limited
  slow start [RFC3742] or hybrid slow start [HR08] for high-bandwidth
  and long-distance networks.

is there any guidance you can give implementers about when to choose specific slow start algorithms?

In 5.10.  Incremental Deployment

  CUBIC requires only the change of TCP senders, and does not require
  any assistant of routers.

I'm not parsing the sentence. Is it saying

  CUBIC requires only changes to TCP senders, and does not require
  any changes to routers.

? Either way, it might be worth pointing out here that no changes to TCP receivers are required, either.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-tcpm-cubic-06, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out (ends 2017-10-02):

From: The IESG
To: IETF-Announce
CC: tcpm@ietf.org, nishida@sfc.wide.ad.jp, ietf@kuehlewind.net, Yoshifumi Nishida , draft-ietf-tcpm-cubic@ietf.org, tcpm-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (CUBIC for Fast Long-Distance Networks) to Informational RFC


The IESG has received a request from the TCP Maintenance and Minor Extensions
WG (tcpm) to consider the following document: - 'CUBIC for Fast Long-Distance
Networks'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-10-02. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  CUBIC is an extension to the current TCP standards.  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 function 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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

The document shepherd is Yoshifumi Nishida
The responsible Area Director is Mirja Kuehlewind .

This document describes CUBIC which is a congestion Control algorithm
used in TCP.
CUBIC modifies the standard congestion control mechanism in TCP in order to
address low utilization issues for networks with large BDP.
CUBIC is well deployed in the current Internet since it has been used as
the default congestion control scheme in Linux.
The objective of the draft is to document the mechanism of CUBIC in
Linux code as an informational RFC.


2. Review and Consensus

The TCPM working group had discussed how to document CUBIC mechanism and
reached the consensus to describe what is currently implemented as an
informational RFC.
If we see demands in the future, new version of the draft can be
published as a PS RFC,although it may require further discussions.

The draft has been reviewed and discussed by various participants in the WG
include experts from Linux kernel development community which have
been useful to adjust the description of detailed logics.
While the WG spent two year to discuss the draft, no major controversial
point has been raised during this process.
I believe there is a strong consensus in the WG for publication.


3. Intellectual Property

Each author has confirmed that their direct, personal knowledge of any
IPR related to this document has already been disclosed.


4. Other Points

None

Request for posting confirmation emailed to previous authors: "Richard Scheffenegger" , "Lars Eggert" , "Lisong Xu" , "Sangtae Ha" , "Injong Rhee" , "Alexander Zimmermann" , tcpm-chairs@ietf.org