Re: statement regarding keepalives

Joe Touch <> Fri, 17 August 2018 20:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3807130DC1; Fri, 17 Aug 2018 13:31:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Status: No, score=-1.989 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] 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 UY8CO6B_RjxJ; Fri, 17 Aug 2018 13:31:19 -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 76FF2130DC3; Fri, 17 Aug 2018 13:31:19 -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=MYkt66g12ly7da2tU1x4+8GIQ7JiODBY3ESHZx/7af0=; b=D9V70ez+N4xr/lnIf1TgvHNiz PlmGA2R60iaJkoHybvBc8XTDQ1TJc2y/ipNYU0TBziAkWeQXW+0Z+u7Sr6BcOIS/1QuIuiIy+TZml 8ceAhxa8pkhglaF06I5qyqj7Pl2kBIqOND4FKmkDBcr7eExwxQd6is3BdHDNWm4xeGdecpO7rkfVI l3g8Y1au6aL4KpUq7h29KU6cHDO6j5f3AUp2ArCrashTCsvPPm9syLK5tD9OC6cJn35YNbjEu1mkR U+mitssLnIbG+jq3/fX6Qk0bDejPpeR+jxdQQOxc36LEAvyzQoDyhpVTzkW9rDqD+TVUOKbDLo//D a7mzroywg==;
Received: from [::1] (port=38216 by with esmtpa (Exim 4.91) (envelope-from <>) id 1fqlOu-004GSu-Qa; Fri, 17 Aug 2018 16:31:17 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_ddc4ff3c6dbafa59df3fbccbe761dee5"
Date: Fri, 17 Aug 2018 13:31:16 -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 20:31:22 -0000

On 2018-08-17 11:43, Tom Herbert wrote:The purpose of an application
keep alive is not to do favors for TCP,

> it's to verify the end to end liveness between application end points.
> This is at a much higher layer, verifying liveness of the TCP
> connection is a side effect.

Sure - that's fine and not what I'm concerned about. 

I don't want the text to say that higher level protocols or apps should
try to do favors to keepalive lower level protocols - because it doesn't
necessarily 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
>> hurts.
> Consider that someone sets an application keepalive to 35 second
> interval and the TCP keepalive timer is 30 seconds. When the
> connection goes idle TCP keepalive will fire at thirty seconds, and
> five seconds later the application keepalive fires. So every
> thirty-five seconds two keepalives are done at two layers. This is not
> good as it wastes network resources and power.


> In this case, the
> application keepalive is sufficient

In this *implementation* it *might* be sufficient, in others, it might
not. There's simply no way for the layers to know. 

> and the TCP keepalive shouldn't be
> used.

If you KNOW that the app keepalive will cause the TCP transmission, sure
- but how do you KNOW that? You don't and can't. Even if you write to
the TCP socket, all you know when the socket returns is that the data
was copied to the kernel. You don't know for sure that you've triggered
a TCP packet. 

Besides, your "keepalives" might end up causing TCP to send packets it
never needed to send in the first place - even IF you think you're doing
it a favor. 

> This is an example of the problems in running two control loops
> at different layers with overlapping functionality,

The problem is trying to infer overlap in functionality. If you realize
that these are independent control loops *and leave them alone* you're

It's only in trying to optimize them as overlapping that a problem is

> if the
> ramifications of doing aren't understood it can lead to undesirable
> interactions and behavior.

Agreed - so don't. Admit that there are inefficiencies *regardless of
how hard you try to do otherwise* and leave them alone, IMO. 

If the app needs an app-level keepalive, do it. 

If the app wants TCP to be kept alive, let IT do it and leave it alone. 

Don't try to couple the two because you can't, and whatever you think
you might gain you could easily lose. Leaving the two alone and separate
is sufficient and robust.