Re: statement regarding keepalives

Joe Touch <> Fri, 17 August 2018 17:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 79EC9130DD5; Fri, 17 Aug 2018 10:27:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 33AugZ2yPmbq; Fri, 17 Aug 2018 10:27:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 94C981252B7; Fri, 17 Aug 2018 10:27:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=EF+FCpBmQ8awUp7CHarNq25Fa0+VOuS6kMre/wOFow4=; b=R5Xdd2HRzURp1UuLhcmW7Pyez 5kmyGU0xDdtlsvx3nKGRYDErV/HzpLq3W9EjshItAfmmbP1uAN3ojJpyEGIMMTRMQixJyKEVj+SGx X3POC9MHw5bfgjznwwoH6LIxfo85Ki7FP9u1/bxEY9vAzuzb1lRwFtqHpOkHrAqUY3AGpPFXJobMx rCJ/xKh+w/x2YuQHgnZ0kZmMx0jsPtcgE/u3w8MsHPv1ghbeWSf/IKYlLLFEYfnSHzpg64ydTWVn7 HTiCy8sMbzFUOMv7OPoAuHLAc8D7w7RWCQ2oyfhf/cgmM++Num4B+JKqrXxIqsjQdZlnYU1aGW/hC tQSxPVshw==;
Received: from [::1] (port=33900 by with esmtpa (Exim 4.91) (envelope-from <>) id 1fqiXK-002AbS-Hh; Fri, 17 Aug 2018 13:27:47 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_3c3135c4eb4c49ca6d20446b0555da3a"
Date: Fri, 17 Aug 2018 10:27:46 -0700
From: Joe Touch <>
To: Tom Herbert <>
Cc: Benjamin Kaduk <>,,,,
Subject: Re: statement regarding keepalives
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Message-ID: <>
User-Agent: Roundcube Webmail/1.3.3
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF Transport and Services Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Aug 2018 17:27:53 -0000

On 2018-08-17 09:05, Tom Herbert wrote:

> On Fri, Aug 17, 2018 at 7:40 AM, Joe Touch <> wrote: 
>> ...
>> It's not subtle. There's no way to know whether keepalives at a higher level have any desired affect at the lower level at all - except using Wireshark to trace the packets sent.
> I don't think that's necessarily true. RFC1122 states:
> "Keep-alive packets MUST only be sent when no data or acknowledgement
> packets have been received for the connection within an interval."

That's Sec and it's talking about what TCP does inside TCP. 

It's not talking about actions by layers above TCP. For all TCP knows, a
user might have tried to send data that's been hung up in the OS.
There's simply no specific way to know that anything above TCP causes
TCP to do anything per se; even if an upper layer protocol does a
TCP_SEND() directly, TCP might stall that data because of other things
going on. 

> So if an application is performing keepalives by sending and receiving
> keepalive messages over the connection then that is enough to supress
> TCP keepalives.

That may or may not be true, but it's for TCP to decide for itself. If
the data isn't getting down to TCP in a way that causes TCP to send data
before a TCP keepalive timer expires, TCP will - and should - send a
keepalive. If the data does cause that timer to be reset, then that's
for TCP to know. 

> For instance, if the period of application sending
> keepalives on a connection is less then the one for TCP keepalives,
> then there should be no TCP keepalives ever sent on the connection (if
> Wireshark is showing otherwise then that might be a bug in the
> implementation).

Consider an app that writes 1GB to TCP every day. If TCP sends that out
slowly (for whatever reason), it's possible no TCP keepalives will ever
be sent. An app that thinks it's doing TCP a favor by sending an app
keepalive every 1.9 hrs (just under the 2 hour default config) would
simply be causing TCP to do unnecessary work. 

However, if that 1GB goes out in 10 seconds, then TCP would have sent
its own keepalives just fine. It didn't need the app's help. 

So the app didn't help at all; at best, it does nothing and at worst it