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

[Vidhi Goel <[e-mail]>]

Thank you Spencer for your review.

> 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.
With the bugs fixed in rfc8312-bis, CUBIC will utilize the link more efficiently which is the goal of any congestion control algorithm. The impact of such change to applications can include many things, for example, faster completion time, but as you said, it also depends on other competing traffic.
So, yes, I agree that we can’t define a certain behavior on which an application can rely on.

> 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.

Ok. I think Ines Robles was also alluding to this. So, I have added new text to specify this in more detail. Please see https://github.com/NTAP/rfc8312bis/pull/163 <https://github.com/NTAP/rfc8312bis/pull/163>. 

> 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).

Fixed this in the above PR.

>> 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.
Not sure what you mean here. “Paths” and “networks” have been used interchangeably in the document (most likely, in most networking literature), even though a network can consist of many paths. IMO, it is fine to use either.

> 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)

Ok. Fixed this with your suggestion in the above PR.

> 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?

It is correct that this section is new as the concept of returning to previous stable state “W_max” is new to Cubic. I don’t know of any related IETF art. Let me know if there is any and I’d be happy to add it.


Thanks,
Vidhi
> On Jan 5, 2023, at 4:38 PM, Spencer Dawkins via Datatracker <[e-mail]> wrote:
> 
> 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?
> 
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm