Re: [tcpm] Linux doesn’t implement RFC3465

Lars Eggert <> Wed, 13 November 2019 06:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 59E69120861 for <>; Tue, 12 Nov 2019 22:53:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4TyC1eYbnnUl for <>; Tue, 12 Nov 2019 22:53:23 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 88FFE12085D for <>; Tue, 12 Nov 2019 22:53:23 -0800 (PST)
Received: from (unknown []) by (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 <>
In-Reply-To: <>
Date: Wed, 13 Nov 2019 08:53:00 +0200
Cc: Neal Cardwell <>, "" <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Vidhi Goel <>
X-MailScanner-ID: 66092611EEB.A44BA
X-MailScanner: Found to be clean
Archived-At: <>
Subject: Re: [tcpm] =?utf-8?q?Linux_doesn=E2=80=99t_implement_RFC3465?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Nov 2019 06:53:25 -0000


On 2019-11-12, at 23:44, Vidhi Goel <> wrote:
> +Mark Allman

oh, is he at BBN now? Not

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