Re: statement regarding keepalives

Tom Herbert <> Thu, 16 August 2018 14:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D7172130E78 for <>; Thu, 16 Aug 2018 07:38:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 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] 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 qNFZ_71NIz_t for <>; Thu, 16 Aug 2018 07:38:10 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 478C4130E0D for <>; Thu, 16 Aug 2018 07:38:10 -0700 (PDT)
Received: by with SMTP id w26-v6so4916623qto.5 for <>; Thu, 16 Aug 2018 07:38:10 -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=lYLJE6U3x4Tw2CXfbieQRg6Zo7IIxD3K76pGfSpJzFI=; b=I/9WTpBNr0Jruqk8MSWqeiy+Wa35X/9utFCu0Hy+71cBejI3ODxDcMTch/SJAJE0oF P22YcRL+sSa7y4z00cVT/lar5govnhxOJAByrd9yY5HB0Mb3OEp/ikfAzOPWNvhEa9s9 jobXz40VTPokA0buVLuK8oGgIUuOso2BZvMYBV9y+zip3MiMpY0hV9YitvdwTMTsZGVz VdTCP90PYfc3UWGUddsRIElY1JCnGAY+djznK+cC/ncrr2TdguT0AmdJIm8apCMFs8mF F/PlRHbCyEyA4wIZvTd93XpUv/mrZwu+m50BbtL5tMBdntX+w9BOKiXstrb/dCregu/n bKWA==
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=lYLJE6U3x4Tw2CXfbieQRg6Zo7IIxD3K76pGfSpJzFI=; b=r5zQ/FTHcA5W/r+LhQ7OqzEGPmceQC7aAEwDgOQye+N3CEsT477OKpLMUYBYHf67uP xDcpsX4UmBbkZDG67AvChFsZYcuetgWfDpdVvxQrpcdg1e8mWEes//Z1hFBgtyQS9oWy PEONwpLxL938agNyfC8Ljf5tuECFUzv71xaj9iP9dzj1oT9B30g+kIYAy/5OhVktJ1t1 8UUjT2uSxYKu/p30QuCwrKbJnePxmnSYeTsmNtYEjCt+aV+xeuriF7ce2/SA7PtF252y 5Zgd3gppndUqiu0DoiujujVz7XKp+qPlYJV/U0AuXQ6Kb7/OQlfr3rLJBZOcH6YLOXJE OnJQ==
X-Gm-Message-State: AOUpUlG9pC+a7HE/7Q4E7YnpXklZHobGhiJFc23pEj7DawO0aek8UyYj Bhrycv62grcgaV8Phfm7rys10iwduIdcDMvsnA2YRg==
X-Google-Smtp-Source: AA+uWPzT+czC2Y99549RCKVrTCSiYuoJYrkTDF4lzAOAHqgSh3Jhn02LL97Hk1WGV/1nMb9wQTYfzXWnq32y1NK/8UY=
X-Received: by 2002:a0c:ace2:: with SMTP id n31-v6mr26499911qvc.72.1534430289162; Thu, 16 Aug 2018 07:38:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac8:3304:0:0:0:0:0 with HTTP; Thu, 16 Aug 2018 07:38:08 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: Tom Herbert <>
Date: Thu, 16 Aug 2018 07:38:08 -0700
Message-ID: <>
Subject: Re: statement regarding keepalives
To: "Olle E. Johansson" <>
Cc: Mikael Abrahamsson <>, "" <>, "" <>, "" <>, "" <>
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: Thu, 16 Aug 2018 14:38:14 -0000

On Thu, Aug 16, 2018 at 12:44 AM, Olle E. Johansson <> wrote:
> On 16 Aug 2018, at 09:28, Mikael Abrahamsson <> wrote:
> On Wed, 15 Aug 2018, Kent Watsen wrote:
> You bring up an interesting point, it goes to the motivation for wanting to
> do keepalives in the first place.  The text doesn't yet mention maintain
> flow state as a motivation.
> It's not only to maintain flow state, it's also to close the connection when
> the network goes down and doesn't work anymore, and "give up" on connections
> that doesn't work anymore (for some definition of "anymore").
> I have operationally been in the situation where a server/client application
> was implemented so that the server could only handle 256 connections (some
> filedescriptor limit). Every time the firewall was rebooted, lost state, the
> connection hung around forever. So the server administrators had to go in
> and restart the process to clear these connections, otherwise there were 256
> hung connections and no new connections could be established.
> Sometimes the other endpoint goes down, and doesn't come back. We will for
> instance deploy home gateways probably keeping netconf-call-home sessions to
> an NMS, and we want them to be around forever, as long as they work. TCP
> level keepalives would solve this, as if the customer just powers off the
> device, after a while the session will be cleared. Using TCP keepalives here
> means you get this kind of behaviour even if the upper-layer application
> doesn't support it (netconf might have been a bad example here). It's a
> single socket option to set, so it's very easy to do.
> From knowing approximately what settings people have in their NAT44 and
> firewalls etc, I'd say the recommendation should be that keepalives are set
> to around 60-300 second interval, and then kill the connection if no traffic
> has passed in 3-5 of these intervals, kill the connection. Otherwise TCP
> will have backed off so far anyway, that it's probably faster to just re-try
> the connection instead of waiting for TCP to re-send the packet.
> I have seen so many times in my 20 years working in networking where lack of
> keepalives have caused all kinds of problems. I wish everybody would turn it
> on and keep it on.

They are already on, TCP has a default keepalive for 2 hrs. The issue
that is inevitably raised is that 2 hrs. is much too long a period for
maintaining NAT state (NAT timeouts are usuallu far less time). But,
as I pointed out already, sending keepalives at a higher frequency is
not devoid of cost nor problems.


> As more and more connections flow over mobile networks, it seems more and
> more important, even for flows you did not expect. I have to send keepalives
> over IPv6 connections - not for NAT as on IPv4. but for middlebox devices
> that has an interesting approach and attitude towards connection management.
> ;-)
> The SIP Outbound RFC has a lot of reasoning behind keep-alives for
> connection failover and may be good input here.
> /O