Last Call Review of draft-ietf-tcpm-rfc8312bis-14
review-ietf-tcpm-rfc8312bis-14-artart-lc-dawkins-2023-01-05-02

(Apologies - my -00 review was excessively line-wrapped. I hope this will be
easier for everyone to handle!)

Please let me start by saying that I'm really impressed by the improved clarity
and organizational structure of this draft, compared to RFC 8312. Nice work.

Because this is an ARTART review of a TCP-level specification, I don't expect
to see impacts of an implementation of this version of CUBIC that would be
visible to an application using TCP, and especially impacts that the
application could rely on, because CUBIC behavior is likely to depend on what
competing flows from other applications are present along the path that the
application is sharing, and no new "knobs" are provided for applications to
control CUBIC-level decisions.

Would the authors agree with that characterization? If not, it would be worth
saying explicitly what applications might notice when moving to this version of
CUBIC from one of the RENO versions, or from the RFC 8312 version of CUBIC.

But, beyond that, I did read through the specification, and I found a few
places where I thought of suggestions that might be improvements. Please do the
right thing, of course.

In the Introduction, in this text:

=====>

This document updates the specification of CUBIC to include algorithmic
improvements based on the Linux, Windows, and Apple implementations and recent
academic work. Based on the extensive deployment experience with CUBIC, it also
moves the specification to the Standards Track, obsoleting [RFC8312]. This
requires an update to Section 3 of [RFC5681], which limits the aggressiveness
of Reno TCP implementations. Since CUBIC is occasionally more aggressive than
the [RFC5681] algorithms, this document updates the first paragraph of Section
3 of [RFC5681], replacing it with a normative reference to guideline (1) in
Section 3 of [RFC5033], which allows for CUBIC's behavior as defined in this
document.

<=====

I see the description of how [RFC5681] is being updated, but I imagine some
readers would appreciate explicit "OLD/NEW" text, so that anyone working on a
5681bis document would know what their starting text says, and would also
appreciate the discussion of what documents are being obsoleted and updated
appearing in its own section, so it would be easier to spot.

I see that this document contains text (for example, in Section 3.2. Principle
2 for Reno-Friendliness) which continues the terminology from RFC 8312
referring to "small-BDP networks" and "large-BDP networks" (although these are
not consistently hyphenated).

From a host's perspective, are these more correctly described as "small-BDP
paths" and "large-BDP paths"? I'm not sure how a host, or even two hosts, would
know what other paths in the network(s) might have as their BDPs.

Section 3.2's introduction of "bandwidth-delay product", in this text, seemed
clunky.

=====>

CUBIC promotes per-flow fairness to Reno. Note that Reno performs well over
paths with short RTTs and small bandwidths (or small BDPs). There is only a
scalability problem in networks with long RTTs and large bandwidths (or large
BDPs).

<=====

I thought the point here was that it didn't matter whether you ended up with a
small or large bandwidth-delay product because of the RTT or because of the
available bandwidth - what matters is whether the product of bandwidth and
delay is large or small. If that's correct, you might reasonably say

=====>

CUBIC promotes per-flow fairness to Reno. Note that Reno performs well over
paths with small bandwidth-delay products, and only experiences problems when
attempting to increase bandwidth utilization on paths with large
bandwidth-delay products.

<=====

(additionally making the "scalability problem" more explicit)

Is it correct that Section 4.7. Fast Convergence is (from an IETF
standards-track perspective) entirely new? I see there's no reference for this
mechanism, in the same way that (for example) Sections 5.6 and 5.8 include, but
is there any prior art that might be acknowledged?