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 >
