From nobody Thu Sep 8 14:24:35 2022 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA38C1533B0; Thu, 8 Sep 2022 14:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrLdXnG8iuzt; Thu, 8 Sep 2022 14:24:31 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF4C8C1533AD; Thu, 8 Sep 2022 14:24:30 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id cb8so2239qtb.0; Thu, 08 Sep 2022 14:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=t2BnE5KmnKHIbIJYJPsvHdrCxtgNJ+fxO+0r7CrGVq4=; b=cqjlLtZBZwPl9PPhOoYSQ2bBo9G9uIugINZ/MIR1wEJkcJwZsgVqpNXBPMBN+k8xO0 eSyA/m3xTVpU//JAoCZ9RM4Gl/9Wp9XtTXMBMBbGWgMy11NI8McGds4ZEZwf53+cRwYp JJXPaDe5ODHirY1M48R+KNg5P0Fm1/vt9BJg/rUFx0WB4AEHfceJKW/kEtBqEp46bCYc +CzWtJzBFAPcrMuvO50cTOXU4z0Qv99OX3eIrMe8MTcZyI5I2Cc/K3+C2cfv5LOSMunF ht2JW6UC0FE+KDePyfjyt81YZt/6MGiV/azdJYR8TIsaCA36bh6OecVkMrHc/hqNc/Wd HbPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=t2BnE5KmnKHIbIJYJPsvHdrCxtgNJ+fxO+0r7CrGVq4=; b=P/laDSi3jHS/emx0ohz9N7EoARIy35aO0732MDeTEVkCtPEG5GOFH0OUOmAl5jfLa/ G4EcebyxQvm2v6m/cSakvlVwypXxULQPomPcBMm651x83newQcA4LacHYoKquV8vCzLr yH/u5SBKs2ly5orCQpBKq1LmyJ34gmz4TKd29fJJne0nWOHa7aOAwWQUzvIlXskg3laB 8HuOCg5xRE0jX8zJOkjwS4rCpjMqYnEE5KXCkgw4PjGTT91YUxhyvN0orxuHK2/oR3/b PhU4xWneWP2qCinuTjr+qDnWO6iuT3SRzohBTilB7GJ6rnAva41fbMlfwMtNYN+sPgKb fEag== X-Gm-Message-State: ACgBeo1P8LOTDy9g17mPYe5PpYG3cyB5KXAJIO93BSCQeVGuPj9fvjOV pJgtpqTRi0//fMNqfsW+878jdjgm5Gl9xLilpLc= X-Google-Smtp-Source: AA6agR6+iG7iLCoo94dHExCCMJRgtG8FrUkd/x6dZ54jgIil5FqfB/hS29nfp6ZS1JCzlFko6Jbwd7GENogBpwXediY= X-Received: by 2002:ac8:7f53:0:b0:343:652:ce62 with SMTP id g19-20020ac87f53000000b003430652ce62mr9429940qtk.514.1662672270000; Thu, 08 Sep 2022 14:24:30 -0700 (PDT) MIME-Version: 1.0 References: <0E94A985-516C-4287-9789-50D3A682211B@fh-muenster.de> <741E2E66-0EC9-48E3-BF8E-4EFE000567D2@fh-muenster.de> In-Reply-To: From: Martin Duke Date: Thu, 8 Sep 2022 14:24:17 -0700 Message-ID: To: Michael Tuexen Cc: Neal Cardwell , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-hystartplusplus.all@ietf.org Content-Type: multipart/alternative; boundary="00000000000008076105e8310ef6" Archived-At: Subject: Re: [tcpm] AD Review of draft-ietf-tcpm-hystartplusplus-09 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2022 21:24:34 -0000 --00000000000008076105e8310ef6 Content-Type: text/plain; charset="UTF-8" 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 wrote: > > On 8. Sep 2022, at 18:53, Martin Duke 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 > wrote: > > > > > > On Wed, Sep 7, 2022 at 5:46 PM wrote: > > > On 7. Sep 2022, at 22:44, Martin Duke wrote: > > > > > > > > > > > > On Wed, Sep 7, 2022 at 1:15 PM wrote: > > > > On 7. Sep 2022, at 21:40, Martin Duke > 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 > > --00000000000008076105e8310ef6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am happy with that formulation, but want community conse= nsus for the numbers (1 and infinity)

<= div dir=3D"ltr" class=3D"gmail_attr">On Thu, Sep 8, 2022 at 2:12 PM <tuexen@fh-muenster.de> wrote:<= br>
> On 8. Sep 2= 022, 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 = =3D 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 parag= raphs to this document would allow us to obsolete 3465. If we can rapidly r= each 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 n= umbers the community is comfortable with are fine with me.
> > Hi Martin,
> >
> > the crucial point here is that we know that MS used L =3D 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 nee= d such an analysis / results
> > from an experiment for selecting an upper limit L_MAX? I would as= sume that it might
> > have an impact whether pacing is used or not.
> >
> > Well the community has at least some data that L =3D 8 is safe on= the internet. Maybe some other practitioners have data for 16 or 32 or wha= tever. 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_MA= X <=3D 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 =3D foo if = you're not pacing"
> >
> >=C2=A0
> > >
> > > I'd also be happier with a cut-and-paste of those consid= erations from 3465, which should not be a lot of work.
> > >
> > > The lower-effort approach is just to strike L from the docum= ent and let people do what they've doing, which is use Ls well in exces= s of 2. But I'd prefer we'd actually write it down because
> > > (1) our standards are better if they reflect widespread beha= vior in the internet; and
> > I agree with the above.
> > > (2) it means we can finally make 3465 historic, as we have s= tandards-track documents that cover virtually all of its material.
> > >
> > > If the community really cannot converge on sensible limits f= or L, then I'd rather publish with no L than wait for a deadlock to res= olve.
> > In my view, the selection of L is not part of the core of the doc= ument.
> >
> > This document standardizes a new slow start algorithm, which incl= udes L as a parameter, for which there is no standard.
> My point was that there is no L_MAX given here.
> >=C2=A0
> > >
> > > 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 conclus= ion: 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 l= ike 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 wi= th good data that it is safe to do so
> Let us see if people provide data which values are good and which valu= es are bad...
>
> FWIW, Linux TCP has been using L_MAX=3Dinfinity since 2013:
>
>=C2=A0 =C2=A0https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.= git/commit/?id=3D9f9843a751d0a2
>
> 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 i= n some very common Internet workloads: web traffic, streaming video, RPC. >
> + To avoid such bursts, whether restarting from idle or not, TCP stack= s 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 c= ommonly 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 f= rom Hystart++, and should have their own RFC.
>
> And whatever is done, at a minimum Hystart++ should not depend on RFC3= 465 (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

--00000000000008076105e8310ef6--