Re: statement regarding keepalives

Tom Herbert <> Fri, 17 August 2018 18:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C285130F0E for <>; Fri, 17 Aug 2018 11:43:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eiJUTyujoHfY for <>; Fri, 17 Aug 2018 11:43:23 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D25BE130F69 for <>; Fri, 17 Aug 2018 11:43:22 -0700 (PDT)
Received: by with SMTP id 89-v6so1554757qkp.2 for <>; Fri, 17 Aug 2018 11:43:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xzkoMOwNqd9rUf763eLrq4OjpbjvTz9q+TG2hrFTtFk=; b=N9QVvBhrNn0iaCq11eud9O3mca1hU2nFbwWbvYETatl/VpoFw7LHZAc1ZOTmqTKXjR 88ILn08b4D6BoPsmk8WHnlfo3ZVvc0be3rn0DMjgWY6ssB29+cxk334Qu1H+rwzJSVZz MHcgur/5dQmO5J2vtC+f/GMeCR9dLKY7levDm8aBK6o29wskeaod2O1qx5wU0oEhJc6I ONMTWvH1BoH/5joNXTiIiK2mZruwqzycdvI52LgZDOZoGaLegq8FuhulxkGwTXak3dQc 8JdJ7aM4WuM8ewWUco03q5yppvbQYare8hzSFXfc+E2FRq5Lx74QCIqHTA4A28OA3Coy wPCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xzkoMOwNqd9rUf763eLrq4OjpbjvTz9q+TG2hrFTtFk=; b=rMMiYGOtQyHuIvmL+QsBEXSH4TTOXsAa7CeCxjQzE+xsXyHQ9ey9ccSz92ZVxKhK63 a5QdiM0WwZveRTxV8yAG80Zj9ghWIWkWlRVtRn3YeMk4tceYpndwl+aqvJ/Fhy4XtJgd PzokjZJ3fKEFo/+xihr38cc5RkCQDY9vLrka6uuxLHCxC21kt/+JeM5EO1KgHhF/MDy1 D4WU9rmT13dmHFfTDHo8JdPZSnuupsjBnWR/qbnin1g8bZYPDRxOxyd5Cd+cxIelZUhh esC7eLherBOUQ8hoZhSXfZU6oNuE3ZRhs6avxYgWcBP7zBhZe5Pucfv1olvgwne0S9wG JdkA==
X-Gm-Message-State: AOUpUlEiz1pX2p/gjX7AiAgVeZXkKcfa/IvnFkLmu22Adh0xL902gAOR 1mHgzC6FOea4uNdadL0qKeRDtb99niLXLZsdWIynUXOi
X-Google-Smtp-Source: AA+uWPyVXDLq79Rwd1f9VeP0V1K27ZwAiNPs/FOf/e6Wgdn+VU3rckztK5D16ncg44x06vgi9kHhbVsgiBikEqzIxYQ=
X-Received: by 2002:a37:c946:: with SMTP id q67-v6mr34509826qki.148.1534531401841; Fri, 17 Aug 2018 11:43:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac8:3304:0:0:0:0:0 with HTTP; Fri, 17 Aug 2018 11:43:21 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Tom Herbert <>
Date: Fri, 17 Aug 2018 11:43:21 -0700
Message-ID: <>
Subject: Re: statement regarding keepalives
To: Joe Touch <>
Cc: Benjamin Kaduk <>,,, " >>" <>,
Content-Type: text/plain; charset="UTF-8"
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 18:43:25 -0000

On Fri, Aug 17, 2018 at 10:27 AM, Joe Touch <> wrote:
> 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.
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.

> 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 and the TCP keepalive shouldn't be
used. This is an example of the problems in running two control loops
at different layers with overlapping functionality, if the
ramifications of doing aren't understood it can lead to undesirable
interactions and behavior.


> Joe