Re: statement regarding keepalives

Tom Herbert <> Fri, 17 August 2018 23:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 72412130FF3 for <>; Fri, 17 Aug 2018 16:54:03 -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 M8aZcuMHuDPy for <>; Fri, 17 Aug 2018 16:53:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4A742130F97 for <>; Fri, 17 Aug 2018 16:53:59 -0700 (PDT)
Received: by with SMTP id 191-v6so7371536qki.13 for <>; Fri, 17 Aug 2018 16:53:59 -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=ZvsboRtT+d6Q0P9VSgKO/n2K7IhmwpYHGGdnvaSeaB8=; b=ao+bGfPN5TQL4CXufjiEHPH+pBXPE+OWgErbVZRtF5tJTCgmBsS/Lybx/6P1joXQDb IsJmal4S9Md+O/3RTdEt/bhpIStT5vY+24Uv8+c1PO0qJCC4uvsQkMnKqLu7crlXENoR b+Y7MQViTVqmscYSekfyiBPOn6k1m98F5USJ8YbHyFK/rsFFMyxcs8gDKQGaY/7ZzgBU dsnbgd9og9VcrG0F0MGQg2sBJM5GAxLRXl9Hrbm8josEHx6OLjjpZDY2qIhZbAdd9B4F GXaoamr2IM9Y6gG2/3RTxJaBfT9rcy/j2zZzS9251jVphr63N/Ko4p9qRbqgWr3xcOKB MQ0g==
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=ZvsboRtT+d6Q0P9VSgKO/n2K7IhmwpYHGGdnvaSeaB8=; b=Lb0c/ffuciu0uMhSh2Z4yz22CSkgkXjtDwByfYyAvbXLXaWlGdiFGNhQkv/KZppj8X jebj+Y17nI0ZKEcDbZ0uE46cgUFDneGF3/Yuj/C9tWW368ENk+bKIhMUfp+uCAt5JCwV OKjU9ZtztNn0TxVqeG0gLciC6cfLa/BXIoul8fSJF/9G7XR5VHoES0nrMUWXHxuS4zzj FrkQCXRlbke9pKeCWOG8rL7UnMwxU8ByEM9hPpQM3+vMpWJAY3w5CSEfwho7HeC0EPbg ZyKgivQOhq48obLbh3E3aegOGQsFRxsmy06r7n6x3uZdYDKsgtj+n291oZ+GE8IvNcrx IXAA==
X-Gm-Message-State: AOUpUlEAqR9sWxdx2xTQZ/XXy9ssTf5q4wGqADvB4MAKkB9RG0Ksg4me CZZCYsiWsDzsrt1o1o3xlNHrkcZojjgRse330Gj4sQ==
X-Google-Smtp-Source: AA+uWPxx1DNCMzMm0s3HXh7PY+cH1y0cX3EJbGC72nCzw4kqbVy06DGj4P3A5g/mGIr/amQnHi+aw1a+Qoz6oQqHiK0=
X-Received: by 2002:a37:c946:: with SMTP id q67-v6mr35383990qki.148.1534550038198; Fri, 17 Aug 2018 16:53:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac8:3304:0:0:0:0:0 with HTTP; Fri, 17 Aug 2018 16:53:57 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Tom Herbert <>
Date: Fri, 17 Aug 2018 16:53:57 -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 23:54:04 -0000

On Fri, Aug 17, 2018 at 4:06 PM, Joe Touch <> wrote:
> On 2018-08-17 14:13, Tom Herbert wrote:
> On Fri, Aug 17, 2018 at 1:31 PM, Joe Touch <> wrote:
> 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.
> Actually, you do know that information. Application keepalives are
> request/response messages sent in TCP data. When a response is
> received to keepalive request over the TCP connection that is proof
> that the keepalive was sent.
> Yes, but the keepalive itself is a guarantee of nothing. It is the keepalive
> ACK that matters.
> If the application keepalive was sent on
> the socket, and no response is received before the application timer
> expires, then the application declares the the connection dead and
> most likely will just close the socket and try to reconnect. The fact
> that an application keepalive request, or its response, might be stuck
> in a TCP send buffer (e.g. peer rcv window is zero) versus the peer
> host completely disappeared is irrelevant. To the application it's all
> the same, a connection to a peer application has failed and action
> needs to be taken.
> In that case it never mattered whether TCP had a keepalive or whether the
> app action interacted with that TCP keepalive.
> What mattered was that the app-app communication was maintained.
> Again, this reiterates my point - run keepalives at the layer that matter to
> you. Ignore how they affect other layers; they will (and should) take care
> of themselves.


I agree to the extent that keepalives are run only at one layer with
one keepalive control loop. If they are simultaneously done at
multiple layers without consideration that can be problematic. It's
also probably a good general recommendation to do keepalives only at
the application (highest layer) if at all possible. Most modern
application protocols support them (HTTP, RPC protocols, etc). There
are still protocols like telnet ssh would need TCP keepalives. TCP
keepalives are a weaker signal and have become increasingly prone to
false positives. For instance, if a connection goes through a
transparent proxy, a TCP keepalive would only verify the liveness of a
connection to the proxy, not TCP all the way to the peer unbeknownst
to the user.


> Joe