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

[Martin Duke <[e-mail]>]

On Wed, Sep 7, 2022 at 1:15 PM <[e-mail]> wrote:

> > On 7. Sep 2022, at 21:40, Martin Duke <[e-mail]> wrote:
> >
> > I would be happier with some sort of limit on L. Maybe: the positive
> integer L SHOULD be 2 and MUST be no more than 8(?) But whatever numbers
> the community is comfortable with are fine with me.
> Hi Martin,
>
> the crucial point here is that we know that MS used L = 8. But we don't
> have any information,
> whether other values of L are worse or better, what the tradeoffs are and
> in particular
> what traffic patterns impact the choice of L. Wouldn't we need such an
> analysis / results
> from an experiment for selecting an upper limit L_MAX? I would assume that
> it might
> have an impact whether pacing is used or not.
>

Well the community has at least some data that L = 8 is safe on the
internet. Maybe some other practitioners have data for 16 or 32 or
whatever. It would be reasonable to set some sort of limit based on the
limits of our empirical limit.

It would be fine to say "one SHOULD NOT exceed L = foo if you're not pacing"



> >
> > I'd also be happier with a cut-and-paste of those considerations from
> 3465, which should not be a lot of work.
> >
> > The lower-effort approach is just to strike L from the document and let
> people do what they've doing, which is use Ls well in excess of 2. But I'd
> prefer we'd actually write it down because
> > (1) our standards are better if they reflect widespread behavior in the
> internet; and
> I agree with the above.
> > (2) it means we can finally make 3465 historic, as we have
> standards-track documents that cover virtually all of its material.
> >
> > If the community really cannot converge on sensible limits for L, then
> I'd rather publish with no L than wait for a deadlock to resolve.
> In my view, the selection of L is not part of the core of the document.
>

This document standardizes a new slow start algorithm, which includes L as
a parameter, for which there is no standard.


> >
> > But as a way forward, I'd suggest:
> > 1) the authors propose text that sets bounds on L (a SHOULD and a MUST)
> and cut-and-pastes the considerations.
> Aren't the consideration in RFC 3465 coming to the conclusion: L SHOULD be
> 1, MAY be 2, MUST NOT be larger than 2?
> How to use the same considerations to come to a different conclusion: L
> SHOULD be 2, MUST NOT be larger than L_MAX
> for L_MAX > 2?
>

Re: SHOULD 1 or 2, I don't have a strong opinion but I feel like the 3465
experiment shows that 2 is safe, and somewhat beneficial given the
prevalence of ack thinning? If there is no consensus for this, I'm happy to
go with 1.

L_MAX: My preference is to set a value that is widely deployed with good
data that it is safe to do so


>
> Best regards
> Michael (as an individual)
> > 2) We do a consensus call on that in TCPM
> >
> > if we have less than rough consensus, we can consider next steps.
> >
> >
> > On Sat, Sep 3, 2022 at 2:50 AM <[e-mail]> wrote:
> > > On 3. Sep 2022, at 00:52, 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.
> > Hi Martin,
> >
> > I think the intention was (3), at least it was my intention.
> >
> > What about only doing (a) by:
> >
> > i) Remove
> >    The following pseudocode integrates Appropriate Byte Counting as
> >    described in [RFC3465].  In particular, see [RFC3465] for the
> >    definition of the variable L.
> > ii) After the first usage of L:
> >     Update the cwnd:
> >       cwnd = cwnd + min (N, L * SMSS)
> >     Add:
> >     The positive integer L SHOULD be 1 and MAY be larger than 1.
> >     See [RFC3465] for details of choosing L.
> >
> > That way we are  consistent with RFC 5681 and allow for higher values.
> > The text in Section 5 gives a clear hint that L > 1 has been used.
> > At least we used the above text in RFC 9260.
> > We could also use
> > See [RFC3465] for a discussion related to the choice of the value of L.
> > or just leave out the reference to RFC3465 at all. I guess people are
> > setting L differently anyway.
> >
> > What do you think?
> >
> > Best regards
> > Michael
> > >
> > > 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
> >
>
>