Re: [tcpm] CUBIC rfc8312bis / WGLC Issue 6 and proposed text
Vidhi Goel <vidhi_goel@apple.com> Mon, 18 July 2022 02:18 UTC
Return-Path: <vidhi_goel@apple.com>
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 DA776C159496 for <tcpm@ietfa.amsl.com>; Sun, 17 Jul 2022 19:18:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.686
X-Spam-Level:
X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.582, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 ySXjTFI4cKxp for <tcpm@ietfa.amsl.com>; Sun, 17 Jul 2022 19:18:02 -0700 (PDT)
Received: from rn-mailsvcp-ppex-lapp15.apple.com (rn-mailsvcp-ppex-lapp15.rno.apple.com [17.179.253.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BA50C15948C for <tcpm@ietf.org>; Sun, 17 Jul 2022 19:18:02 -0700 (PDT)
Received: from pps.filterd (rn-mailsvcp-ppex-lapp15.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp15.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 26I2G6X9004763; Sun, 17 Jul 2022 19:17:57 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=ZFksc7xM+ThnGCtqyQ4epEJ6zPF4r6t5iXTQewVgs8w=; b=fOvX//gy5k7ERvlw0UUTqtDobISSDiTtHtgvRHDtsTvts0IHNb2H2GlM/3v0jUND1I9T 8IKdWIUWZZ2GSoNRlt6HYYMUz5icUeLCb8lFGOOT9AmmHPpM/1t+FK9BhWIb23PtV8Qs M0IqpMp4ACnN1e6nmPILlCUZ+M+b2XnwxfpHzHqGda5RWU2gK2ZUQWfYDdpDZQAbKC6m 97AgnQSHZeUZ9CpiUG5h6Wz0Dqqg8RBIndUJVfKmonK/0JPXy6jbD2L9wMcFLNrty+1w CDly0qMnTkPuIcNTIlYEPZZAH9sUjYZsFrIZbAcWouIqkAMUs04N/+77w44omORhjIvN Og==
Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by rn-mailsvcp-ppex-lapp15.rno.apple.com with ESMTP id 3hcdg5e2fh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 17 Jul 2022 19:17:57 -0700
Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) with ESMTPS id <0RF700FXF2DX2A20@rn-mailsvcp-mta-lapp02.rno.apple.com>; Sun, 17 Jul 2022 19:17:57 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) id <0RF700Y00269YB00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Sun, 17 Jul 2022 19:17:57 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 416c79a5095c152c5612f4e7195632ea
X-Va-E-CD: 41fd44ac25f22bdcc0fda8fbd071d110
X-Va-R-CD: 3f4bfd29cf6328474e486f6f244c64e7
X-Va-CD: 0
X-Va-ID: fa35fc97-9344-4c7a-832e-9f57628511e1
X-V-A:
X-V-T-CD: 416c79a5095c152c5612f4e7195632ea
X-V-E-CD: 41fd44ac25f22bdcc0fda8fbd071d110
X-V-R-CD: 3f4bfd29cf6328474e486f6f244c64e7
X-V-CD: 0
X-V-ID: 7414b213-ed99-4000-a7bd-da0480fe1a0c
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517, 18.0.883 definitions=2022-07-18_01:2022-07-14, 2022-07-18 signatures=0
Received: from smtpclient.apple (unknown [17.11.134.189]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.18.20220407 64bit (built Apr 7 2022)) with ESMTPSA id <0RF700W712DWAC00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Sun, 17 Jul 2022 19:17:57 -0700 (PDT)
From: Vidhi Goel <vidhi_goel@apple.com>
Message-id: <1A95963E-1BEB-4868-9C4F-0C75A4E5B904@apple.com>
Content-type: multipart/signed; boundary="Apple-Mail=_F28EF06B-E81A-4ED4-95F4-4E3954A0FA49"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
Date: Sun, 17 Jul 2022 19:17:56 -0700
In-reply-to: <CAK6E8=djxYk4zMAyCGM+zhmXuZ25WvGLB1jA95Y24i2KMvK4+w@mail.gmail.com>
Cc: "tcpm@ietf.org Extensions" <tcpm@ietf.org>, Neal Cardwell <ncardwell@google.com>
To: Yuchung Cheng <ycheng@google.com>, Markku Kojo <kojo=40cs.helsinki.fi@dmarc.ietf.org>
References: <alpine.DEB.2.21.2207112026000.7292@hp8x-60.cs.helsinki.fi> <31DCA869-30FA-41C6-B21F-3D71E600FFF2@apple.com> <CAK6E8=ddwJK+e8f5Jxe8AW6CmHhvRFyPxb6nhpJ-jdEtXxp5UQ@mail.gmail.com> <alpine.DEB.2.21.2207150152210.7292@hp8x-60.cs.helsinki.fi> <CAK6E8=f63vORKoqDHTkXS=jiaHD_GM0Gw31CzdKbbdhmVeexmA@mail.gmail.com> <alpine.DEB.2.21.2207150229250.7292@hp8x-60.cs.helsinki.fi> <CAK6E8=djxYk4zMAyCGM+zhmXuZ25WvGLB1jA95Y24i2KMvK4+w@mail.gmail.com>
X-Mailer: Apple Mail (2.3696.80.82.1.1)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517, 18.0.883 definitions=2022-07-18_01:2022-07-14, 2022-07-18 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/KThFMS1Liezb1Jemy-1iCrjpt44>
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 <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Jul 2022 02:18:05 -0000
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* …. 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 <ycheng@google.com> 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 <kojo=40cs.helsinki.fi@dmarc.ietf.org <mailto: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 > > <kojo=40cs.helsinki.fi@dmarc.ietf.org <mailto:40cs.helsinki.fi@dmarc.ietf.org>> 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 in 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#L1881 <https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_output.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 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 = min(cwnd, rwnd)" > > That was not the intent. So, I think we agree. > > > What I am saying is that this sentence is not necessary and overly > > strict. Limiting cwnd growth based on inflight which is based on the > > effective sending window (= 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 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 > >>> <vidhi_goel=40apple.com@dmarc.ietf.org <mailto:40apple.com@dmarc.ietf.org>> wrote: > >>>> > >>>> Thank you Markku for proposing the text. Some of this is 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 <kojo=40cs.helsinki.fi@dmarc.ietf.org <mailto: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 <mailto:tcpm@ietf.org> > >>>>> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm> > >>>> > >>>> _______________________________________________ > >>>> tcpm mailing list > >>>> tcpm@ietf.org <mailto:tcpm@ietf.org> > >>>> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm> > >>> > >
- [tcpm] CUBIC rfc8312bis / WGLC Issue 6 and propos… Markku Kojo
- Re: [tcpm] CUBIC rfc8312bis / WGLC Issue 6 and pr… Vidhi Goel
- Re: [tcpm] CUBIC rfc8312bis / WGLC Issue 6 and pr… Yuchung Cheng
- Re: [tcpm] CUBIC rfc8312bis / WGLC Issue 6 and pr… Vidhi Goel
- Re: [tcpm] CUBIC rfc8312bis / WGLC Issue 6 and pr… Markku Kojo
- Re: [tcpm] CUBIC rfc8312bis / WGLC Issue 6 and pr… Markku Kojo
- Re: [tcpm] CUBIC rfc8312bis / WGLC Issue 6 and pr… Markku Kojo
- Re: [tcpm] CUBIC rfc8312bis / WGLC Issue 6 and pr… Yuchung Cheng
- Re: [tcpm] CUBIC rfc8312bis / WGLC Issue 6 and pr… Markku Kojo
- Re: [tcpm] CUBIC rfc8312bis / WGLC Issue 6 and pr… Yuchung Cheng
- Re: [tcpm] CUBIC rfc8312bis / WGLC Issue 6 and pr… Vidhi Goel
- Re: [tcpm] CUBIC rfc8312bis / WGLC Issue 6 and pr… Markku Kojo
- Re: [tcpm] CUBIC rfc8312bis / WGLC Issue 6 and pr… Markku Kojo
- Re: [tcpm] CUBIC rfc8312bis / WGLC Issue 6 and pr… Vidhi Goel
- Re: [tcpm] CUBIC rfc8312bis / WGLC Issue 6 and pr… Markku Kojo
- Re: [tcpm] CUBIC rfc8312bis / WGLC Issue 6 and pr… Vidhi Goel
- Re: [tcpm] CUBIC rfc8312bis / WGLC Issue 6 and pr… Yuchung Cheng