From nobody Fri Jul 29 10:13:09 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 7899BC15A732 for ; Fri, 29 Jul 2022 10:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.605 X-Spam-Level: X-Spam-Status: No, score=-17.605 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, 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, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 3_ndOF0PcY92 for ; Fri, 29 Jul 2022 10:13:04 -0700 (PDT) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 9BF0EC15A72F for ; Fri, 29 Jul 2022 10:13:04 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id c22so2865302wmr.2 for ; Fri, 29 Jul 2022 10:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=81CvW9U2d7O+YlMSwq/vmNAzIieItImmUGgUOY2oAvo=; b=YISkZ7lf1BmafEP25cd9q+OavIWiFzCR3MWz1aMo5FCutblcmDcqLhS8KJH++kO511 MrKXI4VQ5OnrV/0BfUQf62f0e09Mu6X4z/XBaIm4bVMQeZXtBzhwPX4iWTyDpVtXVYGy yg4kyWsPFEPXxwJGmZb5zvdYOvbgg68UxegY/OTPxYXc9bYu8eDzEsBMO4di83JEgF3t 1je2CxFTRwrZhDgE0HnMMPjPPcZGHOlZ8JYQFbV/F+UBRM8UU9WiwMjNpwpaZ9mbaG8i 2TPQYmamWWIWlmdajZ4Rocak4f9i3shTGiOHScSx6QCXzqHOBOMHO5DKFkamG97XMWvW I3hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=81CvW9U2d7O+YlMSwq/vmNAzIieItImmUGgUOY2oAvo=; b=qlQPn5fskK2lH+mGXQivbe4qpSObXtAJyh5W6pORivroGg8e2dWlgpZIYTR8+xAmCk lS1VSCUxtSMyEgWgqw32hGXNrV7IylG62ca6YPnZJ1u5s5kdjLNmogrQCuUj6L8X5Ahm 8qFbQEKrPG3DftrlJagyfHM7zBWtfJ9fOsp9trO7UepPpONgzDA3/dwZEH5/M0X5zLe3 c0j/Do5VTImyGqzDv85C/3P7Du1mtzmoQdeTPSM/c/2qD7GQhsy93qISgCU3Eu4pg2bf aY1IEHTuoKrdfmn3Bl2PFxtnGDTXk7Rze6hmxoQr//m7mLFwP3YPCxijGCycpc040rKs frgw== X-Gm-Message-State: AJIora91dPT72MDc7aGBfFSh21EERD6FwylyB5+yK0Tn3ggNBBaTp5Rn RUpNDeFbQ+lj1TypHrZ/7KoNODCP9YZcv4ir0nEDfg== X-Google-Smtp-Source: AGRyM1t99Be4iHuDq6btQIHs7yh+bKqbgqhnnEl1hjDDOAQQyGL0UxNCj5XlY/XpPl+qrdp93eA9k1d3TJaV5FVCdIY= X-Received: by 2002:a05:600c:154c:b0:3a3:4383:e13f with SMTP id f12-20020a05600c154c00b003a34383e13fmr3114272wmg.16.1659114782816; Fri, 29 Jul 2022 10:13:02 -0700 (PDT) MIME-Version: 1.0 References: <391FCCC9-5653-4F0F-8C5F-73B1B4A997AF@apple.com> In-Reply-To: From: Yuchung Cheng Date: Fri, 29 Jul 2022 10:12:52 -0700 Message-ID: To: Markku Kojo Cc: Vidhi Goel , "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="0000000000004635c905e4f4c369" Archived-At: Subject: Re: [tcpm] CUBIC rfc8312bis / WGLC Issue 6 and proposed text 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: Fri, 29 Jul 2022 17:13:08 -0000 --0000000000004635c905e4f4c369 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The latest text looks good to me. On Thu, Jul 28, 2022, 3:29 PM Markku Kojo wrote: > Hi Vidhi, > > On Thu, 28 Jul 2022, Vidhi Goel wrote: > > > > > > > Hi Markku, > > Can you review the PR? As I have adopted the change that you suggested, > it might be an easy one. We would like to converge on > > this soon. > > I'm fine with the text except the sentence that I spotted only after > re-reading the text later and already commented on the wg mailing list: > > "the mechanisms described in [RFC7661] can be used to mitigate this > issue as it would allow using a value between _cwnd_ and > _flight_size_ to calculate the new _ssthresh_ in Figure 5." > > AFAIK "using a value between _cwnd_ and _flight_size_ to calculate the ne= w > _ssthresh_" does not correctly capture the algo in RFC 7661. In the > non-validated RFC 7661 uses > > (Max(pipeACK,LossFlightSize))/2 > > and adjusts it with R (=3Dretransmitted data) in the end of recovery phas= e. > And, in the validated phase RFC 7661 uses FlightSize/2. > > It would be good to have Gorry to review this piece of text as the text > seems to have been modified from what Gorry originally wrote. > > Good to check that Yuchung also is fine with all the latest text. > > Thanks, > > /Markku > > > > > > [png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABAQMAAAAl21bKAAAAA1BMVEUAAACne= j3aAAAAAXRSTlMAQObYZgAAAApJREFUCNdjYAAAAAIAAeIhvDMAA > > AAASUVORK5CYII=3D] > > restrict use of cwnd directly on a congestion event by goelvidhi =C2=B7= Pull > Request #148 =C2=B7 NTAP/rfc8312bis > > github.com > > > > > > Thanks, > > Vidhi > > > > On Jul 24, 2022, at 2:09 PM, Vidhi Goel > wrote: > > > > =EF=BB=BFHi Markku, > > I have updated the PR with your suggested text to converge faster. Can > you take a look > > - https://github.com/NTAP/rfc8312bis/pull/148/ > > > > Vidhi > > > > On Jul 19, 2022, at 8:03 PM, Markku Kojo 40cs.helsinki.fi@dmarc.ietf.org> wrote: > > > > Hi Vidhi (Cc'ing also Gorry because he has better insight into RFC 7661= ), > > > > Thanks for the text. I'll reply here to keep the discussion on the wg > list so that anyone interested can more > > easily follow the discussion (jumping back and worth between ML and > github may become intractable). > > > > First, I want to stress that I am not expecting nor insisting to stick > with my proposed text (with necessary > > changes to address the comments on the list) but it could possibly > result in faster conclusion(?). > > > > Second, I'd like to highlight that my proposed additional text was > intended just to bring up the caveats of simply > > using cwnd and give advise that is in line with other standards track C= C > RFCs. It was not intended to specify any > > algorithm (or a part of an algorithm). > > > > The new text in github IMO has the following issues: > > > > 1. It does not mention the caveat of letting cwnd to grow > > beyond rwnd which is a known implementation problem in > > the past (so it can easily be repeated by some new > > implementors) nor does it explain why simply using > > cwnd is incorrect. > > > > 2. Even though this draft is intended to be applicable > > with QUIC, it misses the pointer to RFC 9002 that > > articulates the corresponding requirement for QUIC. > > > > 3. It tries to create an ad-hoc algorithm in a single > > sentence that captures the RFC 7661 algorithm for > > those using cwnd. RFC 7661 is some 20 pages of which > > several pages are used to specify the algorithm. > > That is, the proposed text ignores several crucial > > actions of RFC 7661. And, my proposal was not to > > provide an algorithm for those using cwnd. > > > > 4. The sentence / rule "when flight_size is less than 1/2 > > of the cwnd" is not capturing what was discussed earlier > > in github and now on the wg list, and it is also in > > conflict with RFC 9002 and effectively also with RFC > > 5681. None of these effectively allows the sender not > > reacting to a congestion event but the "new" rule would > > allow it once the cwnd has grown more than 43% above the > > flightsize. > > > > Apologies for finding so many issues with the proposed text. > > > > Thanks, > > > > /Markku > > > > On Sun, 17 Jul 2022, Vidhi Goel wrote: > > > > Thank you everyone for the discussion. Since some of the text was > becoming duplicate, I moved the > > below text a > > few lines up and added a restriction for using cwnd directly. And > the recommendation to use RFC 7661 > > now > > applies to both approaches. > > Some implementations of CUBIC currently > > use *cwnd* =E2=80=A6. > > Here is the PR - https://github.com/NTAP/rfc8312bis/pull/148 > > I would really appreciate if folks can review it so that we can > close this issue before meeting at > > IETF 114 > > next week. > > Thanks, > > Vidhi > > > > On Jul 17, 2022, at 8:33 AM, Yuchung Cheng > wrote: > > Glad we agree on improving the text. I think Vidhi will come up > with a good diff that captures our > > discussion. > > On Thu, Jul 14, 2022 at 4:47 PM Markku Kojo 40cs.helsinki.fi@dmarc.ietf.org> wrote: > > On Thu, 14 Jul 2022, Yuchung Cheng wrote: > > > > > On Thu, Jul 14, 2022 at 4:12 PM Markku Kojo > > > wrote: > > >> > > >> Hi Yuchung, > > >> > > >> On Tue, 12 Jul 2022, Yuchung Cheng wrote: > > >> > > >>> AFAIK, the latest (and previous) Linux Cubic > implementation does not follow > > >>> "The implementations that use _cwnd_ MUST use other > measures to avoid > > >>> _cwnd_ from growing beyond the receive window" > > >>> > > >>> I don't see the need to add that check in Linux as the > effective > > >>> window is always the min of cwnd and rwnd. > > >> > > >> That does not help. If cwnd is allowed to grow way beyond > rwnd (more than > > >> 43% for CUBIC or more than 100% for Reno CC), a sender > would not respond > > >> to an arriving congestion signal effectively at all (and > may even > > >> increase the cwnd). That is against the very basic rule i= n > congestion > > >> control principles we have. > > >> > > >>> On the other hand, Linux does restrict cwnd growth if > flight size is > > >>> below cwnd but the > > >>> actual logic is more sophisticated than a "cwnd < > inflight" check to > > >>> work w/ TSO chunking issue well. > > >>> > https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_output.c#L188= 1 > > >>> (Neal cc'd here is the inventor of the advanced check) > > >> > > >> I'm not sure I follow your logic. Doesn't that effectivel= y > restrict cwnd > > >> from growing beyond rwnd? To my understanding with that > check Linux > > >> applies "other measures to avoid _cwnd_ from growing > beyond the receive > > >> window". It does not matter whether the conncetion is > > >> receiver-application limited via rwnd or > sender-application limited. If > > >> rwnd limits flight size, cwnd will not grow more. Maybe I > am missing > > >> something? > > > That's right. Limiting cwnd growth on flight size > automatically > > > prevents cwnd goes far beyond rwnd for the congestion case > you are > > > concerned about. > > > > > > Your suggested text "The implementations that use _cwnd_ > MUST use > > > other measures to avoid _cwnd_ from growing beyond the > receive window" > > > is easily interpreted as a line of code "cwnd =3D min(cwnd= , > rwnd)" > > > > That was not the intent. So, I think we agree. > > > > > What I am saying is that this sentence is not necessary an= d > overly > > > strict. Limiting cwnd growth based on inflight which is > based on the > > > effective sending window (=3D min(cwnd, rwnd)) already > prevents cwnd > > > bloats over rwnd. > > > > Sure, I misinterepted your previous text ;) > > > > > I don't see why Cubic needs to have more strict > > > rules than other C.C.s. > > > > It does not have to be more strict rule. So, to my > understanding we just > > need to tweak the text such that it is not misinterpreted th= e > way you > > thought but still clearly involves the message that the > sender needs to > > prevent cwnd to grow beyond rwnd. > > > > Maybe(?): > > > > "... The implementations that use _cwnd_ MUST use > [other|alternative] > > measures to not allow _cwnd_ to grow when bytes in flight > is > > smaller than cwnd_. That also effectively avoids _cwnd_ > from > > growing beyond the receive window. Such measures are > important > > to prevent a CUBIC sender from using an arbitrarily ..." > > > > Thanks, > > > > /Markku > > > > >> > > >> Thanks, > > >> > > >> /Markku > > >> > > >>> Just want to reflect a major implementation status. > > >>> > > >>> > > >>> On Tue, Jul 12, 2022 at 2:01 PM Vidhi Goel > > >>> wrote: > > >>>> > > >>>> Thank you Markku for proposing the text. Some of this i= s > already covered in the latest > > draft but I can do some edits to your proposed text and > create a PR. > > >>>> I spoke to other co-authors about this suggestion as > well and we are mostly ok with it. > > >>>> > > >>>> > > >>>> Vidhi > > >>>> > > >>>>> On Jul 11, 2022, at 5:37 PM, Markku Kojo 40cs.helsinki.fi@dmarc.ietf.org> wrote: > > >>>>> > > >>>>> Hi all, > > >>>>> > > >>>>> I promised to propose some text to some of the > remaining issues. > > >>>>> This thread starts the discussion on the issue 6 and > proposes text to solve the issue: > > >>>>> > > >>>>> Issue 6) Flightsize: > > >>>>> > > >>>>> The current text in Sec 4.6 w.r.t using FlightSize > vs. cwnd for > > >>>>> calculating multiplicative decrease is fine except > that it does > > >>>>> not quite correcly reflect what stacks that use cwnd > instead of > > >>>>> flightsize should do and actually do. AFAIK and what > was > > >>>>> discussed in github all stacks apply some sort of > restrictions > > >>>>> to not allow cwnd to grow beyond rwnd and to not use > an > > >>>>> arbitrarily high (old) cwnd value to calculate new > cwnd > > >>>>> when a congestion event occurs. > > >>>>> > > >>>>> > > >>>>> Current text in Sec 4.6:: > > >>>>> > > >>>>> Some implementations of CUBIC currently use _cwnd_ > instead > > >>>>> of _flight_size_ when calculating a new _ssthresh_ > using Figure 5. > > >>>>> > > >>>>> Proposed new text: > > >>>>> > > >>>>> Some implementations of CUBIC currently use _cwnd_ > instead > > >>>>> of _flight_size_ when calculating a new _ssthresh_ > using Figure 5. > > >>>>> The implementations that use _cwnd_ MUST use other > measures to > > >>>>> avoid _cwnd_ from growing beyond the receive window > and to not > > >>>>> allow _cwnd_ to grow when bytes in flight is smaller > than > > >>>>> _cwnd_. This prevents a CUBIC sender from using an > arbitrarily > > >>>>> high _cwnd_ value in calculating the new value for > _ssthresh_ > > >>>>> and _cwnd_ when a congestion event is signalled, but > it is not > > >>>>> as robust as the mechanisms described in [RFC7661]. > > >>>>> [Many|Most|All] TCP implementations of CUBIC that use > _cwnd_ apply > > >>>>> such measures. Likewise, a QUIC sender that also uses > congestion > > >>>>> window to calculate a new value for the congestion > window and > > >>>>> slow-start threshold is required to apply similar > mechanisms > > >>>>> [RFC 9002]. > > >>>>> > > >>>>> > > >>>>> Any comments and help in formulating the text are > welcome. > > >>>>> > > >>>>> Need also some guidance from TCP implementations of > CUBIC to finish up the second but > > last sentence. > > >>>>> > > >>>>> Thanks, > > >>>>> > > >>>>> /Markku > > >>>>> > > >>>>> _______________________________________________ > > >>>>> tcpm mailing list > > >>>>> tcpm@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/tcpm > > >>>> > > >>>> _______________________________________________ > > >>>> tcpm mailing list > > >>>> tcpm@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/tcpm > > >>> > > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > > > > > >_______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --0000000000004635c905e4f4c369 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The latest text looks good to me.=C2=A0

