Re: statement regarding keepalives

[Kent Watsen <[e-mail]>]

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.


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

>