Re: [tcpm] Linux doesn’t implement RFC3465

Mark Allman <mallman@icir.org> Mon, 09 August 2021 17:05 UTC

Return-Path: <mallman@icsi.berkeley.edu>
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 EC15E3A0B5E for <tcpm@ietfa.amsl.com>; Mon, 9 Aug 2021 10:05:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5HVxY8j-vC1 for <tcpm@ietfa.amsl.com>; Mon, 9 Aug 2021 10:05:40 -0700 (PDT)
Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com [209.85.210.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE67E3A0B45 for <tcpm@ietf.org>; Mon, 9 Aug 2021 10:05:39 -0700 (PDT)
Received: by mail-ot1-f47.google.com with SMTP id v10-20020a9d604a0000b02904fa9613b53dso7770408otj.6 for <tcpm@ietf.org>; Mon, 09 Aug 2021 10:05:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=jz+qyZu8sQg1eSeP3YJXxcy4WpLLbw+EVv3T03ohJkI=; b=Xzm9s7ocg6xzCkMGvjC2GTsH9ZfBs9yqQBWK8E6r7m+DZ4kvLBCuaGxO30ugX6wftH eEotz8cERIUW3PrRibkEBU61EWM48Z71FVkq+YqsgB3HOUByMS0NzKjSqDTYf6P21hIm oWrF9c6OMYRkox0oA56hEOqk1628ZwEPaYmTlMwhjPeaU2/NZhc3C6AY6UHXOiVF0+LE ts5XcpvPPckXhXCE4M/XaaCCIIRSGs5UJ8b37tjUrKorshTlCog8tdtUa63uugEF50Gb XGDwooz+ym7ZThziUm4xOHDnHMAT+uU3OXdPlHuKe6yQd2qfzhPZHvG2evtjKZ/4A8fU 6QnQ==
X-Gm-Message-State: AOAM530ndyDvazM+FFZ8MpmPMdN++6dmadYoeu7BlLMdNDW7JrPhklz+ dSQgxfKiQN2RnYiEIyIwPV3NH+9xqhCBLdcG
X-Google-Smtp-Source: ABdhPJw+inI2zi0ceYuTtcBiNqd/ArasEcfBEk+sYP3vrNB6bw+7bmjZppPJ0e/10WPY98PCMRltzg==
X-Received: by 2002:a9d:7cc5:: with SMTP id r5mr4363084otn.55.1628528739151; Mon, 09 Aug 2021 10:05:39 -0700 (PDT)
Received: from [192.168.1.208] (162-203-32-211.lightspeed.bcvloh.sbcglobal.net. [162.203.32.211]) by smtp.gmail.com with ESMTPSA id d11sm2886966ooh.8.2021.08.09.10.05.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Aug 2021 10:05:38 -0700 (PDT)
From: "Mark Allman" <mallman@icir.org>
To: "Neal Cardwell" <ncardwell@google.com>
Cc: "Vidhi Goel" <vidhi_goel@apple.com>, "Yuchung Cheng" <ycheng@google.com>, Extensions <tcpm@ietf.org>
Date: Mon, 09 Aug 2021 13:05:35 -0400
X-Mailer: MailMate (1.13.2r5673)
Message-ID: <1EC4E6CF-604B-411E-BF68-3EF695DB22B5@icir.org>
In-Reply-To: <CADVnQy=6XE7mFZRdBar3YXjUMc5URJYcsJvNdUGy26Zz7gajKQ@mail.gmail.com>
References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <CADVnQynkBxTdapXN0rWOuWO3KXQ2qb6x=xhB35XrMU38JkX2DQ@mail.gmail.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com> <54699CC9-C8F5-4CA3-8815-F7A21AE10429@icsi.berkeley.edu> <DF5EF1C7-0940-478A-9518-62185A79A288@apple.com> <E150D881-4AB3-4AEA-BE0C-1D4B47B2C531@icir.org> <CADVnQynjE+D-OSvdOVROjT3y1cnHHWqdNQSmphLAJ+HsBTUAJQ@mail.gmail.com> <A1B50403-2405-4348-9626-025D255DEAE7@icir.org> <CADVnQykM8p-bVz_oPrje1yNh9_7_isAUL+wnQWDoY9Gs18sLPQ@mail.gmail.com> <11FE4818-87E7-4FD8-8F45-E19CD9A3366A@apple.com> <CAK6E8=fFWAE_NSr45i2mdh6NmYDusUFW3GYGtuo-FcL07sox9A@mail.gmail.com> <D6B865F7-9865-4B6F-986B-F44ABE5F12B0@apple.com> <756432D9-4331-454D-82EB-346CF54A355E@icir.org> <CAK6E8=c+KeQxWJq0e98hY9XsQ2vhdr3SiKkypC7kwdZbBRgdXA@mail.gmail.com> <A39F73BE-4BF1-479D-911F-0CAC6D91D924@icir.org> <CAK6E8=eEnVtMNBpu0noFAud4BTWdupCH+QY1beFjTtD9ADkK5g@mail.gmail.com> <CADVnQynWSCpEBeEtHL0JHCBYwyymX0vku_VbfeDQ_snUoCX=ZA@mail.gmail.com> <76891287-22E6-4071-87C4-8F3A1FD3C2D1@apple.com> <CADVnQy=6XE7mFZRdBar3YXjUMc5URJYcsJvNdUGy26Zz7gajKQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_087DB947-9239-428B-8FA5-2B95B531C25C_="; micalg=pgp-sha1; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/iMXzmvmgqMVy27y29akfUvTXz_M>
Subject: Re: [tcpm] =?utf-8?q?Linux_doesn=E2=80=99t_implement_RFC3465?=
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
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, 09 Aug 2021 17:05:45 -0000

> (2) Implementations that don't pace will generally be causing
> large bursts for many different reasons anyway (data and/or ACK
> aggregation in the network or end hosts), restart from idle,...)
> so having a constant L does not provide enough protection from
> bursts to justify the cost in reduced performance (in the form of
> slower slow-start). In support of this, experience with this as
> the default behavior in Linux TCP over the 2013-2021 period
> suggests this works well enough in practice.

I think at some point someone should put some meat on the bones of
"suggests this works well enough in practice".

It isn't enough for linux to have implemented this.  Or, even had it
turned on.  E.g., if L=\infinity yet receivers ACK every other
packet then there is an effective L of 2.  We see lots of people
saying this scenario isn't the prevalent scenario these days.  If
that's true then it should be easy to provide a summary of
experience with L=\infinity.

This would all just seem better with some concrete experience rather
than the quite hand wavy statements we've seen so far.

allman