Re: [tcpm] Linux doesn’t implement RFC3465

Vidhi Goel <vidhi_goel@apple.com> Thu, 12 August 2021 18:34 UTC

Return-Path: <vidhi_goel@apple.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 F38B23A4565 for <tcpm@ietfa.amsl.com>; Thu, 12 Aug 2021 11:34:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level:
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 dy8hqODm42AO for <tcpm@ietfa.amsl.com>; Thu, 12 Aug 2021 11:34:38 -0700 (PDT)
Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3A1A3A45BD for <tcpm@ietf.org>; Thu, 12 Aug 2021 11:34:38 -0700 (PDT)
Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 17CIS9VG014900; Thu, 12 Aug 2021 11:34:30 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=W+rJoFBJo5zJ3I3seJMoUNZ/yqH2RxbOEkLB6sEp0yU=; b=DSlgryX3FXw5gC75fE4OPsss/M0qpBqIPaleWh86JMG4+quLTFCdv+LeFicXAqbEXZjE NwVfborEkIRV2jVlixXg0lYdI6f64twJ5tozGqPMbhbvHVXPjxKKyFmDAO5k6DY4atsZ Q2ojgWLHzmVJj3Ap6fVjbEOHGT1r0BZP0dFB/W0Mx9b+XW7VBZFFDXGT939oRBsfQhiq AhY0Q3tLnRJIoj/1BGn2xsqdCwMMLlZvX8s6VsaELnJovHhJDAQBuRPXsS3tio3fqKqy +JpB3wsNLPwBeZ0EPyzsiRw/5bx4FDEatXIH2/PT4L1m7rFTp1ffPCpeChLjIirWSrcP KA==
Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 3a9s5wvq9v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 12 Aug 2021 11:34:30 -0700
Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QXQ004Y8OXIC900@rn-mailsvcp-mta-lapp01.rno.apple.com>; Thu, 12 Aug 2021 11:34:30 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) id <0QXQ00H00OF4BZ00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Thu, 12 Aug 2021 11:34:30 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 1c81ee2767b4be5bac0682a8445e85fc
X-Va-E-CD: 8ad83cf34a8c3732cb73dea81270d36d
X-Va-R-CD: 2eec4d4b333905bf2498bde820845c7b
X-Va-CD: 0
X-Va-ID: df998e0d-1f88-4cc9-b517-a406f6b121e5
X-V-A:
X-V-T-CD: 1c81ee2767b4be5bac0682a8445e85fc
X-V-E-CD: 8ad83cf34a8c3732cb73dea81270d36d
X-V-R-CD: 2eec4d4b333905bf2498bde820845c7b
X-V-CD: 0
X-V-ID: b0890670-d0ca-4730-9b46-d5eb4c3d5dc8
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-12_06:2021-08-12, 2021-08-12 signatures=0
Received: from smtpclient.apple (unknown [17.234.111.4]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QXQ00072OXHTU00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Thu, 12 Aug 2021 11:34:29 -0700 (PDT)
From: Vidhi Goel <vidhi_goel@apple.com>
Message-id: <44490F18-FFB0-4E13-BB97-0FF642B67171@apple.com>
Content-type: multipart/signed; boundary="Apple-Mail=_D5D519F6-32E2-4C0A-B37F-7A8736E3FA24"; protocol="application/pkcs7-signature"; micalg=sha-256
MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.11\))
Date: Thu, 12 Aug 2021 11:34:28 -0700
In-reply-to: <CAM4esxQOp5+_G4xBeCvSbVCQVSKM1n4atZUJzrWrTqXdS8BA4Q@mail.gmail.com>
Cc: Mirja Kuehlewind <mirja.kuehlewind=40ericsson.com@dmarc.ietf.org>, Extensions <tcpm@ietf.org>, Mark Allman <mallman@icir.org>
To: Martin Duke <martin.h.duke@gmail.com>, Yuchung Cheng <ycheng=40google.com@dmarc.ietf.org>, Neal Cardwell <ncardwell@google.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> <1EC4E6CF-604B-411E-BF68-3EF695DB22B5@icir.org> <CAK6E8=eO5=YfVVhMu54Af1K6sb4iXbykON-Zo8__pWfqG3Vk_w@mail.gmail.com> <4A5AA064-CAC9-4319-8E42-463B3E1FAA1E@ericsson.com> <CAM4esxQOp5+_G4xBeCvSbVCQVSKM1n4atZUJzrWrTqXdS8BA4Q@mail.gmail.com>
X-Mailer: Apple Mail (2.3654.100.0.2.11)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-12_05:2021-08-12, 2021-08-12 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/eg2S9u2vJY4RmuR_1fMJ6GphNV4>
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:34:44 -0000

Thanks Martin for mentioning the different available options.

> If I understand the current document state correctly, the current ABC guidance we have is
> 
> RFC3465 (Experimental): L=2
> RFC5681 (PS): L=1

I want to note that the guidance in 3465 is a MUST while in 5681 is a RECOMMEND.

> 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.

I created a GitHub repo https://github.com/goelvidhi/rfc3465-bis <https://github.com/goelvidhi/rfc3465-bis> with the current text of 3465. Neal and Yuchung have mentioned that they would be willing to contribute. (Neal, Yuchung, please correct me if I misunderstood).

> 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.

I don’t think 3465 can be upgraded to PS as-is.

> 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.

Yeah, it could delay the simpler and important update to 3465. I am ok with going either way - 5681-bis or 3465-bis whichever could likely make faster progress.

> 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).

Personally, I like the structure of 6928 more than 3465. Is it possible to rope in ABC (3465) in a 6928bis and change the title - Would like to hear more from the authors of both the RFCs.

Thanks,
Vidhi

> On Aug 12, 2021, at 11:10 AM, Martin Duke <martin.h.duke@gmail.com> wrote:
> 
> 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 <mailto:40ericsson.com@dmarc.ietf.org>> wrote:
> Sigcomm paper from 2015:
> 
>  
> 
> http://www.sigcomm.org/sites/default/files/ccr/papers/2015/July/0000000-0000002.pdf <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 <mailto:tcpm-bounces@ietf.org>> on behalf of Yuchung Cheng <ycheng=40google.com@dmarc.ietf.org <mailto:40google.com@dmarc.ietf.org>>
> Date: Monday, 9. August 2021 at 22:53
> To: Mark Allman <mallman@icir.org <mailto:mallman@icir.org>>
> Cc: Extensions <tcpm@ietf.org <mailto: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 <mailto: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 <mailto:tcpm@ietf.org>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm