Subject: [homenet] Spencer Dawkins' Discuss on draft-ietf-homenet-dncp-09: (with DISCUSS)

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 15 Sep 2015 20:43:29 -0700

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.

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 16 Sep 2015 11:15:13 +0300

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

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 16 Sep 2015 15:09:25 -0500

Hi, Markus,

On Wed, Sep 16, 2015 at 3:15 AM, Markus Stenberg <[email-masked]>
wrote:

> 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.

This explanation is very helpful.

> 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.

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 17 Sep 2015 17:24:59 +0300

<snip>
On 16.9.2015, at 23.09, Spencer Dawkins at IETF <[email-masked]> wrote:
> 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

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 17 Sep 2015 09:32:19 -0500

Hi, Markus,

On Thu, Sep 17, 2015 at 9:24 AM, Markus Stenberg <[email-masked]>
wrote:

> detecting liveness is available, it’s probably faster than two hours, so
> 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.
>

OK, we discussed it. Thanks, and I'll clear.

Spencer