[tcpm] John Scudder's No Objection on draft-ietf-tcpm-hystartplusplus-13: (with COMMENT)

[John Scudder via Datatracker <[e-mail]>]

John Scudder has entered the following ballot position for
draft-ietf-tcpm-hystartplusplus-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-hystartplusplus/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this interesting and useful spec. I have a few comments, which I
hope may be helpful.

## COMMENTS

### Section 4.2

I found the almost-but-not-quite-C pseudocode ever so mildly problematic. Two
specific points:

- I’m not confident that clamp() is such a universally understood idiom that
you should use it without defining it.

- The pseudocode block below wouldn’t work right if it were actual C, because
of the lack of braces in the outer and inner if statements.

```
if (rttSampleCount >= N_RTT_SAMPLE AND
    currentRoundMinRTT != infinity AND
    lastRoundMinRTT != infinity)
  RttThresh = clamp(MIN_RTT_THRESH,
                    lastRoundMinRTT / 8,
                    MAX_RTT_THRESH)
  if (currentRoundMinRTT >= (lastRoundMinRTT + RttThresh))
    cssBaselineMinRtt = currentRoundMinRTT
    exit slow start and enter CSS
```

Admittedly it visibly isn’t quite C and the meaning is reasonably clear from
the use of indentation. However since the pseudocode is the only specification
of the algorithm (unlike some specifications that use pseudocode only as an
adjunct to elucidate a prose specification), I think it would be worthwhile to
try extra-hard to be unambiguous, which means either (ideally) referencing a
formal grammar for the pseudocode dialect you're using, or at least adding a
few more hints (a definition and some braces or other block delimiters,
respectively, in the case of the things I flag above).

### Section 4.2

I’m curious, in the pseudocode block quoted in my previous point, where did the
constant ‘8’ come from? It doesn’t seem to be from the HyStart paper (I didn’t
read it carefully, just grepped it for ‘8’). It’s somewhat surprising to see
this as a literal instead of a tunable, without discussion.

### Section 4.3

I'm not a transport guy, and “paced TCP implementation” doesn’t mean anything
to me -- I would have benefited from a reference, this seems indicated also
since the term isn’t just informative but normative (“A paced TCP
implementation SHOULD…”).

### Section 4.3

Please spell out BDP instead of using the initialism. (Or define it somewhere,
but since you only use it once why not just spell it out.)

### Section 9

RFC 8174 should probably be a normative reference.

## NITS

s/send heavy/send-heavy/g