Re: statement regarding keepalives

[Tom Herbert <[e-mail]>]

On Wed, Aug 15, 2018, 1:56 PM Kent Watsen <[e-mail]> 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
mechanism?

Tom


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