Re: [tcpm] Linux doesn’t implement RFC3465

Mark Allman <> Thu, 29 July 2021 14:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8ADBD3A241B for <>; Thu, 29 Jul 2021 07:06:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NqB7poDqRebc for <>; Thu, 29 Jul 2021 07:06:35 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ABFC93A2400 for <>; Thu, 29 Jul 2021 07:06:35 -0700 (PDT)
Received: by with SMTP id h63-20020a9d14450000b02904ce97efee36so5961020oth.7 for <>; Thu, 29 Jul 2021 07:06:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=zIl0FkvPN3/e3SZuLy6t4+c4zFNeVkQcKpvyyWlQJ94=; b=sn5bJN9znOVC8igweZAY0crTZ3AL2rhf200P1T88r7J5sWFWCXrFkuNQT788EfprSD /RA8T3sFB2zAwEcL4IjBZ3UnGfr2TOUBqh+USDpsxt7L51AcBbenYCkXy5936NZ0znbL 4Ryrfh+X6Bqb5oXDs9QzX8BnwF4DbghDq1OyaC5NvcWYlgPH9+J2yaZEXoe1fqueADCT U10GSZ6JGUVSyCucRV4CZspj4XKaFWe2eIN1TAzx/euBAuPGwlb3aRTu6lKuvrR1xuci d2NZ285AWRw6tfWoUKp3FYFXtz7Fi86WGm0X3hQx9GapTShAfEjz70xuWEuqJR/NCMJR FZpw==
X-Gm-Message-State: AOAM531nB3PoGY8cobvjmq0MtY3CWqqHUJQeSKVySoGm078GJ5cMX9lb d8XZK5VBOzp/Jh7Tz/o4hWA6/A==
X-Google-Smtp-Source: ABdhPJzPuyHUikcKXkDj7f+cPDr2uqG1oJPvsFNFgO6sFIckIoY0Klv0mOcN6SNtYqsoDmomj2xkmA==
X-Received: by 2002:a05:6830:140d:: with SMTP id v13mr3557377otp.296.1627567594785; Thu, 29 Jul 2021 07:06:34 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id f16sm605032oiw.29.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jul 2021 07:06:34 -0700 (PDT)
From: "Mark Allman" <>
To: "Neal Cardwell" <>
Cc: "Vidhi Goel" <>, Extensions <>
Date: Thu, 29 Jul 2021 10:06:31 -0400
X-Mailer: MailMate (1.13.2r5673)
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_283CFC4C-4731-4DD2-9C19-E6B5A945CE1B_="; micalg=pgp-sha1; protocol="application/pgp-signature"
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: Thu, 29 Jul 2021 14:06:46 -0000

>>     (b) If there is no burst mitigation then we have to figure out
>>         if L is still useful for this purpose and whether we want to
>>         retain it.  Seems like perhaps L=2 is sensible here.  L was
>>         never meant to be some general burst mitigator.  However,
>>         ABC clearly *can* aggravate bursting and so perhaps it makes
>>         sense to have it also try to limit the impact of the
>>         aggravation (in the absence of some general mechanism).
> Even if recommending a static L value, IMHO L=2 is a bit
> conservative.

Well, perhaps.  L=2 was designed to exactly counteract delayed ACKs.
So, it isn't exactly a new magic number.  We could wave our hands
and say "5 seems OK" or "10 seems OK" or whatever.  And, I am sure
we could come up with something that folks felt was fine.  However,
my feeling is that if we want to worry about bursts then let's worry
about bursts in some generic way.  And, if you have some way to deal
with bursts then L isn't needed.  And, if you don't have a way to
deal with bursts then a conservative L seems fine.  But, perhaps
putting the effort into a generic mechanism instead of cooking yet
another magic number we need to periodically refresh is probably a
better way to spend effort.

>>   - During slow starts that follow RTOs there is a general
>>     problem that just because the window slides by X bytes
>>     doesn't say anything about the *network*, as that sliding can
>>     happen because much of the data was likely queued for the
>>     application on the receiver.  So, e.g., you can RTO and send
>>     one packet and get an ACK back that slides the window 10
>>     packets.  That doesn't mean 10 packets left.  It means one
>>     packet left the network and nine packets are eligible to be
>>     sent to the application.  So, it is not OK to set the cwnd to
>>     1+10 = 11 packets in response to this ACK.  Here L should
>>     exist and be 1.
> AFAICT this argument only applies to non-SACK connections. For
> connections with SACK (the vast majority of connections over the
> public Internet and in datacenters), it is quite feasible to
> determine how many packets really left the network (and Linux TCP
> does this; see below).

If you have an accurate way to figure out how many of the ACKed
bytes left the network and how many were just buffered at the
receiver then I see no problem with increasing based on byte count
as you do in the initial slow start.

(I don't remember what the paper you cite says, but my guess is it's
often the case that L=1 is a reasonable substitute for something
complicated here.  But, perhaps I am running the simulation in my
head wrong ... it has been a while, admittedly!)

> Yes, offload mechanisms are so pervasive in practice,

I am trying to build a mental model here.  How pervasive would you
guess these are?  And, where in the network?  I have assumed that
they are for sure pervasive in data centers and server farms, but
not for the vast majority of Internet-connected devices.