Subject: [homenet] I-D Action: draft-ietf-homenet-dncp-02.txt

From: [email-masked]
Date: Wed, 22 Apr 2015 02:58:37 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Home Networking Working Group of the IETF.

        Title           : Distributed Node Consensus Protocol
        Authors         : Markus Stenberg
                          Steven Barth
	Filename        : draft-ietf-homenet-dncp-02.txt
	Pages           : 27
	Date            : 2015-04-22

Abstract:
   This document describes the Distributed Node Consensus Protocol
   (DNCP), a generic state synchronization protocol which uses Trickle
   and Merkle trees.  DNCP is transport agnostic and leaves some of the
   details to be specified in profiles, which define actual
   implementable DNCP based protocols.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-homenet-dncp-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-dncp-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Apr 2015 11:37:27 +1200

Hi,

> 1. Changed DNCP "messages" into series of TLV streams, allowing optimized round-trip saving synchronization. 

So, I have a couple of questions about the new text:

   A DNCP message in and of itself is just an abstraction; when using
   reliable stream transport, the whole stream of TLVs can be considered
   a single message, with new TLVs becoming gradually available once
   they have been fully received.  On datagram transport, each
   individual datagram is a separate message.  In order to facilitate
   fast comparing of local state with that in a received update, TLVs in
   every container TLV MUST be placed in ascending order based on the
   binary comparison of both TLV header and value.

Firstly how do I know when I have received the end of "the whole stream
of TLVs"? It's presumably not infinite, but with no clear notion of a
"message" how do I know when to stop processing?

Secondly, please define the phrase "container TLV". It's quite unclear
to me whether your model is simply a sequence of separate TLVs or
whether TLVs are encapsulated, i.e. does the length field of the first
TLV include the size of some embedded TLVs? Of course I could go and
read the code to find out what you really mean, but this should really
be specified at the beginning of section 7 "Type-Length-Value Objects".

> 2. Added fragmentation extension for bigger node data and for chunking in absence of reliable L2 and L3 fragmentation.

Hmm. For GDNP we are thinking of simply saying "use a conservative MTU
and TLS" to avoid fragmentation.

Regards
   Brian Carpenter

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 23 Apr 2015 09:46:35 +0300

On 23.4.2015, at 2.37, Brian E Carpenter <[email-masked]> wrote:
> “message" how do I know when to stop processing?

You can process TLVs invididually (the length is in second byte received), or in small chunks. TLV processing definition has only one dependency on other TLVs (node data has to have respective node state ’nearby’, for undefined nearby) in the stream, and the node connection TLV must be remembered per message (=whole TCP stream or single UDP datagram) if encountered.

Any suggestions on how to rephrase that to be more clear?

> be specified at the beginning of section 7 “Type-Length-Value Objects".

The later. I guess some sort of update is needed here.

Node Data TLV is the only container TLV in the base spec (but it only says nested TLVs). The base spec has no other container TLVs. 

I noticed also that the Node Data TLV is missing a description. I guess it only alludes to how it is encoded with the variable length, but that could also just refer to the node identifier which is variable length in base spec so clearly more detail is needed here.

> and TLS” to avoid fragmentation.

With TCP (=TLS) fragmentation isn’t a problem anyway for most part. Of course, as our single node’s data is encoded (by default) in a single Node Data TLV, that sets 2^16 size limit to it; that can be worked around using the fragmentation scheme as well.

Thanks for the comments ;)

Cheers,

-Markus

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Apr 2015 16:46:25 +1200

Hi Markus,
> You can process TLVs invididually (the length is in second byte received), or in small chunks. TLV processing definition has only one dependency on other TLVs (node data has to have respective node…

OK, so the process will just keep running until the TCP session closes,
as I understand it. Which incidentally means that you tie up the listen port,
doesn't it? In GDNP we think of more transactional messages, which is why
I wasn't understanding DNCP properly.

> Any suggestions on how to rephrase that to be more clear?

Maybe you need an outline description of the DNCP state machine.

> The later. I guess some sort of update is needed here.

Yes, it's not quite clear.

> Node Data TLV is the only container TLV in the base spec (but it only says nested TLVs). The base spec has no other container TLVs.

OK.

> With TCP (=TLS) fragmentation isn’t a problem anyway for most part. Of course, as our single node’s data is encoded (by default) in a single Node Data TLV, that sets 2^16 size limit to it; that can…

OK, that's clear now, thanks.

   Brian

---

From: Markus Stenberg <[email-masked]>
Date: Fri, 24 Apr 2015 10:51:30 +0300

On 24.4.2015, at 7.46, Brian E Carpenter <[email-masked]> wrote:
> I wasn’t understanding DNCP properly.

I am not sure what do you mean with listen port; the TCP connection is (proto, ip1, p1, ip2, p2) tuple, and one listen port can obviously produce as many TCP connections as there are connecting clients (as long as you do not run out of the tuples).

However, the duration of the TCP connection is intentionally not specified in the core protocol; a DNCP profile _may_ tie e.g. peer state to it’s lifetime (in which case longer durations are preferable), but it also may not.

> Maybe you need an outline description of the DNCP state machine.

Well, that is intentionally omitted. The mandatory ’state machine’ should be simply Trickle caused network state messages, and then processing triggered by them (the MUSTs in the processing of received TLVs).

This is so that ’simple’ implementation is indeed simple (in -03 we will probably send today, we are removing the # of TLVs that need to be handled from 6 to 5 by removing the node data altogether, as it had implicit dependency on node state anyway to be useful),

Given the per-TLV semantics, optimizations such as more proactive spreading of state _will_ be supported by simple clients, although they are not even specified in the DNCP base spec yet, we have just some ideas for implementation purposes. 

Anyway, sending updated -03 probably later today or early next week, it should hopefully make the per-TLV nature bit more clear (and also address some other things).

Cheers,

-Markus

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Apr 2015 08:25:21 +1200

> I am not sure what do you mean with listen port; the TCP connection is (proto, ip1, p1, ip2, p2) tuple, and one listen port can obviously produce as many TCP connections as there are connecting cli…

Yes, but that means that DNCP can only be used for one thing at a time; if you want to
synchronize two different datasets you would need two ports. That's fine, it's
just different from our goals with GDNP, which is why I wanted to understand it.

> Well, that is intentionally omitted. The mandatory ’state machine’ should be simply Trickle caused network state messages, and then processing triggered by them (the MUSTs in the processing of rece…

Fair enough, but not quite obvious until you stated it.

Thanks
   Brian

---

From: Markus Stenberg <[email-masked]>
Date: Sat, 25 Apr 2015 00:25:11 +0300

> just different from our goals with GDNP, which is why I wanted to understand it.

Yes. But you can run multiple instances of DNCP on a single transport stream easily enough (by inserting e.g. 1 byte instance id at front of each TLV, or by defining some container TLV semantics) in a profile if you want to. I guess there are other schemes for that as well. However, the core protocol intends to stay simple so I am not sticking them (or areas) there :-)

(You could probably even share keepalives across instances, therefore keeping it still efficient.)

Cheers,

-Markus