Re: statement regarding keepalives

Spencer Dawkins at IETF <> Fri, 20 July 2018 13:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1F2DD13101E; Fri, 20 Jul 2018 06:40:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 kMfg7sS1CV8p; Fri, 20 Jul 2018 06:40:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5FA7E130EC5; Fri, 20 Jul 2018 06:40:02 -0700 (PDT)
Received: by with SMTP id r3-v6so4354809ywc.5; Fri, 20 Jul 2018 06:40:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CXfXKwOmqsJNp7+I07yFzpfPx/2+CMLNCTOyRqnVUgI=; b=XOzy7nr3jmsQ28/OruqHkXXOYZpjerceWHOIpp4W0feQjLZefhbq5fM2WLA6p9YNQj ns6dawtqhOKaTdkz/VFAe2PZpn92Mxf1Wcni82OuUrJk3QMKzJfSC+VDemG31PhwR6lR pU6EE5Db2uTQSgcRiYFqVcfn86pHe1l8i89vc9uS+qCjlGfoZFf/slrAEVL15bbEnJZy I/EpnhVgOMJahLdApLcOflh60K8/t9NX6YCTzcmVQO0gLL1r1IKed7Rq1YpNXwnlmL0h 3B6cGF382FlS+N/8z3pQh/Yv17na3k8IbM9Yjdd756Oi2oRtk724tjk7fhUwKCNsUeNH +Dhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CXfXKwOmqsJNp7+I07yFzpfPx/2+CMLNCTOyRqnVUgI=; b=qjmqpIP6RtTXdqDdJtXRqbpfVM9PZ50vIaxUyIEwh30tfxFMy3wreeyI08Tq+dozvX 9RmrV5G5FPGvdz2xTtQOC2uDdMH0xCUIuXW62TVF8SCQYiFQDWD/uooI+h4om6NZnRzW 2igMvMGN7MZaX4yBI9YFH10xK/QEj0PKfUp2Oqlvt4SittwWIrayNhaiWXv6EEdmXidj AG4LE283Pd5Y6six6f0Jq2N4QgJahpn+5tvBTrOpww2l16k9W5a5QLc8bToGK7i98v9X Kc1bhF0zJMiI7rH0BeTEFQeoTBssUn+oV2ZFv+xFYAtuTREiHMjIoC64k5jwvFIDp4ym fOIw==
X-Gm-Message-State: AOUpUlEevEuzVe6em1er3TI77uh2QVt9ACgM64d6eAgSkuxfUIiKMqSq DpIR5RaG23gRQKv2fbhXNurSn6Zzm1J0LyZuj4s=
X-Google-Smtp-Source: AAOMgpeLv2NW+6ROSB6R+vWisbK5y2jhp7w2mW5vrqU3VOl5Y3OLgFlAHnvtay6joqd2j6m8gWJaqvb88WcYKcJREns=
X-Received: by 2002:a81:86c4:: with SMTP id w187-v6mr986717ywf.424.1532094001502; Fri, 20 Jul 2018 06:40:01 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Spencer Dawkins at IETF <>
Date: Fri, 20 Jul 2018 08:39:47 -0500
Message-ID: <>
Subject: Re: statement regarding keepalives
To: Mikael Abrahamsson <>
Cc: Kent Watsen <>, " >>" <>,,,
Content-Type: multipart/alternative; boundary="000000000000b8e02405716e6e59"
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, 20 Jul 2018 13:40:04 -0000

Hi, Mikael,

On Fri, Jul 20, 2018 at 6:48 AM Mikael Abrahamsson <> wrote:

> Hi,
> While I agree with the sentiment here, I have personally been in positions
> where application programmers were unable to (in a timely manner) modify
> whatever was running, to implement a keepalive protocol. In that case,
> turning on TCP keepalives was a very easy thing to do that immediately
> would yield operational benefits.
> So I'd like to see in the text that we recommend to do it as "high up" in
> the stack as possible, but still don't put off people turning on TCP
> keepalives "because the IETF doesn't recommend that", and thus they do
> nothing at all and the problem just persists.
> Also, should we talk about recommendations for what these timers should
> be? In my experience, it's typically in tens of seconds up to 5-10 minutes
> that makes sense for Internet use. Shorter than that might interrupt the
> connection prematurely, longer than that causes things to take too long to
> detect a problem. Of course it's up to the application/environment to
> choose the best value for each use-case, but some text on this might be
> worthwhile to have there?

This is exactly the kind of feedback I'd like to reflect in whatever
guidance we give, in whatever form. Thank you for that.

Other thoughts?


(And, yes, there's a tension between "why would I tear down a perfectly
good idle connection because it might not work the next time I try to use
it? for real" and "OMG, I need to send a message to the other side, but my
idle connection is now timing out, so I have to set up a new connection,
secure it, and do whatever else I need to do with the other side before I
can send a message!!!". That's a good thing to include in our advice)