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

From: Michael Tuexen <[email-masked]>
Date: Wed, 13 May 2020 23:40:11 +0200

Dear all,

this mail starts a WG adoption call for
https://tools.ietf.org/html/draft-balasubramanian-tcpm-hystartplusplus-03

The intended status would be PS.

So I would like to solicit feedback regarding support for or objections against the
adoption of the document as a WG document in TCPM, if it hasn't been already sent to
the list.

Please provide feedback before May 21st.

Best regards
Michael

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 14 May 2020 08:06:28 +0000

I support adoption.

On 13.05.20, 23:40, "tcpm on behalf of Michael Tuexen" <[email-masked] on behalf of [email-masked]> wrote:

    Dear all,

    Best regards
    Michael

---

From: "Mark Allman" <[email-masked]>
Date: Thu, 14 May 2020 08:06:21 -0400

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

allman

---

From: Neal Cardwell <[email-masked]>
Date: Thu, 14 May 2020 11:13:47 -0400

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

---

From: "Mark Allman" <[email-masked]>
Date: Thu, 14 May 2020 11:24:48 -0400

Neal-

Based on your note it seems that it should be straightforward to add
solid motivation in the document.  (And, hopefully your high-level
notions of finding that it works well can readily be turned into
objective statements.)  So, why don't we just do that?

> However, I would urge that these concerns be addressed in future
> editorial revisions,

My issue is that this is **not** editorial.  There is simply nothing
in the document that suggests it is a good idea.  That fact is
completely independent of whether it is or is not a good idea.  It
just means there is no basis to judge given in the document.  We
should expect some explanation of why this is reasonable before the
WG is asked to adopt and work on something.  IMHO.

allman

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 14 May 2020 23:03:55 +0200

I would like to see this work adopted.

Am 13.05.2020 um 23:40 schrieb Michael Tuexen:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Thu, 14 May 2020 19:21:18 -0700 (PDT)

Dear tcpm'ers,
	I have read the 03 version of this draft, and support this draft
being adopted by the WG.

	I however believe this work should be consider only a starting
point for formalizing hystartplusplus, for one the description seems to
ignore ECN (RFC3168) and refers to drops or loss, though I believe the
implementation actually does react to a CE.

	I am also concerned as a "Proposed Standard" it has the text
indicated one can "experiment" with magic constants, that would be fine
for an experimental track, but I do not feel comfortable with that text
in a PS.  If these constants are not well defined perhaps this should be
an experiment.

Regards,
Rod Grimes

-- 
Rod Grimes                                                 [email-masked]

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 15 May 2020 09:15:26 +0000

Hi Mark,

this work has been presented multiple time in tcpm which a bunch of measurement numbers of real deployments. I really don't think this material should end up in the draft. The draft provides the specification of the mechanism (preferably as comprehensive and short as possible). The IETF proceedings provide the record for results and background information.

Mirja

On 14.05.20, 17:25, "tcpm on behalf of Mark Allman" <[email-masked] on behalf of [email-masked]> wrote:

    Neal-

    allman

---

From: "Scharf, Michael" <[email-masked]>
Date: Fri, 15 May 2020 10:38:44 +0000

A draft could also have an informative appendix or a short non-normative section with background information.

For what it is worth, I don't know how many readers of any existing RFC even know that the IETF has proceedings. If people are expected to find data in the IETF proceedings, a draft should probably include references, IMHO.

Michael

> -----Original Message-----
> From: tcpm <[email-masked]> On Behalf Of Mirja Kuehlewind
> Sent: Friday, May 15, 2020 11:15 AM
> To: Mark Allman <[email-masked]>; Neal Cardwell
> <[email-masked]>
> Cc: Michael Tuexen <[email-masked]>; tcpm IETF list
> <[email-masked]>; [email-masked]
> Subject: Re: [tcpm] Request for feedback on WG adoption of draft-
> balasubramanian-tcpm-hystartplusplus-03
> 
> Hi Mark,
> 
> this work has been presented multiple time in tcpm which a bunch of
> measurement numbers of real deployments. I really don't think this material
> should end up in the draft. The draft provides the specification of the
> mechanism (preferably as comprehensive and short as possible). The IETF
> proceedings provide the record for results and background information.
> 
> Mirja
> 
> 
> On 14.05.20, 17:25, "tcpm on behalf of Mark Allman" <tcpm-
> [email-masked] on behalf of [email-masked]> wrote:
> 
> 
>     Neal-
>

---

From: "Mark Allman" <[email-masked]>
Date: Fri, 15 May 2020 09:26:25 -0400

> this work has been presented multiple time in tcpm which a bunch
> of measurement numbers of real deployments. I really don't think
> this material should end up in the draft. The draft provides the
> specification of the mechanism (preferably as comprehensive and
> short as possible). The IETF proceedings provide the record for
> results and background information.

I have never actually heard quite that framing before.

I am not looking for a research paper here.  But, some sketch of why
this has been found to be reasonable, that the draft is just
documenting existing practice, etc. would seem required to me.

And, incorporating a comprehensive set of references for more and
deeper information is fine.  The substantive reference in this draft
is from over a decade ago (yes, "the" because there is only one).  I
am not the sharpest knife in the drawer, but I would never think to
go dig through the IETF proceedings to try to find such.  Not that
it might not be there, just that that would be a long slog without a
reference.

I also bristle somewhat at this notion that our job is just to give
the "what" and not the "why".  I know we are much better at the
former.  And, I know I have been guilty of too little of the latter
at times.  I know this because I have seen new folks read these RFCs
and not understand why something was done.  Or, that something is
important for some unstated, but crucial reason.  Or, decide that we
do X because of Y and so if Y is different then X can be, too---even
though we did X because of Z and just didn't say it well.

I am clearly not consensus, but to me the adoption question is
completely premature when the document doesn't offer motivation that
it is reasonable (beyond an intuitive hand wave that we're
preventing slow start overshoot).  Neal's note does sketch out why
this might be an OK thing to do.  And, probably IETF talks have, as
well.  But, some of that motivation has to make it into the
document, it seems to me.

allman

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 15 May 2020 15:39:37 +0000

Hi Mark,  and also hi Michael (replying to your mail here as well basically),

I didn't meant to say that a draft cannot have such material or that people that read this draft after it left the work groups should dig out the proceeding. But as also indicated by Michael, this kind of material may rather be part of the appendix. The draft and future RFC must ensure that the spec is understandable and implementable.  

At adoption time, yes, we also need to understand why this work in needed and why it might be beneficial, but I think we should be able in this group to have this understanding based on what was presented (and can be found in the proceeding and at least we all currently working in this group should know how to find them).

At least I have a good enough understanding to be able to say that I think we as a group should further work on this, with the goal to push an RFC. For my point of view that's all that's needed to adopt a draft as a starting point for this work.

Mirja

    allman

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 15 May 2020 18:39:07 +0200

I support its adoption.