Re: [tcpm] AD Review of draft-ietf-tcpm-hystartplusplus-09

[Martin Duke <[e-mail]>]

A brief addendum regarding option 1 (eliminate L from the spec)

Even if RFC 3465 were standards track, it limits L to 2. So this draft's
current posture of "use-3465-with-hystart" is actually "use L=2 with
hystart" which not obviously any more germane to the L=8 data than just
using L=1.

On Fri, Sep 2, 2022 at 3:52 PM Martin Duke <[e-mail]> wrote:

> Thank you for this concise and very readable document.
>
> My only major concern is the old subject of RFC3465 (ABC) being
> Informative, but a downref if we make it Normative. In my opinion, the
> document as written is not implementable without 3465 and it should be a
> normative reference.
>
> If I am correct about the status quo, the only part of 3465 that is not in
> 5681 (and therefore still Experimental) is the use of L > 1 in slow start.
>
> There are three approaches to handling this problem.
>
> 1. Eliminate L from the spec, and use the RFC5681 slow start formula.
> What's bad about this is that IIUC we have no data with L=1. But we could
> say in Section 5 that the tests also used RFC 3465 with L=8 and the market
> decide what to do with that.
>
> 2. Send to the RFC Editor with a normative reference; the doc will be
> "done", but will not publish until ABC goes to PS (which is not imminent,
> to say the least).
>
> 3. What I think you've actually done here is standardized RFC3465 behavior
> only when combined with CSS (i.e. a partial promotion of ABC). I think this
> is the best course of action, but if we're going to do that, we should go
> all the way:
>
> (a) Add a definition of L and a discussion of how to set it -- basically
> Sec 2.3 of RFC3465 but presumably with no L=2 limit. If we're going to
> publish a standard with a higher cap on L we really ought to have that
> discussion.
>
> (b) It can "update" or "obsolete" 3465 depending on whether or not the WG
> cares to keep the experimental status of ABC-without-CSS.
>
> The community apparently has consensus that L > 1, even L >  2, *in this
> context* is safe, so I don't see it as reckless to make this change.
>
> I'm happy to have a dialogue about this.
>
> NITS:
> (3) s/definition/definitions
>
> (4.1) "The Inter Packet Arrival algorithm does not perform well." If
> there's a useful citation here (or for the results discussed in Section 5)
> that would be nice to include.
>
> (4.1) s/it's concluded that/the algorithm concludes
>
> Thanks again!
> Martin
>