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

I am happy with that formulation, but want community consensus for the
numbers (1 and infinity)

On Thu, Sep 8, 2022 at 2:12 PM <tuexen@fh-muenster.de> wrote:

> > On 8. Sep 2022, at 18:53, Martin Duke <martin.h.duke@gmail.com> wrote:
> >
> > Hi Neal, thanks for the data.
> >
> > Given its wide deployment, I'm happy for the spec to allow L_max =
> infinity, assuming the community is fine with it.
> So would you be happy with:
>
> The positive integer L SHOULD be 1 and MAY be larger than 1.
>
> Best regards
> Michael
> >
> > I don't care that much, in theory, whether L limits are defined in this
> document or in another one. However, in practice adding about 2 paragraphs
> to this document would allow us to obsolete 3465. If we can rapidly reach
> consensus on this, it seems like the expeditious thing to do.
> >
> > The alternative is to simply eliminate L from Hystart++, and we "really
> know" what people will do in production.
> >
> > On Thu, Sep 8, 2022 at 9:42 AM Neal Cardwell <ncardwell@google.com>
> wrote:
> >
> >
> > On Wed, Sep 7, 2022 at 5:46 PM <tuexen@fh-muenster.de> wrote:
> > > On 7. Sep 2022, at 22:44, Martin Duke <martin.h.duke@gmail.com> wrote:
> > >
> > >
> > >
> > > On Wed, Sep 7, 2022 at 1:15 PM <tuexen@fh-muenster.de> wrote:
> > > > On 7. Sep 2022, at 21:40, Martin Duke <martin.h.duke@gmail.com>
> 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.
> > Sure. My point was just that the results provided my MS show that L_MAX
> <= 8 seems to
> > be safe in the scenario they looked at. But there is no statement that
> L_MAX > 8 is
> > bad...
> > >
> > > 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.
> > My point was that there is no L_MAX given here.
> > >
> > > >
> > > > 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
> > Let us see if people provide data which values are good and which values
> are bad...
> >
> > FWIW, Linux TCP has been using L_MAX=infinity since 2013:
> >
> >
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9f9843a751d0a2
> >
> > IMHO trying to limit bursts with an L parameter is misguided:
> >
> > + AN L limit is only a partial solution; TCP RFCs still allow massive
> line-rate bursts of cwnd when restarting from idle, which is super-common
> in some very common Internet workloads: web traffic, streaming video, RPC.
> >
> > + To avoid such bursts, whether restarting from idle or not, TCP stacks
> should enable pacing.
> >
> > + Once pacing is enabled, having an L limit purely shoots your flow in
> the foot, causing it to fail to double cwnd each round trip in slow start
> in the very common case of the many ubiquitous aggregation mechanisms that
> cause ACKs to arrive for dozens of packets at a time (e.g.. Linux GRO/LRO
> commonly aggregate 45 packets into a single unit that is processed and
> ACKed as a unit).
> >
> > IMHO ideally burst control, pacing, and L limits should be separated
> from Hystart++, and should have their own RFC.
> >
> > And whatever is done, at a minimum Hystart++ should not depend on
> RFC3465 (ABC) (though it could mention it in passing to provide context).
> >
> > my two cents,
> > neal
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm
>
>