Re: [tcpm] Linux doesn’t implement RFC3465

Martin Duke <martin.h.duke@gmail.com> Thu, 12 August 2021 18:11 UTC

Return-Path: <martin.h.duke@gmail.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 E3E983A4502 for <tcpm@ietfa.amsl.com>; Thu, 12 Aug 2021 11:11:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Dtp_6Rk0SVGQ for <tcpm@ietfa.amsl.com>; Thu, 12 Aug 2021 11:10:55 -0700 (PDT)
Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 13EFD3A44FF for <tcpm@ietf.org>; Thu, 12 Aug 2021 11:10:55 -0700 (PDT)
Received: by mail-il1-x133.google.com with SMTP id i9so7937169ilk.9 for <tcpm@ietf.org>; Thu, 12 Aug 2021 11:10:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B/3GhVJZyGgXmPKQjTCK/0CE1fKRChpMmPbdxDc0/xw=; b=QyMCuw7Tol/YkGnNTWpQrSDfrKWbDE5UQsP937pqC+hTTv/eBxWCcXtNW/ZL1jqOS0 x2Q9PE5Yzt5tZn4TFCEEfJ4Q21uFqrHktf0l/M9XoCIo9/kyr4lmIE+DGKwCF7ay9gua K48fEgUk9WkIQ27x3ESIuCPypqv937bjB7Yw6GLEqKSiyBlAr3JiBZ0UD2wmC2+L621b bFTUEQPuVVViyCVsTO7zg9eDgLeNfRb81vSHBoI4r4tNIyYuaaV/OhKh9/xUoksJf1Jj z1UrAFqReTy+nr7+oq0Ie0RlVOszGblt5fAACD1ADRwuxWMKPiaHoZq7DUzBMF/d5Vfr Zv1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=B/3GhVJZyGgXmPKQjTCK/0CE1fKRChpMmPbdxDc0/xw=; b=LCMcuzsieJmjAboN5d2ajam/r0+sgiHj7jrS3a0SySWLC4D85pbY5NmU6s1jonSGix XcACvO4ZquCM4NS63gnhR8Xxd5gP/Uo3cDHDig2FeromsHSKEnVWZq9b3tYiEzFdMXPr dKEbCZuTcMSulttWq3SeuLopyY30v4lFVEbNxXi7oKrouFtb3IUKTL8noMd+l0yWJIjt Oc3q2uafJv2VZdDxPHRcPB5Et77rjp8RwoitSBFGzFVjKChSOTC2leqotfupGJ8/PuaJ YLpwqvp07vv9aOVfPI3zGA/KVe1/fgKtlfRt+B6sSztjeYWOsi3QWnR51p/zV4gZdkmx at+w==
X-Gm-Message-State: AOAM531LBJdhtbmOH7/5oHNA0ngOoMdo4bhaUivEekwuCAt2kf/Vowe9 NUcEzKWlFoK8M2z9Ls1walj0bxs3aEB5pWx0Ncw=
X-Google-Smtp-Source: ABdhPJz/w7x455x2/qeuJ2o6hCuqT07O9dA6hvyCPGp5Gfd3xyVMgu92V2EZ50VEBvfsWY9a281vVv4x1LfbiebIfew=
X-Received: by 2002:a92:cd8a:: with SMTP id r10mr3657226ilb.287.1628791853289; Thu, 12 Aug 2021 11:10:53 -0700 (PDT)
MIME-Version: 1.0
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> <1EC4E6CF-604B-411E-BF68-3EF695DB22B5@icir.org> <CAK6E8=eO5=YfVVhMu54Af1K6sb4iXbykON-Zo8__pWfqG3Vk_w@mail.gmail.com> <4A5AA064-CAC9-4319-8E42-463B3E1FAA1E@ericsson.com>
In-Reply-To: <4A5AA064-CAC9-4319-8E42-463B3E1FAA1E@ericsson.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Thu, 12 Aug 2021 11:10:42 -0700
Message-ID: <CAM4esxQOp5+_G4xBeCvSbVCQVSKM1n4atZUJzrWrTqXdS8BA4Q@mail.gmail.com>
To: Mirja Kuehlewind <mirja.kuehlewind=40ericsson.com@dmarc.ietf.org>
Cc: Yuchung Cheng <ycheng=40google.com@dmarc.ietf.org>, Mark Allman <mallman@icir.org>, Extensions <tcpm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d4160605c960a708"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/SxhTzyNYzRN59Claf7Nc8dBhZ_4>
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: Thu, 12 Aug 2021 18:11:01 -0000

With AD hat on,

If I understand the current document state correctly, the current ABC
guidance we have is

RFC3465 (Experimental): L=2
RFC5681 (PS): L=1

There are a few PS drafts floating around that use byte counting in some
form and would benefit from a standards-track reference in this case.

1. The most comprehensive solution would be a 3465bis PS doc that obsoletes
3465 and updates 5681 with L= Infinity, 8, or whatever number the group
decides on. If we agree this is the right thing to do and someone has the
energy to drop 3465bis-00, then let's do so to have a basis of discussion.

2. If there is no such energy, or there are contentious issues that will
draw out the process to get this to RFC, than I can initiate a review of
upgrading 3465 to PS directly. I think we all agree this would be an
improvement on the status quo, but isn't worth doing if 3465bis is going to
happen quickly.

3. There might be interest in a more generalized 5681bis, but my instinct
is that this is a bigger job that will delay the most urgently needed
update -- which is not to say that we shouldn't do that document too.

4. However, I don't think it would be too much of a stretch to rope in an
IW update (6928bis) in 3465bis, if it doesn't add too much time. It all
fits in with the general theme of the maximum allowable burst on the
internet in the absence of any sort of pacing (ack-driven or
stack-enforced).

The most useful thing right now would be for people to either (1) disagree
with any of my 4 points above or (2) or volunteer to write 3465bis-00.

Martin

On Tue, Aug 10, 2021 at 8:55 AM Mirja Kuehlewind <mirja.kuehlewind=
40ericsson.com@dmarc.ietf.org> wrote:

> Sigcomm paper from 2015:
>
>
>
>
> http://www.sigcomm.org/sites/default/files/ccr/papers/2015/July/0000000-0000002.pdf
>
>
>
> They’ve observed 11-22% of connections with stretched ACKs, ack’ing mostly
> up to 6 packets….
>
>
>
>
>
>
>
> *From: *tcpm <tcpm-bounces@ietf.org> on behalf of Yuchung Cheng <ycheng=
> 40google.com@dmarc.ietf.org>
> *Date: *Monday, 9. August 2021 at 22:53
> *To: *Mark Allman <mallman@icir.org>
> *Cc: *Extensions <tcpm@ietf.org>
> *Subject: *Re: [tcpm] Linux doesn’t implement RFC3465
>
>
>
>
>
>
>
> On Mon, Aug 9, 2021 at 10:05 AM Mark Allman <mallman@icir.org> wrote:
>
>
> > (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".
>
> Good point. We could add anecdotal words on the degree of stretched ACK.
>
>
>
> Maybe we can also cite priori discussions on ACK compression / decimation
> a couple years ago in tcpm / tsvwg. Are there research papers on stretch
> ACK degrees too?
>
>
>
>
> 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
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>