Re: [tcpm] Proceeding CUBIC draft - thoughts and late follow-up

Neal Cardwell <ncardwell@google.com> Mon, 06 June 2022 16:21 UTC

Return-Path: <ncardwell@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 EEC5FC15948F for <tcpm@ietfa.amsl.com>; Mon, 6 Jun 2022 09:21:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.61
X-Spam-Level:
X-Spam-Status: No, score=-17.61 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 fNmsZjfyt1bG for <tcpm@ietfa.amsl.com>; Mon, 6 Jun 2022 09:21:34 -0700 (PDT)
Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (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 61F95C15948B for <tcpm@ietf.org>; Mon, 6 Jun 2022 09:21:34 -0700 (PDT)
Received: by mail-qv1-xf36.google.com with SMTP id j2so10525024qvp.9 for <tcpm@ietf.org>; Mon, 06 Jun 2022 09:21:34 -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=GLt2EnodGIT+7nEuCSTmx/WNfBG3iUGFUoJr2+iQnzU=; b=agd1Fiy7UxvIH9Rsd1tufV3L3v3LUthNrj9b0ZEvd6KskAU9NCTIVtbDvyZJIWoPxY POlvUQZmip/hOZH+4sKbAKx4aH3ZzY/0lpHxMWyPoAwNwclRB7p4IKBC/Ntrde2tkfSw gPXtKhGnDLioYV7/8W3cnh7uGJEsg0Q9uk9HGpCl0EZfwnfFegAHToJAXc+fVrbJTEZo RwKcg7OBqsVsNzaAccl5urAklMdUwS87T9CUjncqezZLuQNG2J94WUY0pObj6vPogMno SlubGo6DhUj/NBEbBuz1d1aLegIxH0Orsnb5S9kF58Lc9U4anXtwZ1SdjOGi4vzqlMDM H9HA==
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=GLt2EnodGIT+7nEuCSTmx/WNfBG3iUGFUoJr2+iQnzU=; b=MNCL3DL5bsN5PA1KA7drow2bxqmPUE4r9kztMBL3s2WLK9Y4+jK9O1DiKHTEosqRgv 7pWzg+Yh8F6GGMELWGr3+W+jDJwPlvxnXrqOffizbK2AKuIMHK8VWbfWgvtSo/ZOfouC +AiZIvbDjj7u8wjVaVGSnDRk8BDg+my3L/RTVOyaVfBrAe634LSo6e99AEzOAIG/8yyJ ora38ahBe4z5QSkIoaforPfHvKYbOjUDfF66Wiq0qxH8ygtN2C8S6eFbfSIrZ39gDFS5 GPu2/5EstxZ/HqIQpabxVCT4ZGo7B87Vf8juSWhUfp+D91HplZeZsuotdF7HTFTx/kHl twrg==
X-Gm-Message-State: AOAM531Pif0Fsw5uDDjh3wnbu/BV918XaHgAINbecbTQ9Ybqw9lzQJN7 jDYo1WuL1GWlv2kmMe6bu0cPI77yQIf8wv/oGOxL7w==
X-Google-Smtp-Source: ABdhPJwjhXr5WHhIaHM/uhBBY2L2kIki59MUJThBzmKCx5YJvMD2YLpBOE+dFCibvkWVFDd6Y0y7Nmtxu/v1ilNNmyI=
X-Received: by 2002:a05:6214:248a:b0:464:5f79:e9ea with SMTP id gi10-20020a056214248a00b004645f79e9eamr25325852qvb.47.1654532492450; Mon, 06 Jun 2022 09:21:32 -0700 (PDT)
MIME-Version: 1.0
References: <CAAK044R12B3f+=2mR1ZK15Zkno5n0YvsjGy64LBiBgBN+9n71A@mail.gmail.com> <CAK6E8=fZs--fR+5Rie1NgtrA4cviatVW=Aw+qkeuqstk9DB0Hw@mail.gmail.com> <CAAK044S3RnvbTzOSHR+B26XCFEiT=YbiNGqQUH4zV4T8c9ZfgA@mail.gmail.com> <864B7333-A8EA-4C9F-A4A7-5DAB49AA4245@eggert.org> <CAAK044TGaTBYwDYU=_JC_MEH4u3Ln4T60BFzXJe681cX6eZjpg@mail.gmail.com> <CAAK044TjuQyQzyHmJCyfuOTUJ5VnyPSVn+EDzdKxLPZ6uahShg@mail.gmail.com> <CAK6E8=feYY-rznoYOokRpphSRDb07MTELKPS02w9N1kwar5k4Q@mail.gmail.com> <CAAK044SHORdqn8+CpwhmJaQoHB+1EqHKjD44CD++N+8JrZ3BLw@mail.gmail.com> <4a2b0971-1159-fe25-c31c-fcfe42c285f6@erg.abdn.ac.uk> <alpine.DEB.2.21.2206061135361.7292@hp8x-60.cs.helsinki.fi>
In-Reply-To: <alpine.DEB.2.21.2206061135361.7292@hp8x-60.cs.helsinki.fi>
From: Neal Cardwell <ncardwell@google.com>
Date: Mon, 06 Jun 2022 12:21:13 -0400
Message-ID: <CADVnQykPmrzGx_STTse1=+pUr3g-sy9WLmhUTLQUD4fr+tBF_g@mail.gmail.com>
To: Markku Kojo <kojo=40cs.helsinki.fi@dmarc.ietf.org>
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>, tcpm-chairs <tcpm-chairs@ietf.org>, Lars Eggert <lars@eggert.org>, Vidhi Goel <vidhi_goel@apple.com>
Content-Type: multipart/alternative; boundary="0000000000007bb51405e0c9dd9b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/Ge05Dzeh-lHcW0SFpmpxxZzwZoM>
Subject: Re: [tcpm] Proceeding CUBIC draft - thoughts and late follow-up
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, 06 Jun 2022 16:21:35 -0000

Markku, thank you for your clear and comprehensive write-up.

Regarding this particular, somewhat easier point:

On Mon, Jun 6, 2022 at 6:30 AM Markku Kojo <kojo=
40cs.helsinki.fi@dmarc.ietf.org> wrote:

> 3 a) The rule for changing alpha to 1 when Wmax is reached in the
>       Reno-friendly region is the correct thing to do during the normal
>       steady state. However, it is incorrect action to take when in the
>       fast convergence mode within the Reno-friendly region because it
>       would act just *opposite* to what CUBIC should do when in the fast
>       convergence mode; instead of slowing down the increase rate during
>       congestion avoidance it actually accelerates because alpha becomes
>       increased to 1 earlier than when not in the fast convergence mode.
>       This seems an obvious mistake with the quite recent modifications
>       to the rfc8312bis.
>

I agree this seems like a clear and straightforward thing to fix. Indeed,
my current draft Linux TCP CUBIC patch series for this "changing alpha to
1" mechanism already uses your suggested approach, and it seems to behave
sensibly.

I have posted a proposed pull request to try to encode this in the draft:
  https://github.com/NTAP/rfc8312bis/pull/146

Please take a look and see what you think. Thanks!

neal