Hi, Kent, For keepalives, I think there are some more useful recommendations than are currently proposed. Here's my cut:
- keepalives SHOULD be used at *every* protocol layer where it is important to retain state (connectivity) in the absence of traffic from higher layers - keepalives at a layer SHOULD be suppressed in the presence of sufficient traffic from higher layers - keepalives at a layer SHOULD NOT be interpreted as implying state at any other layer (this was the error that BGP once made, i.e., assuming that if TCP could not keep state then the route should be dropped) IMO, these are necessary and sufficient. I don't think there should be any other statement about the relative timing of keepalives at different layers or that keepalives should be driven by the highest layer possible. That's just silly - e.g., if the app layer doesn't care about keeping state but the lower layer benefits, there's no reason to rewrite the app just to keep the function out of the transport layer(s). Joe On 2018-07-20 08:14, Kent Watsen wrote: >> ...but still don't put off people turning on TCP keepalives "because >> the IETF doesn't recommend that", and thus they do nothing at all and >> the problem just persists. > > No disagreement with what you and others have written, but note that > the proposed statement only recommends not using TCP keepalives in > the presence of a crypto layer on top of the TCP-layer. > > Perhaps the statement could be refined, something along the lines > of, in cases when there is a crypto layer, to recommend not using, > or at least relying on, TCP keepalives, *unless* higher-level > keepalives have stopped working. > > To be clear, the statement as written, though not stated explicitly, > recommends TCP keepalives, in cases where they make sense. > > Kent
