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>
> >>>
> >