On 16.9.2015, at 6.43, Spencer Dawkins <spencerdawkins.i...@gmail.com> wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This should be an easy Discuss to ... discuss ... > > I'm looking at this text: > > If keep-alives specified in Section 6.1 are NOT sent by the peer > (either the DNCP profile does not specify the use of keep-alives or > the particular peer chooses not to send keep-alives), some other > existing local transport-specific means (such as Ethernet carrier- > detection or TCP keep-alive) MUST be used to ensure its presence. > > and wondering if using TCP keep-alive for liveness detection is realistic > in the use cases this specification is expecting to address. > > Unless I missed something, the default TCP keep-alive interval is still > two hours (that's been true since RFC 1122, and also true in the > relatively recent version of Linux I'm using). If that's OK, I'll clear. > > If you're assuming a keep-alive interval that's shorter, lots of > implementations allow you to tune this, but it seems like the > specification should say something about that. > > Given that the other example of "transport-specific means" is Ethernet > carrier-detection, which would be orders of magnitude faster, I thought I > should ask.
I think your discuss is valid, and it illustrates why giving e.g. concrete numbers about DNCP _in general_ is hard (‘how fast does it converge’, ‘how fast does it do X’, ‘is it good for Y’, ..). Those questions are usually more relevant if asked about the concrete profiles of DNCP-based protocols given the choices left to the profiles. (Even default) TCP keep-alive _is_ fine for applications where the state moves slowly, or detecting that the interruptions in the state flow do not matter so much. E.g. my home automation stuff I wrote on top of DNCP actually would not mind 2-hour delay, as it would decrease the implementation complexity (and power usage to some extent possibly if there’s hardware acceleration of TCP) needed for the sensor nodes themselves (assuming their stack had TCP). While rapidly detecting that e.g. my living room temperature sensor is offline sooner would be _nice_, it is not really mandatory and e.g. TCP k-a would eventually clean it up. Do you think we should insert some sort of disclaimer there about the default value to avoid potential misdesign? Cheers, -Markus _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
