Re: statement regarding keepalives

[Joe Touch <[e-mail]>]

Hi, Kent, 

For keepalives, I think there are some more useful recommendations than
are currently proposed. Here's my cut: 

- keepalives SHOULD be used at *every* protocol layer where it is
important to retain state (connectivity) in the absence of traffic from
higher layers 

- keepalives at a layer SHOULD be suppressed in the presence of
sufficient traffic from higher layers  

- keepalives at a layer SHOULD NOT be interpreted as implying state at
any other layer (this was the error that BGP once made, i.e., assuming
that if TCP could not keep state then the route should be dropped) 

IMO, these are necessary and sufficient.  

I don't think there should be any other statement about the relative
timing of keepalives at different layers or that keepalives should be
driven by the highest layer possible. That's just silly - e.g., if the
app layer doesn't care about keeping state but the lower layer benefits,
there's no reason to rewrite the app just to keep the function out of
the transport layer(s). 

Joe

On 2018-07-20 08:14, Kent Watsen wrote:

>> ...but still don't put off people turning on TCP keepalives "because
>> the IETF doesn't recommend that", and thus they do nothing at all and
>> the problem just persists.
> 
> No disagreement with what you and others have written, but note that 
> the proposed statement only recommends not using TCP keepalives in
> the presence of a crypto layer on top of the TCP-layer.
> 
> Perhaps the statement could be refined, something along the lines 
> of, in cases when there is a crypto layer, to recommend not using,
> or at least relying on, TCP keepalives, *unless* higher-level
> keepalives have stopped working.
> 
> To be clear, the statement as written, though not stated explicitly,
> recommends TCP keepalives, in cases where they make sense.
> 
> Kent