Re: [tcpm] Linux doesn’t implement RFC3465

Mark Allman <mallman@icir.org> Thu, 12 August 2021 19:06 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 717BA3A468B for <tcpm@ietfa.amsl.com>; Thu, 12 Aug 2021 12:06:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 SIs76XnreyQJ for <tcpm@ietfa.amsl.com>; Thu, 12 Aug 2021 12:06:24 -0700 (PDT)
Received: from mail-oi1-f182.google.com (mail-oi1-f182.google.com [209.85.167.182]) (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 252A23A4689 for <tcpm@ietf.org>; Thu, 12 Aug 2021 12:06:24 -0700 (PDT)
Received: by mail-oi1-f182.google.com with SMTP id be20so11905324oib.8 for <tcpm@ietf.org>; Thu, 12 Aug 2021 12:06:24 -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=zbufhXqzgVrw7aiJEyHqrX0+jnL6pbh3yttiSn+Xihg=; b=CE0WCXm1VyghujcMLZ3QEqvMqVBJgcA/sCsN8uy2GZzsi7VhgfW+oqBZbx1Sm+5v27 8wUIG+0qaggy16FBeohDOt2IyCef6wKRhbNdmYZ/gmX6q7dX7WwpCPD8L+5LKJQJeeX8 FTj8iCLA68uvZFr86KexiYFiZRdfKRMZoXw89vjoMmh/RN+EHdQJ2UuvZB5pYLkLexj6 n45fG2CqZoATOxwFYrU7Lqlm3Lg+oH7p6OOAZQw6PYLksLviTsJ4OLt6nX9zAraxscDG foNSSn0N9bl3pKyMtz0g+if8cNm428FCKq6KaJM5dnKlcJB3HMH2JmTCeibySEbbiGyW oIyw==
X-Gm-Message-State: AOAM530US2K+sVQD4sqZ6LFlkiPXxYuEEn1ulr5CK9YaF1u3gV5cra7u T7R2ZFTPLB+eP7YNApcJ0wiEzQ==
X-Google-Smtp-Source: ABdhPJxVDWS7rumqyhmtQlDhaYJzbix+gc14u+PNqYskdrWAWALth9KS3RxZY4xeiMMwroViY/eVEA==
X-Received: by 2002:aca:400a:: with SMTP id n10mr4633703oia.127.1628795183470; Thu, 12 Aug 2021 12:06:23 -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 45sm834537otm.43.2021.08.12.12.06.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Aug 2021 12:06:22 -0700 (PDT)
From: "Mark Allman" <mallman@icir.org>
To: "Martin Duke" <martin.h.duke@gmail.com>
Cc: "Mirja Kuehlewind" <mirja.kuehlewind=40ericsson.com@dmarc.ietf.org>, "Yuchung Cheng" <ycheng=40google.com@dmarc.ietf.org>, Extensions <tcpm@ietf.org>
Date: Thu, 12 Aug 2021 15:06:20 -0400
X-Mailer: MailMate (1.13.2r5673)
Message-ID: <66DA3C67-BED1-4B15-BA1D-01F4775E58D4@icir.org>
In-Reply-To: <CAM4esxQOp5+_G4xBeCvSbVCQVSKM1n4atZUJzrWrTqXdS8BA4Q@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> <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>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_1E117BB0-2C59-4C72-A438-FD095FA3C4D8_="; micalg=pgp-sha1; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/QehgYTPQ4VbyaThylCnvdfG9WNQ>
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 19:06:31 -0000

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

Yep.

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

Approach-wise this is OK.  But, there are issues here ...

  - First, we could probably move to L=2 pretty easily (as
    standard).  We have been using byte counting with standard
    delayed ACKs for a long time in stacks that do not use an L.
    So, we have effectively been living with this.

  - Moving to L > 2 (5, 10, \infinity) would seem to me to require
    someone to make the case that we have experience that suggests
    this is OK.  Or, that we have some suggestions that we could run
    at experimental L>2 for a while.  There have been a bunch of
    folks saying that we understand L > 2 works fine, but in pretty
    hand-wavy, mailing list sorts of ways.  I.e., there are stretch
    ACKs.  Or, there is an implementation with an L.  Or, there are
    offload systems that aggregate packets/ACKs.  When we haven't
    seen---that I am aware of---is a discussion that shows L
    > 2 is a good idea.  Or, that it isn't a bad idea.  It seems to
    me that the usual way these things get advanced is to offer some
    tangible / concrete assessment that says "hey, this is perhaps a
    reasonable thing to change".

  - I am not saying we shouldn't change L.  Perhaps we should.
    E.g., with pacing it seems like a no-brainer.  I am just saying
    that the case hasn't even been attempted.

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

I think a very scoped 5681bis could be done quickly.  If it is a
change to L and/or a change to IW we can use the 6298 model and make
the very tiny text change and add an appendix that justifies the
change.  So, the normative text of the RFC changes very little.

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

Hm.  Well.  Hm.  I'd have to think about that one.  I do think that
just defining some general burst limit could prove to be thorny.
E.g., if you said the max burst size was 10 so IW=10 would be fine
then would a stretch ACK that covered 20 packets only be able to
liberate 10 packets?  Or, if we said a stretch ACK could liberate 20
packets would that imply an IW of 20 packets?  And, do we really
draw no distinction between what we can send into an unknown network
and what we can send into a network we have probed enough to have
some idea about?  This seems difficult.

allman