On Fri, Aug 17, 2018 at 10:27 AM, Joe Touch <to...@strayalpha.com> wrote: > > > > > On 2018-08-17 09:05, Tom Herbert wrote: > > On Fri, Aug 17, 2018 at 7:40 AM, Joe Touch <to...@strayalpha.com> wrote: > > > ... > It's not subtle. There's no way to know whether keepalives at a higher level > have any desired affect at the lower level at all - except using Wireshark > to trace the packets sent. > > I don't think that's necessarily true. RFC1122 states: > > "Keep-alive packets MUST only be sent when no data or acknowledgement > packets have been received for the connection within an interval." > > > > That's Sec 4.2.3.6. and it's talking about what TCP does inside TCP. > > It's not talking about actions by layers above TCP. For all TCP knows, a > user might have tried to send data that's been hung up in the OS. There's > simply no specific way to know that anything above TCP causes TCP to do > anything per se; even if an upper layer protocol does a TCP_SEND() directly, > TCP might stall that data because of other things going on. > > > So if an application is performing keepalives by sending and receiving > keepalive messages over the connection then that is enough to supress > TCP keepalives. > > > > That may or may not be true, but it's for TCP to decide for itself. If the > data isn't getting down to TCP in a way that causes TCP to send data before > a TCP keepalive timer expires, TCP will - and should - send a keepalive. If > the data does cause that timer to be reset, then that's for TCP to know. > > > For instance, if the period of application sending > keepalives on a connection is less then the one for TCP keepalives, > then there should be no TCP keepalives ever sent on the connection (if > Wireshark is showing otherwise then that might be a bug in the > implementation). > > > Consider an app that writes 1GB to TCP every day. If TCP sends that out > slowly (for whatever reason), it's possible no TCP keepalives will ever be > sent. An app that thinks it's doing TCP a favor by sending an app keepalive > every 1.9 hrs (just under the 2 hour default config) would simply be causing > TCP to do unnecessary work. > The purpose of an application keep alive is not to do favors for TCP, it's to verify the end to end liveness between application end points. This is at a much higher layer, verifying liveness of the TCP connection is a side effect.
> However, if that 1GB goes out in 10 seconds, then TCP would have sent its > own keepalives just fine. It didn't need the app's help. > > So the app didn't help at all; at best, it does nothing and at worst it > hurts. Consider that someone sets an application keepalive to 35 second interval and the TCP keepalive timer is 30 seconds. When the connection goes idle TCP keepalive will fire at thirty seconds, and five seconds later the application keepalive fires. So every thirty-five seconds two keepalives are done at two layers. This is not good as it wastes network resources and power. In this case, the application keepalive is sufficient and the TCP keepalive shouldn't be used. This is an example of the problems in running two control loops at different layers with overlapping functionality, if the ramifications of doing aren't understood it can lead to undesirable interactions and behavior. Tom > > Joe > >
