Re: statement regarding keepalives

[Tom Herbert <[e-mail]>]

On Fri, Aug 17, 2018 at 4:06 PM, Joe Touch <[e-mail]> wrote:
>
>
>
> On 2018-08-17 14:13, Tom Herbert wrote:
>
> On Fri, Aug 17, 2018 at 1:31 PM, Joe Touch <[e-mail]> wrote:
>
>
>
> If you KNOW that the app keepalive will cause the TCP transmission, sure -
> but how do you KNOW that? You don't and can't. Even if you write to the TCP
> socket, all you know when the socket returns is that the data was copied to
> the kernel. You don't know for sure that you've triggered a TCP packet.
>
> Actually, you do know that information. Application keepalives are
> request/response messages sent in TCP data. When a response is
> received to keepalive request over the TCP connection that is proof
> that the keepalive was sent.
>
>
> Yes, but the keepalive itself is a guarantee of nothing. It is the keepalive
> ACK that matters.
>
>
>
> If the application keepalive was sent on
> the socket, and no response is received before the application timer
> expires, then the application declares the the connection dead and
> most likely will just close the socket and try to reconnect. The fact
> that an application keepalive request, or its response, might be stuck
> in a TCP send buffer (e.g. peer rcv window is zero) versus the peer
> host completely disappeared is irrelevant. To the application it's all
> the same, a connection to a peer application has failed and action
> needs to be taken.
>
>
> In that case it never mattered whether TCP had a keepalive or whether the
> app action interacted with that TCP keepalive.
>
> What mattered was that the app-app communication was maintained.
>
> Again, this reiterates my point - run keepalives at the layer that matter to
> you. Ignore how they affect other layers; they will (and should) take care
> of themselves.

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. It's
also probably a good general recommendation to do keepalives only at
the application (highest layer) if at all possible. Most modern
application protocols support them (HTTP, RPC protocols, etc). There
are still protocols like telnet ssh would need TCP keepalives. TCP
keepalives are a weaker signal and have become increasingly prone to
false positives. 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.

Tom

>
> Joe
>
>
>
>