Re: [homenet] Spencer Dawkins' Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS)
On 16.9.2015, at 23.09, Spencer Dawkins at IETF 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
Re: [homenet] Spencer Dawkins' Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS)
On 16.9.2015, at 6.43, Spencer Dawkins 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
[homenet] Spencer Dawkins' Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS)
Spencer Dawkins has entered the following ballot position for draft-ietf-homenet-dncp-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/ -- 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. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
