Re: statement regarding keepalives

Tom Herbert <> Fri, 20 July 2018 13:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4003A1311AE for <>; Fri, 20 Jul 2018 06:52:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-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 7oO0uT2BhGC9 for <>; Fri, 20 Jul 2018 06:52:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 100D4131187 for <>; Fri, 20 Jul 2018 06:52:42 -0700 (PDT)
Received: by with SMTP id z74-v6so6215353qkb.10 for <>; Fri, 20 Jul 2018 06:52:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sX9j05Y81gkuhIl1If6ZkoQYT2k8kmaNyY/5tMEBNcE=; b=Fi73RV+XLwoSfV8gGJg4LjrnQOtAvgkgIUgPxXT9a/tu7VdNg5isMm18IgpeHj0xlN tyFCwoscIesMcBMUCekcNQBWxPwTJzcAULHm7Me4nneS+9UusrirfsxT1y0BkjSV01AK GvuKL1VM6j/l2mpcieIHMohIfomxFYry6lUTGjqxRRE2yJuDnEYc0TigS7gPh+djiR8s AiZYqwoDhTL2tCA9uDJ40KLzDYGZPzDoPugENayo//ZWjM47Lf+BtFJWYUFLfZDsFJde jQsEwRCVG2z06DkKbNC8RhDwnBe6GofPoN6SHLpkhQYXaHrZbq7/3JDAJ2Pylb7OZEMt OE7Q==
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=sX9j05Y81gkuhIl1If6ZkoQYT2k8kmaNyY/5tMEBNcE=; b=L5TGLZtV/Zda09I2HiDYygOkHhLf4zcArvx7VzaCF0DFZj2tmmTxMyGpgnJxZ+HO7w K9jIWzb52dSgGGj5WNjmicPxum+3kwqPHsR96irLek28NhrOm8L3DBbqVHTHo+XsTAqb CN3DTleIkEOcV4NafEUVDEgnj1Q8Zdb+YdxM0iMVeMdgg+3ts5GJtI/jJwQ4EpVXPCWN oj4oAkP1yUF6oiKBJBgSdXuLvhGjYgfOtQudcIBGmvjAVnq4gt7/hCvS6BSeQ5mptKF6 8ZJetRhVz/a+BgJGBBCeD2t43eTv9f1R1o73FWqc50Q6KhhXyfXr6Pr+Wz1HJwvLwTpO JMPQ==
X-Gm-Message-State: AOUpUlHh6bj32xfW+mO647rtCryHGurpNunALJ3w7U//3HQQ3TYyNAqV FlzxNtLewxLXUtbsiL4r0wC3NdTHeu50rLjeB9fKpg==
X-Google-Smtp-Source: AAOMgpdVGO/nBL+A6MJ6rP1Mju5LUXTELpT1ec2Bxg2ap5obfXTzKqTwBucDPIPp/gyNjP1rwZXuZPawhsO7olc4m4w=
X-Received: by 2002:a37:1ae7:: with SMTP id l100-v6mr1841709qkh.248.1532094760777; Fri, 20 Jul 2018 06:52:40 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Fri, 20 Jul 2018 07:52:28 -0600
Message-ID: <>
Subject: Re: statement regarding keepalives
To: Spencer Dawkins at IETF <>
Cc: Mikael Abrahamsson <>, " >>" <>,,,
Content-Type: multipart/alternative; boundary="000000000000fa904205716e9b7e"
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:52:59 -0000

On Fri, Jul 20, 2018, 7:40 AM Spencer Dawkins at IETF <> wrote:

> 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?


When I saw the subject I was wondering if this was going to be the proposal
to deprecate keepalives! With vast numbers of connections performing them,
they at some point start to create congestion. This is especially
problematic if somehow keepalives timers become sychronized. IIRC Google
calendar was brought down at one point a while back because of a keepalive
avalanche. I would assume that keepalives are primarily needed to maintain
NAT state, so if NAT were deprecated (like conceptually promised by  IPv6)
then maybe keepalives could go away.

In any case, I think the text here probably would be good in the draft that
examines current state of keepalives and makes recommendations.


> Spencer
> (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)