On Thu, Jul 28, 20= 22, 3:29 PM Markku Kojo <kojo=3D40cs.helsinki.fi@dmarc.ietf.org> wrote:
Hi Vidhi,

On Thu, 28 Jul 2022, Vidhi Goel wrote:

>
>
> Hi Markku,
> Can you review the PR? As I have adopted the change that you suggested= , it might be an easy one. We would like to converge on
> this soon.

I'm fine with the text except the sentence that I spotted only after re-reading the text later and already commented on the wg mailing list:

=C2=A0 "the mechanisms described in [RFC7661] can be used to mitigate = this
=C2=A0 =C2=A0issue as it would allow using a value between _cwnd_ and
=C2=A0 =C2=A0_flight_size_ to calculate the new _ssthresh_ in Figure 5.&quo= t;

AFAIK "using a value between _cwnd_ and _flight_size_ to calculate the= new
_ssthresh_" does not correctly capture the algo in RFC 7661. In the non-validated RFC 7661 uses

=C2=A0 (Max(pipeACK,LossFlightSize))/2

and adjusts it with R (=3Dretransmitted data) in the end of recovery phase.=
And, in the validated phase RFC 7661 uses FlightSize/2.

It would be good to have Gorry to review this piece of text as the text seems to have been modified from what Gorry originally wrote.

