Re: [tcpm] initcwnd updates?

Neal Cardwell <ncardwell@google.com> Fri, 15 March 2024 16:41 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 A672DC14F698 for <tcpm@ietfa.amsl.com>; Fri, 15 Mar 2024 09:41:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.606
X-Spam-Level:
X-Spam-Status: No, score=-17.606 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_NONE=-0.0001, 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 LeN4PIN0hhHF for <tcpm@ietfa.amsl.com>; Fri, 15 Mar 2024 09:40:58 -0700 (PDT)
Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (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 792B1C14F616 for <tcpm@ietf.org>; Fri, 15 Mar 2024 09:40:58 -0700 (PDT)
Received: by mail-vk1-xa36.google.com with SMTP id 71dfb90a1353d-4d44216ea59so73087e0c.2 for <tcpm@ietf.org>; Fri, 15 Mar 2024 09:40:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1710520857; x=1711125657; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=//QLjbWNhlMNbTVaJ5KY9Dz5CS/Sm2HhWFKZ0FYFDK4=; b=CTU2milWn2qRXqdTgTQOI0wEs/4+dwGGtagYbLlUhg11o8ms77eGQSzhoJrHyYJzx/ NKMzVwUtMB3LYbwvP7WboNYTAXqQZF/BSWAz16PGtl5Ofkx50sIpMwHckCAJw+Hk31vq 4o6+y/Q3LAL4MrMa5Y9FbBiv4MPXRbn5f6JFFheGl5bswg6GbAUDR2D14GAB7xyVPirg FC7MMiQ7JmvAxPedcbCEvK9LxHLx8t29h0ODZjaDKF5p8Ah0Y2nEjsZcARoFriLO7iIR siExyaAyH5usMs8P7vKCAJe6MMjExBSudNrzvMe4vR4Q4dwFc9ew6EmyCPEzLJWUQ0/v 1m4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710520857; x=1711125657; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=//QLjbWNhlMNbTVaJ5KY9Dz5CS/Sm2HhWFKZ0FYFDK4=; b=OjW6r8/f8m0z2HirLkdsYwJbxsMHWmTAknU+Fp2cvYQJKv5ogmFYSg113bdvrFSAP0 GOkQxw/3Q1myKzPy3XgreK7wdsgQ6MbQAAj0ZNqzP0VBnOO9RQGfQKgWztfeJlaG8ICC R/qO22lSVmNXTpERTvZCUdkphRvN5bEAlUrtnVbsfLrSskEtQoZJBbl0ZaKOhMjGIeeZ 5tqCrPw9S0O/EC9PWp2sDbhI8b+huY7liA+lOAunOoENSZIOFz+rm5GCxYZkV82fMF0s 308Y6t2RVWxokbFygx5ew2+zABWC5FLsq0OQBDitPjE65DIldwy25H+c8Ekqg3StrWZc 2VlA==
X-Gm-Message-State: AOJu0YyVONLsK6gbjddI8TRoYz3h3mXActm3cvFqqwt402oxTIyubYHL 74ltl0C6YuY2McTw+UtZKVyKv0S7ZCwK4P8677iY3r2+KxH/jtbqKNxE579fcIUJdUm2/luSyTT AF005TYcStVXH9XmGA6ZEkgJscgT1QYOyg8Md
X-Google-Smtp-Source: AGHT+IGtWaoD0aQ0wmyl3blM4uJeSZxhWyhmnl4l3ccih1pfzqQpualVbVJmRlI7Xa89CfI8tL/Vn+y0ORxJC7hdePI=
X-Received: by 2002:a05:6122:2511:b0:4d3:b326:5ae8 with SMTP id cl17-20020a056122251100b004d3b3265ae8mr6587468vkb.14.1710520857178; Fri, 15 Mar 2024 09:40:57 -0700 (PDT)
MIME-Version: 1.0
References: <2c7008ebafdb43b480bada1205e6bb5e@amazon.com>
In-Reply-To: <2c7008ebafdb43b480bada1205e6bb5e@amazon.com>
From: Neal Cardwell <ncardwell@google.com>
Date: Fri, 15 Mar 2024 12:40:36 -0400
Message-ID: <CADVnQykQUOxkHBxys4MYVTGeYWWq2yLsTT2fr37CREUkr2BTBg@mail.gmail.com>
To: "Kampanakis, Panos" <kpanos=40amazon.com@dmarc.ietf.org>
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Mark Allman <mallman@icir.org>
Content-Type: multipart/alternative; boundary="0000000000001347070613b5ac86"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/oAIiDPoSpLeAsSxGAMThbWnaG3A>
Subject: Re: [tcpm] initcwnd updates?
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, 15 Mar 2024 16:41:02 -0000

One interesting draft on this topic since RFC 6928 is  Mark Allman's draft
from 2015:

  Removing TCP's Initial Congestion Window
  https://datatracker.ietf.org/doc/html/draft-allman-tcpm-no-initwin-00

Another related draft that is in progress is about reusing congestion
control parameters from previous connections over the same path:

  Convergence of Congestion Control from Retained State
  https://datatracker.ietf.org/doc/draft-ietf-tsvwg-careful-resume/

neal


On Fri, Mar 15, 2024 at 11:31 AM Kampanakis, Panos <kpanos=
40amazon.com@dmarc.ietf.org> wrote:

> Hi all,
>
> Sorry if this has been asked recently, but looking in the list archive, I
> can’t seem to find any discussions about it.
>
> I was wondering if initcwnd updates have come up in TCPM recently.
>
> It has been 14 years since draft-hkchu-tcpm-initcwnd started and 11 since
> RFC6928 got ratified.
>
> Many CDNs use initicwnds=30 or more to increase performance.
>
> Also, new post-quantum signatures, if they ever got deployed, could lead
> to >15KB of authentication data (certificate chain and CertificateVerify
> signature) which means they would add an unnecessary RTT when initcwnd=10.
> This has been in shown in various publications *[1]*
> <https://www.ndss-symposium.org/ndss-paper/post-quantum-authentication-in-tls-1-3-a-performance-study/>,
> *[2]* <https://dl.acm.org/doi/10.1145/3386367.3431305>, *[3]*
> <https://blog.cloudflare.com/sizing-up-post-quantum-signatures/>
>
> So, I was wondering, should investigating the increase of the default TCP
> initcwnd be a topic for discussion over a decade after the last increase?
> Has technology evolved enough for a new default initcwnd=15 or 20?
>
> Rgs,
> Panos
>
> [1]
> *https://www.ndss-symposium.org/ndss-paper/post-quantum-authentication-in-tls-1-3-a-performance-study/*
> <https://www.ndss-symposium.org/ndss-paper/post-quantum-authentication-in-tls-1-3-a-performance-study/>
> [2] *https://dl.acm.org/doi/10.1145/3386367.3431305*
> <https://dl.acm.org/doi/10.1145/3386367.3431305>
> [3] *https://blog.cloudflare.com/sizing-up-post-quantum-signatures/*
> <https://blog.cloudflare.com/sizing-up-post-quantum-signatures/>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>