Subject: [tcpm] adoption and implementation of draft-balasubramanian-tcpm-hystartplusplus-03

From: Martin Duke <[email-masked]>
Date: Wed, 29 Apr 2020 10:32:14 -0700

I support adoption of this work.

I would also encourage anyone in the WG thinking about implementing this
draft to speak up. If this set is not null, I would encourage Praveen to
move this draft to the Proposed Standard (preferred) or at least
Experimental track.

Martin

---

From: Yuchung Cheng <[email-masked]>
Date: Wed, 29 Apr 2020 12:09:41 -0700

+1 on adoption

two questions
1. RttSampleCount. Since the counter is incremented on a per ACK
basis, the receiver behavior may significantly influence the actual
hystart timeline. For example a receiver acking one full cwnd burst vs
acking every packet (or even every byte). it'd be good to clarify if
the intended rounds or time-scale in hystart++ design

2. "In practice, the Inter- Packet Arrival algorithm does not perform
well and is not able to detect congestion early, primarily due to ACK
compression." In my experience, another reason is it relies on packets
being pushed out in a window of burst in slow start. Therefore in
paced slow start (e.g. slow_start w/ linux fq/pacing) often produces
premature exit as well. I am curious if the authors have similar
experience?

Lastly, I am a fan of the BBR startup algorithm for obvious reasons.
The algorithm can be easily ported to produce an ssthresh for
conventional C.C.. It'd be great to see some words describing the
difference and even some real comparisons. BBR startup definitely
requires a lot more states (e.g. to track bw) for example. so there
are pros & cons.

On Wed, Apr 29, 2020 at 10:32 AM Martin Duke <[email-masked]> wrote:
> I would also encourage anyone in the WG thinking about implementing this draft to speak up. If this set is not null, I would encourage Praveen to move this draft to the Proposed Standard (preferred) or at least Experimental track.
>
> Martin
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Ian Swett <[email-masked]>
Date: Wed, 29 Apr 2020 15:46:58 -0400

+1 on adoption from me as well.

I'd be happy to implement this in our QUIC Cubic implementation(which is
still the default CC for Chrome QUIC).

---

From: Junho Choi <[email-masked]>
Date: Wed, 29 Apr 2020 14:57:18 -0700

Ian - I implemented for Cloudflare quiche:
https://github.com/cloudflare/quiche/pull/476

There is a minor difference due to TCP vs QUIC (see PR desciprion) but in
general it's easy to port and works well so far.

On Wed, Apr 29, 2020 at 12:47 PM Ian Swett <ianswett=
[email-masked]> wrote:

>> On Wed, Apr 29, 2020 at 10:32 AM Martin Duke <[email-masked]
>> <[email-masked]>> wrote:
>> >
>> > I would also encourage anyone in the WG thinking about implementing
>> this draft to speak up. If this set is not null, I would encourage Praveen
>> to move this draft to the Proposed Standard (preferred) or at least
>> Experimental track.
>> >
>> > Martin

-- 
Junho Choi <junho dot choi at gmail.com>

---

From: Vidhi Goel <[email-masked]>
Date: Wed, 29 Apr 2020 15:03:11 -0700

+1 for adoption. I plan to implement this in Apple QUIC which uses Cubic by default later this fall.

Vidhi

> On Apr 29, 2020, at 2:57 PM, Junho Choi <[email-masked]> wrote:
> 
> Ian - I implemented for Cloudflare quiche: https://github.com/cloudflare/quiche/pull/476 <https://github.com/cloudflare/quiche/pull/476>
> 
> There is a minor difference due to TCP vs QUIC (see PR desciprion) but in general it's easy to port and works well so far.
> 
> On Wed, Apr 29, 2020 at 12:47 PM Ian Swett <ianswett=[email-masked] <mailto:[email-masked]>> wrote:
> I'd be happy to implement this in our QUIC Cubic implementation(which is still the default CC for Chrome QUIC).
> 
> On Wed, Apr 29, 2020 at 3:10 PM Yuchung Cheng <ycheng=[email-masked] <mailto:[email-masked]>> wrote:
> +1 on adoption
> 
> two questions
> On Wed, Apr 29, 2020 at 10:32 AM Martin Duke <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>
> 
> 
> -- 
> Junho Choi <junho dot choi at gmail.com <http://gmail.com/>>

---

From: Yuchung Cheng <[email-masked]>
Date: Wed, 29 Apr 2020 15:08:49 -0700

btw it might be good to see the draft discusses applying it to other C.C.
that uses ssthresh too in the draft, particularly RFC5681 reno

---

From: Neal Cardwell <[email-masked]>
Date: Wed, 29 Apr 2020 22:30:05 -0400

I support adoption of this work as well. The HyStart++ algorithm has
some nice improvements over the original delay-based HyStart
mechanism.

The draft already seems to do a nice job of stating the algorithm
generically, without tying it to CUBIC. But I like Yuchung's idea to
explicitly state that the algorithm can be used for Reno or CUBIC.

neal

On Wed, Apr 29, 2020 at 6:09 PM Yuchung Cheng
<ycheng=[email-masked]> wrote:
>
> btw it might be good to see the draft discusses applying it to other C.C. that uses ssthresh too in the draft, particularly RFC5681 reno
>

---

From: Junho Choi <[email-masked]>
Date: Thu, 30 Apr 2020 00:09:11 -0700

FYI, my HyStart++ implementation for quiche is just an option for slow
start, so can be set for Reno and CUBIC both.

On Wed, Apr 29, 2020 at 7:30 PM Neal Cardwell <ncardwell=
[email-masked]> wrote:

> > btw it might be good to see the draft discusses applying it to other
> C.C. that uses ssthresh too in the draft, particularly RFC5681 reno
> >