Re: statement regarding keepalives

Tom Herbert <> Wed, 15 August 2018 21:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 01180130E02 for <>; Wed, 15 Aug 2018 14:04:02 -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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lpxURqdxqOW2 for <>; Wed, 15 Aug 2018 14:03:58 -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 6759D130DF3 for <>; Wed, 15 Aug 2018 14:03:58 -0700 (PDT)
Received: by with SMTP id c126-v6so1822499qkd.7 for <>; Wed, 15 Aug 2018 14:03:58 -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=VbYgG+VanSLuxVRUz36oMRWDxYiZrv74YmGbZGg9WEc=; b=SjNV6IyfHUs/6h3pHp0cEjh42WYrcBN1BJfItbHRBs+u5agaLpSt8M/Dq5TihGqmW/ B8zmuhADHPSS9kFxA4kxjzvU9tCjGWdRPDR8IIS5rNFKYR4WHFmQ0bhqMudZAQUFGn+G a7DFo0K61fOYytMUIIFONE7JtdzI8A9gYCQpd335U7dfz0je3jZ28bn8xA/R6STgNL32 SKg2bu1fiHqIrkWTvTENksS0QeODDtWyI8DQtBWMz5GVNMpUE7WG/feqNQKzQQYLPdmp tvSRf9A+ccAV6esFxnpyiNEUwxrzjQ7VpRHGaAUGkaXW5hxOot5Zga0UZLkRPPUpG/y/ SPzQ==
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=VbYgG+VanSLuxVRUz36oMRWDxYiZrv74YmGbZGg9WEc=; b=hblQqMtoITXOhu05g0sLbQI8G+AaVzhC9yqLstuI12ec8mlnTRxsFRo5rM0a+uZJX9 k54AsFEMV3AgBIrYIlTPpNdel1L5Q22iOUFIgfD1OyMrCvnbr9PCmSPG5c4HNXOVjsFr GBAVWNJtw7e0fY+aSqrZ9dt3P/2gh5GpjSSWkFmB4qKvpq/bcmu8NTzPG+nJaEQcNjs7 mTRnzF0idAa3a/axRpaNi1BfEZny9gkamYpVkd4Yqv4Ver9bT7/qjgPPeqcwQAsHe+OM KdOkEU4XRsbMd8yTJddehZ/vFqLNR2EdHu+zalG2zW+O+fTr3AqgdJueeJxUTWtDP0/P seiQ==
X-Gm-Message-State: AOUpUlHrXSnIg96ekJIShB5vi61yC5QvRaklsaHb7BrVv/+HFwpgjjnr Wjo5StYNOymkuUrv3d9h6m4PXK11uV+WJBDdxkGcXQ==
X-Google-Smtp-Source: AA+uWPxTWtsTf42nqZFROm5cnlvfQoTFWtzwiU773cveTVYmNIbTmxkJiBIMtFPXQBaf068qVj2IUCOjh2OEegjj8Fo=
X-Received: by 2002:a37:2c84:: with SMTP id s126-v6mr24744934qkh.311.1534367037377; Wed, 15 Aug 2018 14:03:57 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Wed, 15 Aug 2018 14:03:45 -0700
Message-ID: <>
Subject: Re: statement regarding keepalives
To: Kent Watsen <>
Cc: Joe Touch <>,, "" <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="00000000000037e46c05737faa08"
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: Wed, 15 Aug 2018 21:04:02 -0000

On Wed, Aug 15, 2018, 1:56 PM Kent Watsen <> wrote:

> Hi Tom,
> I recall you're mentioning NAT before.  It fell into a crack and I
> lost sight of it.
> 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.
> The first paragraph of the "keepalives" section says:
>   When the initiator of a networking session needs to maintain a
>   long-lived connection, it is necessary for it to periodically test
>   the aliveness of the remote device.
> Would it make sense to adjust it to say the following?
>   When the initiator of a networking session needs to maintain a
>   long-lived connection, it is necessary for it to periodically
>   ensure network accessibility to and test the aliveness of the
>   remote device.  For instance, without keepalive, an intermediate
>   NAT or firewalls may evict the flow state for quiet connections
>   due to a timeout or least recently used policy.  Similarly, the
>   remote application process, while accessible, may be hung, thus
>   accounting for the reason why the connection is quiet.
> Regarding your other comment, that the discussion should "include
> considerations on the frequency of keepalives and their cost", it
> seems that you almost wrote the paragraph below.  Would you be
> willing to proffer some formal text we could paste in, maybe to
> the end of the "keepalives" section or another section?  If not,
> I can try to take a stab at it.

Kent, I'm not sure what the context of formal text is. Is this write up
going to be in an I-D, or is it intended to be published by some other


> Thanks,
> Kent
> ===== original message =====
> I think the statement is missing a primary purpose of keepalives,
> maybe the most important one, which to maintain flow state in NAT and
> firewalls and prevent eviction by timeout or LRU.
> Also, any meaningful discussion or statement about keepalives should
> include considerations on the frequency of keepalives and their cost.
> Keepalives themselves carry no meaningful end user data, they are
> purely management overhead. The higher the frequency of keepalives,
> the higher the overhead and hence the more network resources they
> consume. At some point they can become a source of congestion,
> especially when keepalive timers become synchronized across a network
> as I previously pointed out. Unfortunately, there is no standard for
> how NAT state eviction is done and no standard NAT timeout, so the
> frequency of keepalives to prevent NAT state eviction is probably
> higher than it should be (hence more network overhead).
> In terms of cost, consider the effects of waking up the transmitter on
> a smart phone periodically just for the purpose of keeping connections
> up. With a high enough frequency this will drain the battery quickly.
> In fact, one of the touted benefits of IPv6 was supposed to be that
> NAT isn't present so there is no need for periodic keepalives to
> maintain NAT state and hence this would conserve power on mobile
> devices. Use of keepalives in power constrained devices is a real
> issue.
> Tom
> >