From nobody Tue Jul 19 17:03:44 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 07D5BC14F72E for ; Tue, 19 Jul 2022 17:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.007 X-Spam-Level: X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi 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 ybiOJXn0nMm9 for ; Tue, 19 Jul 2022 17:03:38 -0700 (PDT) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DDE1C15A727 for ; Tue, 19 Jul 2022 17:03:37 -0700 (PDT) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Wed, 20 Jul 2022 03:03:19 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type:content-id; s=dkim20130528; bh=7+ukU7 ctKxLMHLDPkMsHHy+aJKU/SKwN65VhHWAOb3Y=; b=IL8h0XM0NmYNbV6pubpzWY zdOo9ef2i61TKEKY3NBMsG9SF+VXmGqrTHQicNkQNsUBSYp8HONHNdscN8XefG8y yXjHiONNh9e8sxzZ25x4ve/+ModRhaJiCCNb/+YBQmGvDlAvRhIN4RYgZAHOQZlW vspxSr6Xy6bmEucep6u9Y= Received: from hp8x-60 (85-76-46-2-nat.elisa-mobile.fi [85.76.46.2]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Wed, 20 Jul 2022 03:03:19 +0300 id 00000000005A011D.0000000062D74647.00003D3A Date: Wed, 20 Jul 2022 03:03:18 +0300 (EEST) From: Markku Kojo To: Vidhi Goel cc: Yuchung Cheng , "tcpm@ietf.org Extensions" , Neal Cardwell , Gorry Fairhurst In-Reply-To: <1A95963E-1BEB-4868-9C4F-0C75A4E5B904@apple.com> Message-ID: References: <31DCA869-30FA-41C6-B21F-3D71E600FFF2@apple.com> <1A95963E-1BEB-4868-9C4F-0C75A4E5B904@apple.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_script-15698-1658275399-0001-2" Content-ID: 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: Wed, 20 Jul 2022 00:03:43 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_script-15698-1658275399-0001-2 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Content-ID: 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 lis= t=20 so that anyone interested can more easily follow the discussion (jumping=20 back and worth between ML and github may become intractable). First, I want to stress that I am not expecting nor insisting to stick=20 with my proposed text (with necessary changes to address=20 the comments on the list) but it could possibly result in faster=20 conclusion(?). Second, I'd like to highlight that my proposed additional text was=20 intended just to bring up the caveats of simply using cwnd and give=20 advise that is in line with other standards track CC RFCs. It was not=20 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 becom= ing duplicate, I moved the below text a > few lines up and added a restriction for using cwnd directly. And the r= ecommendation to use RFC 7661 now > applies to both approaches. > Some implementations of CUBIC currently > use *cwnd*=C2=A0=E2=80=A6. >=20 >=20 > Here is the PR -=C2=A0https://github.com/NTAP/rfc8312bis/pull/148 >=20 > I would really appreciate if folks can review it so that we can close t= his issue before meeting at IETF 114 > next week. >=20 > Thanks, > Vidhi > > On Jul 17, 2022, at 8:33 AM, Yuchung Cheng wr= ote: >=20 > Glad we agree on improving the text. I think Vidhi will come up with a = good diff that captures our > discussion. >=20 > On Thu, Jul 14, 2022 at 4:47 PM Markku Kojo 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 d= oes 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 effect= ive > >>> 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 n= ot respond > >> to an arriving congestion signal effectively at all (and may e= ven > >> increase the cwnd). That is against the very basic rule in con= gestion > >> 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" c= heck to > >>> work w/ TSO chunking issue well. > >>> https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_o= utput.c#L1881 > >>> (Neal cc'd here is the inventor of the advanced check) > >> > >> I'm not sure I follow your logic. Doesn't that effectively res= trict cwnd > >> from growing beyond rwnd? To my understanding with that check = Linux > >> applies "other measures to avoid _cwnd_ from growing beyond th= e receive > >> window". It does not matter whether the conncetion is > >> receiver-application limited via rwnd or sender-application li= mited. If > >> rwnd limits flight size, cwnd will not grow more. Maybe I am m= issing > >> 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 u= se > > other measures to avoid _cwnd_ from growing beyond the receive = window" > > is easily interpreted as a line of code "cwnd =3D min(cwnd, rwn= d)" > > That was not the intent. So, I think we agree. > > > What I am saying is that this sentence is not necessary and ove= rly > > strict. Limiting cwnd growth based on inflight which is based o= n 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 the way = you > thought but still clearly involves the message that the sender ne= eds to > prevent cwnd to grow beyond rwnd. > > Maybe(?): > > =C2=A0 "... The implementations that use _cwnd_ MUST use [other|a= lternative] > =C2=A0 =C2=A0measures to not allow _cwnd_ to grow when bytes in f= light is > =C2=A0 =C2=A0smaller than cwnd_. That also effectively avoids _cw= nd_ from > =C2=A0 =C2=A0growing beyond the receive window. Such measures are = important > =C2=A0 =C2=A0to 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 is alr= eady 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 an= d we are mostly ok with it. > >>>> > >>>> > >>>> Vidhi > >>>> > >>>>> On Jul 11, 2022, at 5:37 PM, Markku Kojo wrote: > >>>>> > >>>>> Hi all, > >>>>> > >>>>> I promised to propose some text to some of the remaining is= sues. > >>>>> This thread starts the discussion on the issue 6 and propos= es text to solve the issue: > >>>>> > >>>>> Issue 6) Flightsize: > >>>>> > >>>>>=C2=A0 =C2=A0The current text in Sec 4.6 w.r.t using FlightS= ize vs. cwnd for > >>>>>=C2=A0 =C2=A0calculating multiplicative decrease is fine exc= ept that it does > >>>>>=C2=A0 =C2=A0not quite correcly reflect what stacks that use = cwnd instead of > >>>>>=C2=A0 =C2=A0flightsize should do and actually do. AFAIK and = what was > >>>>>=C2=A0 =C2=A0discussed in github all stacks apply some sort = of restrictions > >>>>>=C2=A0 =C2=A0to not allow cwnd to grow beyond rwnd and to no= t use an > >>>>>=C2=A0 =C2=A0arbitrarily high (old) cwnd value to calculate = new cwnd > >>>>>=C2=A0 =C2=A0when a congestion event occurs. > >>>>> > >>>>> > >>>>> Current text in Sec 4.6:: > >>>>> > >>>>>=C2=A0 Some implementations of CUBIC currently use _cwnd_ in= stead > >>>>>=C2=A0 of _flight_size_ when calculating a new _ssthresh_ us= ing Figure 5. > >>>>> > >>>>> Proposed new text: > >>>>> > >>>>>=C2=A0 Some implementations of CUBIC currently use _cwnd_ in= stead > >>>>>=C2=A0 of _flight_size_ when calculating a new _ssthresh_ us= ing Figure 5. > >>>>>=C2=A0 The implementations that use _cwnd_ MUST use other me= asures to > >>>>>=C2=A0 avoid _cwnd_ from growing beyond the receive window a= nd to not > >>>>>=C2=A0 allow _cwnd_ to grow when bytes in flight is smaller = than > >>>>>=C2=A0 _cwnd_. This prevents a CUBIC sender from using an ar= bitrarily > >>>>>=C2=A0 high _cwnd_ value in calculating the new value for _s= sthresh_ > >>>>>=C2=A0 and _cwnd_ when a congestion event is signalled, but = it is not > >>>>>=C2=A0 as robust as the mechanisms described in [RFC7661]. > >>>>>=C2=A0 [Many|Most|All] TCP implementations of CUBIC that use = _cwnd_ apply > >>>>>=C2=A0 such measures. Likewise, a QUIC sender that also uses = congestion > >>>>>=C2=A0 window to calculate a new value for the congestion wi= ndow and > >>>>>=C2=A0 slow-start threshold is required to apply similar mec= hanisms > >>>>>=C2=A0 [RFC 9002]. > >>>>> > >>>>> > >>>>> Any comments and help in formulating the text are welcome. > >>>>> > >>>>> Need also some guidance from TCP implementations of CUBIC t= o 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 > >>> > > >=20 >=20 >=20 > --=_script-15698-1658275399-0001-2--