Re: [tcpm] Linux doesn’t implement RFC3465

Lars Eggert <lars@eggert.org> Wed, 13 November 2019 06:53 UTC

Return-Path: <lars@eggert.org>
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 59E69120861 for <tcpm@ietfa.amsl.com>; Tue, 12 Nov 2019 22:53:25 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 4TyC1eYbnnUl for <tcpm@ietfa.amsl.com>; Tue, 12 Nov 2019 22:53:23 -0800 (PST)
Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88FFE12085D for <tcpm@ietf.org>; Tue, 12 Nov 2019 22:53:23 -0800 (PST)
Received: from eggert.org (unknown [62.248.255.8]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id E5FAB20033; Wed, 13 Nov 2019 08:53:18 +0200 (EET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
From: Lars Eggert <lars@eggert.org>
In-Reply-To: <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com>
Date: Wed, 13 Nov 2019 08:53:00 +0200
Cc: Neal Cardwell <ncardwell=40google.com@dmarc.ietf.org>, "tcpm@ietf.org" <tcpm@ietf.org>, mallman@bbn.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <BBF2FA59-B8DE-4874-A945-D1A20C457F89@eggert.org>
References: <78EF3761-7CAF-459E-A4C0-57CDEAFEA8EE@apple.com> <CADVnQynkBxTdapXN0rWOuWO3KXQ2qb6x=xhB35XrMU38JkX2DQ@mail.gmail.com> <601D9D4F-A82C-475A-98CC-383C1F876C44@apple.com>
To: Vidhi Goel <vidhi_goel=40apple.com@dmarc.ietf.org>
X-MailScanner-ID: 66092611EEB.A44BA
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/yc6ed6fPy9BvArk9akgYGz6DZX4>
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: Wed, 13 Nov 2019 06:53:25 -0000

Hi,

On 2019-11-12, at 23:44, Vidhi Goel <vidhi_goel=40apple.com@dmarc.ietf.org> wrote:
> +Mark Allman

oh, is he at BBN now? Not mallman@icir.org?

> Is it worth investing time in writing another draft to document what Linux (and possibly other implementations) do for more accurate congestion window growth and for solving the burst send issue via pacing, TSQ etc.?

That is IMO the key question. *If* there is an alternative mechanism to ABC that solves (some of) the same problems, and potentially in a better way, or in a way that has a different implementation footprint, that may be worth documenting.

I'm not up to speed with the Linux code, but from what Neal writes, it seems that the Linux mechanism is tied in with or relying on a bunch of lower-level packet I/O functionality that is maybe pretty Linux-specific? In other words, can something like the Linux mechanism even be instantiated without (much of) this underpinning?

Lars