[art] Artart last call review of draft-ietf-tcpm-rfc8312bis-14

[Spencer Dawkins via Datatracker <[e-mail]>]

Reviewer: Spencer Dawkins
Review result: Ready with Nits

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, I see 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 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?