On Fri, Jul 20, 2018, 7:40 AM Spencer Dawkins at IETF < spencerdawkins.i...@gmail.com> wrote:
> Hi, Mikael, > > On Fri, Jul 20, 2018 at 6:48 AM Mikael Abrahamsson <swm...@swm.pp.se> > 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, When I saw the subject I was wondering if this was going to be the proposal to deprecate keepalives! With vast numbers of connections performing them, they at some point start to create congestion. This is especially problematic if somehow keepalives timers become sychronized. IIRC Google calendar was brought down at one point a while back because of a keepalive avalanche. I would assume that keepalives are primarily needed to maintain NAT state, so if NAT were deprecated (like conceptually promised by IPv6) then maybe keepalives could go away. In any case, I think the text here probably would be good in the draft that examines current state of keepalives and makes recommendations. Tom > 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) >
