Re: [tcpm] Linux doesn’t implement RFC3465

Michael Tuexen <michael.tuexen@lurchi.franken.de> Thu, 12 August 2021 18:55 UTC

Return-Path: <michael.tuexen@lurchi.franken.de>
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 B56973A464A for <tcpm@ietfa.amsl.com>; Thu, 12 Aug 2021 11:55:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.489
X-Spam-Level:
X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 4LXDbn5NGQjc for <tcpm@ietfa.amsl.com>; Thu, 12 Aug 2021 11:55:50 -0700 (PDT)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBDA73A464E for <tcpm@ietf.org>; Thu, 12 Aug 2021 11:55:49 -0700 (PDT)
Received: from smtpclient.apple (ip1f100e9c.dynamic.kabel-deutschland.de [31.16.14.156]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 6229F7220B805; Thu, 12 Aug 2021 20:55:41 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Michael Tuexen <michael.tuexen@lurchi.franken.de>
In-Reply-To: <409938D1-CF12-4238-8641-C24C173B2E33@apple.com>
Date: Thu, 12 Aug 2021 20:55:40 +0200
Cc: Martin Duke <martin.h.duke@gmail.com>, Yuchung Cheng <ycheng=40google.com@dmarc.ietf.org>, Extensions <tcpm@ietf.org>, Mirja Kuehlewind <mirja.kuehlewind=40ericsson.com@dmarc.ietf.org>, Mark Allman <mallman@icir.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9D606388-C6C3-4ADD-B9E0-7B1F69D296ED@lurchi.franken.de>
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> <44490F18-FFB0-4E13-BB97-0FF642B67171@apple.com> <CAM4esxSNwhZc3VWwh7gjZb+G=4N8pfCpZa1aKzsMf7PF+ZEB3A@mail.gmail.com> <409938D1-CF12-4238-8641-C24C173B2E33@apple.com>
To: Vidhi Goel <vidhi_goel=40apple.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/PxHG-ZzvtYb1GfmFCTnNXiHBcbw>
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:55:55 -0000

> On 12. Aug 2021, at 20:44, Vidhi Goel <vidhi_goel=40apple.com@dmarc.ietf.org> wrote:
> 
>> On Thu, Aug 12, 2021 at 11:34 AM Vidhi Goel <vidhi_goel@apple.com> wrote:
>>> 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.
>> 
>> Why not?
> 
> Because L=2 as MUST is too constrained for high BDPs and most stacks don’t even follow that.
My reading is:

* However, ABC with L=1*SMSS bytes is more conservative in a
  number of key ways (as discussed in the next section) and therefore,
  this document suggests that even though with L=1*SMSS bytes TCP
  stacks will see little performance change, ABC SHOULD be used.

* This document specifies that TCP implementations MAY use L=2*SMSS
  bytes and MUST NOT use L > 2*SMSS bytes.

* The exception to the above suggestion is during a slow start phase
  that follows a retransmission timeout (RTO).  In this situation, a
  TCP MUST use L=1*SMSS

So I don't think saying L = 2 is a MUST is a summary. For me it is more
important that it says MUST NOT be larger than 2.

Best regards
Michael
> 
> 
>> On Aug 12, 2021, at 11:39 AM, Martin Duke <martin.h.duke@gmail.com> wrote:
>> 
>> 
>> 
>> On Thu, Aug 12, 2021 at 11:34 AM Vidhi Goel <vidhi_goel@apple.com> wrote:
>>> 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.
>> 
>> Why not?
>>  
>> 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.
>> 
>> It will take a bit more editorial work, but there's no reason a single document can't obsolete both RFCs.
>>  
>> 
>> Thanks,
>> Vidhi
>> 
>> Thanks for writing a draft. That will move things along.
>>  
>> 
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm