<snip> On 16.9.2015, at 23.09, Spencer Dawkins at IETF <spencerdawkins.i...@gmail.com> wrote: > Do you think we should insert some sort of disclaimer there about the default > value to avoid potential misdesign? > > I haven't seen people tripping over using TCP keep-alives and assuming they'd > be more responsive than they are lately, but I have seen that happen a bunch > of times in my life ... > > If you think making a text change would be helpful, I'd suggest simply > removing the reference to "or TCP keep-alive". If any other way of detecting > liveness is available, it’s probably faster than two hours, so TCP > keep-alives would likely be a last-ditch defense in any case.
I (slightly) prefer including the second example especially as it is the traffic/implementation minimizing option (given TCP transport). So I think I will leave it there. Only case where it really hits the TCP k-a interval anyway is if _nothing_ in the DNCP network changes during the k-a interval, otherwise the connection would hit the (potentially tuned) RFC1122’s R2 anyway. That would guarantee dropping of connections that seem not to propagate fresh state change correctly. In my experience, I have yet to encounter a DNCP use case (and I have seen so far 4 distinct ones) where that 2 hour limit would be really encountered anyway => ’something else’ would take care of it faster than the TCP k-a if the network is really functioning, and if not, k-a would sort it out ‘eventually’ for e.g. a lone node that gets network partitioned away from other nodes. Cheers, -Markus _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
