[tcpm] apparent ambiguities in draft spec for Hystart++ window start/end?

[Neal Cardwell <[e-mail]>]

Hi,

Thanks again for the nice Hystart++ draft!

Below are three quick comments about what AFAICT are some ambiguities about
the spec for detecting and handling window starts/ends, plus a suggestion
for wording that section:

(1) Currently, the draft at:

https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-hystartplusplus#section-4.2
says:

      When windowEnd is ACKed, the current round ends and windowEnd is
      set to SND.NXT

IMHO this is a bit ambiguous as to whether it means:
(a)  if (SND.UNA > windowEnd)
or
(b)  if (SND.UNA >= windowEnd)

Normally when I read that a sequence number X "is ACKed" I think of the (b)
case, i.e. SND.UNA >= X. But for application-limited flights of data, I
think that (b) interpretation would lead to the Hystart++ logic for the
start/end of rounds potentially being executed twice for each flight of
data: once for the first segment in the flight, and once for the last
segment in the flight (because while processing ACKs for an
application-limited flight the value of SND.NXT may not change).

So I imagine the Hystart++ algorithm actually intends the (a) semantics.
The (a) approach is what Linux TCP CUBIC Hystart does, and the AFAICT  (a)
semantics give the correct once-per-round behavior even for
application-limited flights. I think it would be good to express that
aspect of the algorithm more precisely to indicate the approach that is
intended.

(2) A second, related, issue: for per-round behavior section 4.2 of the
algorithm specifies how to detect the end of a round ("When windowEnd is
ACKed, the current round ends"), but only specifies what action is to be
taken at the start of a round ("At the start of each round during standard
slow start ([RFC5681]) and CSS:").

I suppose the text is implicitly considering that the start of one round is
the same as the end of the previous round. For bulk data that assumption
might be acceptable; it might be fine to think of the start of one round as
the same as the end of the previous round. But for application-limited
flights of data that assumption does not hold, and the start of a round and
end of a round are very different events with very different timing and
characteristics. So for the common case of application-limited flights of
data currently the draft does not specify how to detect the "start of each
round" event that triggers the per-round actions; it only defines how to
detect the "end" of a round.

(3)  A third, related, issue: the text in section 4.2 says:

   A round is chosen to be approximately the Round-Trip Time (RTT).


For application-limited flights this text is a poor or confusing fit. For
application-limited flights,  the duration of time between two successive
rounds, aka the length of a round (IMHO), can be arbitrarily long; it can
be much longer than the RTT and perhaps hours or even days. I would suggest
just dropping that sentence, to avoid confusion.

---

(a suggestion):

To clear up these ambiguities I would suggest tweaking the existing text
from:

*(before):*
"""

   A round is chosen to be approximately the Round-Trip Time (RTT).  We
   recommend that rounds be measured using sequence numbers.  Round can
   be approximated using sequence numbers as follows:

      Define windowEnd as a sequence number initialize to SND.UNA

      When windowEnd is ACKed, the current round ends and windowEnd is
      set to SND.NXT

   At the start of each round during standard slow start ([RFC5681
<https://datatracker.ietf.org/doc/html/rfc5681>]) and
   CSS:

"""

...to be something more like the following:

*(after):*
"""

   Hystart++ measures rounds using sequence numbers, as follows:


      Define windowEnd as a sequence number initialized to SND.UNA.

      Upon receiving an ACK, if (SND.UNA > windowEnd) then
      a new round has started and the sender sets windowEnd to
      SND.NXT.

   At the start of each new round during standard slow start ([RFC5681])
   and CSS:
"""

best regards,
neal