On Wed, Aug 15, 2018, 1:56 PM Kent Watsen <kwat...@juniper.net> 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 > > > > > >
