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

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

On Wed, Apr 29, 2020 at 12:09 PM Yuchung Cheng <ycheng@google.com> wrote:

> +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 <martin.h.duke@gmail.com>
> wrote:
> >
> > 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
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm
>