Re: statement regarding keepalives

[Joe Touch <[e-mail]>]

> On Aug 17, 2018, at 4:53 PM, Tom Herbert <[e-mail]> wrote:
> ...
> Joe,
> 
> I agree to the extent that keepalives are run only at one layer with
> one keepalive control loop. If they are simultaneously done at
> multiple layers without consideration that can be problematic.

They are equally problematic to try to coordinate those control loops.

> It's
> also probably a good general recommendation to do keepalives only at
> the application (highest layer) if at all possible.

That makes sense ONLY if the application layer is the layer at which the keepalives are needed; application layer keepalives aren’t a good way to keep a TLS session active, nor necessarily to keep NAT state. 

> Most modern
> application protocols support them (HTTP, RPC protocols, etc). There
> are still protocols like telnet ssh would need TCP keepalives.

Sorry, why does Telnet need a TCP keepalive? I agree telnet through a NAT might, but telnet itself wouldn’t timeout any more than TCP would or should when idle.

> TCP
> keepalives are a weaker signal and have become increasingly prone to
> false positives.

TCP keepalives are a great way to make sure TCP is kept active - the primary purposes of which are to take down any associated state (or let it be taken down) when it cannot be re-established. 

They’re not ‘weak’ at all. They’re TCP.

> For instance, if a connection goes through a
> transparent proxy, a TCP keepalive would only verify the liveness of a
> connection to the proxy, not TCP all the way to the peer unbeknownst
> to the user.

Agreed - again, you’re confirming the point. Use keepalives at EVERY layer that they are meaningfully needed. Don’t expect any other layer to solve that problem.

Joe