On Fri, Aug 17, 2018 at 7:40 AM, Joe Touch <to...@strayalpha.com> wrote: > > >> On Aug 16, 2018, at 3:57 PM, Benjamin Kaduk <ka...@mit.edu> wrote: >> >> On Thu, Aug 16, 2018 at 03:52:54PM -0700, Joe Touch wrote > >>> >>> On Aug 16, 2018, at 3:10 PM, Benjamin Kaduk <ka...@mit.edu> wrote: >>> >>>>> Keepalives at a layer SHOULD NOT be interpreted as implying state at >>>>> any other layer. >>>> >>>> What's going on here in the last sentence is probably a bit subtle -- a >>>> keeaplive both does not indicate "real" protocol activity but also can >>>> serve to exercise the lower protocol layers (and, even, per the previous >>>> sentence, suppresses their keepalives). >>> >>> That may be intended but is never actually known. Lower layers can >>> compress, cache, merge, and otherwise change the effect a transmission st >>> one layer has on any other. >> >> Right, that's why it's subtle :) > > 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." So if an application is performing keepalives by sending and receiving keepalive messages over the connection then that is enough to supress TCP keepalives. 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). Tom > That’s why users SHOULD NOT try to affect lower level keepalives using higher > level ones. (it’s not MUST NOT because there’s no strict harm, except that > it simply can’t be known whether it achieved its desired effect). > > Joe
