> On Aug 17, 2018, at 4:53 PM, Tom Herbert <[email protected]> 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
