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? -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
