Re: [tcpm] CUBIC rfc8312bis / WGLC Issue 6 and proposed text
Yuchung Cheng <ycheng@google.com> Fri, 29 July 2022 17:13 UTC
Return-Path: <ycheng@google.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 7899BC15A732 for <tcpm@ietfa.amsl.com>; 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 <tcpm@ietfa.amsl.com>; 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 <tcpm@ietf.org>; Fri, 29 Jul 2022 10:13:04 -0700 (PDT)
Received: by mail-wm1-x331.google.com with SMTP id c22so2865302wmr.2 for <tcpm@ietf.org>; 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> <C1342BC5-CADA-4798-9A1E-52F953E71588@apple.com> <alpine.DEB.2.21.2207282334570.7292@hp8x-60.cs.helsinki.fi>
In-Reply-To: <alpine.DEB.2.21.2207282334570.7292@hp8x-60.cs.helsinki.fi>
From: Yuchung Cheng <ycheng@google.com>
Date: Fri, 29 Jul 2022 10:12:52 -0700
Message-ID: <CAK6E8=cjsQM+yFj+TQy5DBFE4F6MC0KhpZjTk2BgfY9Z2GjF4g@mail.gmail.com>
To: Markku Kojo <kojo=40cs.helsinki.fi@dmarc.ietf.org>
Cc: Vidhi Goel <vidhi_goel=40apple.com@dmarc.ietf.org>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004635c905e4f4c369"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/M9M1YjXPN_vgfXI_b1vgylxne5U>
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: Fri, 29 Jul 2022 17:13:08 -0000
The latest text looks good to me. On Thu, Jul 28, 2022, 3:29 PM Markku Kojo <kojo= 40cs.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: > > "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 new > _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 (=retransmitted 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,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABAQMAAAAl21bKAAAAA1BMVEUAAACnej3aAAAAAXRSTlMAQObYZgAAAApJREFUCNdjYAAAAAIAAeIhvDMAA > > AAASUVORK5CYII=] > > restrict use of cwnd directly on a congestion event by goelvidhi · Pull > Request #148 · NTAP/rfc8312bis > > github.com > > > > > > Thanks, > > Vidhi > > > > On Jul 24, 2022, at 2:09 PM, Vidhi Goel <vidhi_goel@apple.com> > wrote: > > > > Hi 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 <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 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 > > 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* …. > > 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> 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> 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 > > >>> (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> 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> 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 >
- [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