Re: [tcpm] Request for feedback on WG adoption of draft-balasubramanian-tcpm-hystartplusplus-03

[Neal Cardwell <[e-mail]>]

"On Thu, May 14, 2020 at 8:06 AM Mark Allman <[e-mail]> wrote:
>
>
> > this mail starts a WG adoption call for
> > https://tools.ietf.org/html/draft-balasubramanian-tcpm-hystartplusplus-03
> >
> > The intended status would be PS.
>
> Per note from the other day, I think this could get there, but the
> current document doesn't offer enough (any, really) motivation that
> suggests HyStart++ is useful or effective.  Since I can't figure
> that out, I can't support the document for WG adoption at the moment
> (and especially so at PS).

Fair enough. However, I would urge that these concerns be addressed in
future editorial revisions, but that we not allow them to derail
progress toward WG adoption working toward PS for
draft-balasubramanian-tcpm-hystartplusplus-03.

I would make several arguments for WG adoption, working toward the PS
level, for draft-balasubramanian-tcpm-hystartplusplus-03:

(1) From previous production experience with large-scale Internet
services, our team has seen that Hystart is very important in reducing
packet loss rates from new flows entering the public Internet. So
Hystart is important and very useful on a technical level.

(2) The original Hystart has already been ubiquitously deployed on the
Internet for a decade, since it has been default-enabled in Linux TCP
for a decade (as part of the default-enabled CUBIC congestion control
module for Linux). Just as it was important, IMHO, to document the
core CUBIC algorithm in RFC8312, I think it's important to document
some version of Hystart as an RFC.

(3) At an algorithmic level, I see several important improvements that
Hystart++ makes over the original Hystart; at least:

  (a) using only the delay-based variant of Hystart, and not the
ack-train-based variant of Hystart (the ack-train-based variant our
team has also found is liable to false positives, especially with
paced flows)

 (b) "mitigating poor performance which can result from false
positives when HyStart is used alone", by ensuring that after
triggering Hystart++, a connection increases its cwnd at least as fast
as Limited Slow Start allows.

  (c) decoupling the delay-based algorithm from the global min_rtt of
the connection, and instead using lastRoundMinRTT

Presuming that multiple implementations or deployments can validate
that these changes are indeed resulting in good performance, I think
it would be good to document this improved version, Hystart++, rather
than the 10-year-old original Hystart.

(4) Yes, there are magic numbers in Hystart++, but (aside from the new
LSS_DIVISOR)  those other four magic numbers are all identical to the
magic numbers in the Hystart code that has been doing a good job of
improving performance for much of the traffic on the Internet for the
last decade (see (2)). So the fact that the magic numbers are not
discussed or justified is a point that can be cleared up in the
editing process, and IMHO need not delay progress through the RFC
process. I would argue that, like the constants used for SRTT and RTO
calculations, in the future we could try to do more science to try
other values and quantify the performance of the alternative values,
but long-term experience has shown that these magic values work well
enough in practice, and thus we do not need to bikeshed them now, and
so we should not let the magicness of these numbers hold back their
publication as a PS RFC. We should just document the rationale for
each magic number in the RFC, and explain in the document that they
have stood the test of time and wide deployment/use. Slides at the
meetings can quantify the performance impact of alternative values.

best regards,
neal