Good to check that Yuchung also is fine with all the latest text.

Thanks,

/Markku



> [png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABAQMAAAAl21bKAAAAA1BMVEUAAA= Cnej3aAAAAAXRSTlMAQObYZgAAAApJREFUCNdjYAAAAAIAAeIhvDMAA
> AAASUVORK5CYII=3D]
> restrict use of cwnd directly on a congestion event by goelvidhi =C2= =B7 Pull Request #148 =C2=B7 NTAP/rfc8312bis
> github.com
>
>
> Thanks,
> Vidhi
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0On Jul 24, 2022, at 2:09 PM, Vidhi Goel <= vidhi_goel@apple.com> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=EF=BB=BFHi Markku,
> I have updated the PR with your suggested text to converge faster. Can= you take a look
> -=C2=A0https://github.com/NTAP/rfc8312bi= s/pull/148/
>
> Vidhi
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0On Jul 19, 2022, at 8:03 PM, Markku Kojo <= ;kojo=3D40cs.helsinki.fi@dmarc.ietf.org> wrote:
>
> Hi Vidhi (Cc'ing also Gorry because he has better insight into RFC= 7661),
>
> Thanks for the text. I'll reply here to keep the discussion on the= wg list so that anyone interested can more
> easily follow the discussion (jumping back and worth between ML and gi= thub may become intractable).
>
> First, I want to stress that I am not expecting nor insisting to stick= with my proposed text (with necessary
> changes to address the comments on the list) but it could possibly res= ult in faster conclusion(?).
>
> Second, I'd like to highlight that my proposed additional text was= intended just to bring up the caveats of simply
> using cwnd and give advise that is in line with other standards track = CC RFCs. It was not intended to specify any
> algorithm (or a part of an algorithm).
>
> The new text in github IMO has the following issues:
>
> 1. It does not mention the caveat of letting cwnd to grow
> =C2=A0=C2=A0beyond rwnd which is a known implementation problem in
> =C2=A0=C2=A0the past (so it can easily be repeated by some new
> =C2=A0=C2=A0implementors) nor does it explain why simply using
> =C2=A0=C2=A0cwnd is incorrect.
>
> 2. Even though this draft is intended to be applicable
> =C2=A0=C2=A0with QUIC, it misses the pointer to RFC 9002 that
> =C2=A0=C2=A0articulates the corresponding requirement for QUIC.
>
> 3. It tries to create an ad-hoc algorithm in a single
> =C2=A0=C2=A0sentence that captures the RFC 7661 algorithm for
> =C2=A0=C2=A0those using cwnd. RFC 7661 is some 20 pages of which
> =C2=A0=C2=A0several pages are used to specify the algorithm.
> =C2=A0=C2=A0That is, the proposed text ignores several crucial
> =C2=A0=C2=A0actions of RFC 7661. And, my proposal was not to
> =C2=A0=C2=A0provide an algorithm for those using cwnd.
>
> 4. The sentence / rule "when flight_size is less than 1/2
> =C2=A0=C2=A0of the cwnd" is not capturing what was discussed earl= ier
> =C2=A0=C2=A0in github and now on the wg list, and it is also in
> =C2=A0=C2=A0conflict with RFC 9002 and effectively also with RFC
> =C2=A0=C2=A05681. None of these effectively allows the sender not
> =C2=A0=C2=A0reacting to a congestion event but the "new" rul= e would
> =C2=A0=C2=A0allow it once the cwnd has grown more than 43% above the > =C2=A0=C2=A0flightsize.
>
> Apologies for finding so many issues with the proposed text.
>
> Thanks,
>
> /Markku
>
> On Sun, 17 Jul 2022, Vidhi Goel wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Thank you everyone for the discussion. Since= some of the text was becoming duplicate, I moved the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0below text a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0few lines up and added a restriction for usi= ng cwnd directly. And the recommendation to use RFC 7661
>=C2=A0 =C2=A0 =C2=A0 =C2=A0now
>=C2=A0 =C2=A0 =C2=A0 =C2=A0applies to both approaches.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Some implementations of CUBIC currently
>=C2=A0 =C2=A0 =C2=A0 =C2=A0use *cwnd*=C2=A0=E2=80=A6.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Here is the PR -=C2=A0https://github.com/NTAP/rfc8312bis/pull/148
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I would really appreciate if folks can revie= w it so that we can close this issue before meeting at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0IETF 114
>=C2=A0 =C2=A0 =C2=A0 =C2=A0next week.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Vidhi
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0On Jul 17, 202= 2, at 8:33 AM, Yuchung Cheng <ycheng@google.com> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Glad we agree on improving the text. I think= Vidhi will come up with a good diff that captures our
>=C2=A0 =C2=A0 =C2=A0 =C2=A0discussion.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0On Thu, Jul 14, 2022 at 4:47 PM Markku Kojo = <kojo=3D40cs.helsinki.fi@dmarc.ietf.org> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0On Thu, 14 Jul= 2022, Yuchung Cheng wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> On Thu, J= ul 14, 2022 at 4:12 PM Markku Kojo
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> <kojo= =3D40cs.helsinki.fi@dmarc.ietf.org> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>> Hi Yu= chung,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>> On Tu= e, 12 Jul 2022, Yuchung Cheng wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>> A= FAIK, the latest (and previous) Linux Cubic implementation does not follow<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>> &= quot;The implementations that use _cwnd_ MUST use other measures to avoid >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>> _= cwnd_ from growing beyond the receive window"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>> I= don't see the need to add that check in Linux as the effective
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>> w= indow is always the min of cwnd and rwnd.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>> That = does not help. If cwnd is allowed to grow way beyond rwnd (more than
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>> 43% f= or CUBIC or more than 100% for Reno CC), a sender would not respond
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>> to an= arriving congestion signal effectively at all (and may even
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>> incre= ase the cwnd). That is against the very basic rule in congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>> contr= ol principles we have.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>> O= n the other hand, Linux does restrict cwnd growth if flight size is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>> b= elow cwnd but the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>> a= ctual logic is more sophisticated than a "cwnd < inflight" che= ck to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>> w= ork w/ TSO chunking issue well.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>> <= a href=3D"https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_outpu= t.c#L1881" rel=3D"noreferrer noreferrer" target=3D"_blank">https://elixir.b= ootlin.com/linux/latest/source/net/ipv4/tcp_output.c#L1881
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>> (= Neal cc'd here is the inventor of the advanced check)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>> I'= ;m not sure I follow your logic. Doesn't that effectively restrict cwnd=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>> from = growing beyond rwnd? To my understanding with that check Linux
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>> appli= es "other measures to avoid _cwnd_ from growing beyond the receive
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>> windo= w". It does not matter whether the conncetion is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>> recei= ver-application limited via rwnd or sender-application limited. If
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>> rwnd = limits flight size, cwnd will not grow more. Maybe I am missing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>> somet= hing?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> That'= s right. Limiting cwnd growth on flight size automatically
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> prevents = cwnd goes far beyond rwnd for the congestion case you are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> concerned= about.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> Your sugg= ested text "The implementations that use _cwnd_ MUST use
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> other mea= sures to avoid _cwnd_ from growing beyond the receive window"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> is easily= interpreted as a line of code "cwnd =3D min(cwnd, rwnd)"
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0That was not t= he intent. So, I think we agree.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> What I am= saying is that this sentence is not necessary and overly
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> strict. L= imiting cwnd growth based on inflight which is based on the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> effective= sending window (=3D min(cwnd, rwnd)) already prevents cwnd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> bloats ov= er rwnd.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Sure, I misint= erepted your previous text ;)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> I don'= ;t see why Cubic needs to have more strict
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0> rules tha= n other C.C.s.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0It does not ha= ve to be more strict rule. So, to my understanding we just
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0need to tweak = the text such that it is not misinterpreted the way you
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0thought but st= ill clearly involves the message that the sender needs to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0prevent cwnd t= o grow beyond rwnd.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Maybe(?):
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ".= .. The implementations that use _cwnd_ MUST use [other|alternative]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0m= easures to not allow _cwnd_ to grow when bytes in flight is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0s= maller than cwnd_. That also effectively avoids _cwnd_ from
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0g= rowing beyond the receive window. Such measures are important
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0t= o prevent a CUBIC sender from using an arbitrarily ..."
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Thanks,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0/Markku
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>> Thank= s,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>> /Mark= ku
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>> J= ust want to reflect a major implementation status.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>> O= n Tue, Jul 12, 2022 at 2:01 PM Vidhi Goel
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>> &= lt;vidhi_goel=3D40apple.com@dmarc.ietf.org> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t; Thank you Markku for proposing the text. Some of this is already covered= in the latest
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0draft but I ca= n do some edits to your proposed text and create a PR.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t; I spoke to other co-authors about this suggestion as well and we are mos= tly ok with it.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t; Vidhi
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;> On Jul 11, 2022, at 5:37 PM, Markku Kojo <kojo=3D40c= s.helsinki.fi@dmarc.ietf.org> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;> Hi all,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;> I promised to propose some text to some of the remaining issues.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;> This thread starts the discussion on the issue 6 and proposes text t= o solve the issue:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;> Issue 6) Flightsize:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>=C2=A0 =C2=A0The current text in Sec 4.6 w.r.t using FlightSize vs. c= wnd for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>=C2=A0 =C2=A0calculating multiplicative decrease is fine except that = it does
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>=C2=A0 =C2=A0not quite correcly reflect what stacks that use cwnd ins= tead of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>=C2=A0 =C2=A0flightsize should do and actually do. AFAIK and what was=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>=C2=A0 =C2=A0discussed in github all stacks apply some sort of restri= ctions
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>=C2=A0 =C2=A0to not allow cwnd to grow beyond rwnd and to not use an<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>=C2=A0 =C2=A0arbitrarily high (old) cwnd value to calculate new cwnd<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>=C2=A0 =C2=A0when a congestion event occurs.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;> Current text in Sec 4.6::
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>=C2=A0 Some implementations of CUBIC currently use _cwnd_ instead
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>=C2=A0 of _flight_size_ when calculating a new _ssthresh_ using Figur= e 5.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;> Proposed new text:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>=C2=A0 Some implementations of CUBIC currently use _cwnd_ instead
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>=C2=A0 of _flight_size_ when calculating a new _ssthresh_ using Figur= e 5.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>=C2=A0 The implementations that use _cwnd_ MUST use other measures to=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>=C2=A0 avoid _cwnd_ from growing beyond the receive window and to not=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>=C2=A0 allow _cwnd_ to grow when bytes in flight is smaller than
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>=C2=A0 _cwnd_. This prevents a CUBIC sender from using an arbitrarily=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>=C2=A0 high _cwnd_ value in calculating the new value for _ssthresh_<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>=C2=A0 and _cwnd_ when a congestion event is signalled, but it is not=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>=C2=A0 as robust as the mechanisms described in [RFC7661].
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>=C2=A0 [Many|Most|All] TCP implementations of CUBIC that use _cwnd_ a= pply
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>=C2=A0 such measures. Likewise, a QUIC sender that also uses congesti= on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>=C2=A0 window to calculate a new value for the congestion window and<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>=C2=A0 slow-start threshold is required to apply similar mechanisms >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>=C2=A0 [RFC 9002].
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;> Any comments and help in formulating the text are welcome.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;> Need also some guidance from TCP implementations of CUBIC to finish = up the second but
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0last sentence.=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;> Thanks,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;> /Markku
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;> _______________________________________________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;> tcpm mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;> tcpm@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;> https://www.ietf.org/mailman/listinfo/tc= pm
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t; _______________________________________________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t; tcpm mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t; tc= pm@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>>&g= t; https://www.ietf.org/mailman/listinfo/tcpm
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0>
>
> _______________________________________________
> tcpm mailing list
> = tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm=
>
>
>
>_______________________________________________
tcpm mailing list
tcpm@= ietf.org
https://www.ietf.org/mailman/listinfo/tcpm<= br>
--0000000000004635c905e4f4c369--