Hi, Mikael, On Fri, Jul 20, 2018 at 6:48 AM Mikael Abrahamsson <[email protected]> wrote:
> > Hi, > > While I agree with the sentiment here, I have personally been in positions > where application programmers were unable to (in a timely manner) modify > whatever was running, to implement a keepalive protocol. In that case, > turning on TCP keepalives was a very easy thing to do that immediately > would yield operational benefits. > > So I'd like to see in the text that we recommend to do it as "high up" in > the stack as possible, 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. > > Also, should we talk about recommendations for what these timers should > be? In my experience, it's typically in tens of seconds up to 5-10 minutes > that makes sense for Internet use. Shorter than that might interrupt the > connection prematurely, longer than that causes things to take too long to > detect a problem. Of course it's up to the application/environment to > choose the best value for each use-case, but some text on this might be > worthwhile to have there? > This is exactly the kind of feedback I'd like to reflect in whatever guidance we give, in whatever form. Thank you for that. Other thoughts? Spencer (And, yes, there's a tension between "why would I tear down a perfectly good idle connection because it might not work the next time I try to use it? for real" and "OMG, I need to send a message to the other side, but my idle connection is now timing out, so I have to set up a new connection, secure it, and do whatever else I need to do with the other side before I can send a message!!!". That's a good thing to include in our advice)
