Subject: [Anima] Fwd: I-D Action: draft-carpenter-anima-gdn-protocol-01.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 06 Jan 2015 11:11:51 +1300

Hi,

Here is an updated version of our candidate protocol for Anima. We did
quite a lot of work on the draft, so the diffs may not be very helpful.

Note in particular:

1. We restructured the logical flow of the document. We hope the
   document is now more self-explanatory.
2. We now describe synchronization completely.
3. We added unsolicited responses.
4. There are numerous corrections and clarifications.
5. We expanded the future work list - there are still a lot of open issues.
6. Sheng Jiang has stepped down as an author due to his WG Chair role.

We'd really appreciate review, comments, opinions, and suggestions.

(Note that the reference to HNCP is still present, but for next time
we need to update to cite draft-ietf-homenet-dncp. Our synchronization
model is intentionally less strict than theirs.)

Regards
   Brian + Bing

-------- Forwarded Message --------
Subject: I-D Action: draft-carpenter-anima-gdn-protocol-01.txt
Date: Mon, 05 Jan 2015 13:56:07 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : A Generic Discovery and Negotiation Protocol for Autonomic Networking
        Authors         : Brian Carpenter
                          Bing Liu
	Filename        : draft-carpenter-anima-gdn-protocol-01.txt
	Pages           : 42
	Date            : 2015-01-05

Abstract:
   This document establishes requirements for a protocol that enables
   intelligent devices to dynamically discover peer devices, to
   synchronize state with them, and to negotiate mutual configurations
   with them.  The document then defines a general protocol for
   discovery, synchronization and negotiation, while the technical
   objectives for specific scenarios are to be described in separate
   documents.  An Appendix briefly discusses existing protocols as
   possible alternatives.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-carpenter-anima-gdn-protocol/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-carpenter-anima-gdn-protocol-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-carpenter-anima-gdn-protocol-01

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/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 6 Jan 2015 12:08:56 +0200

Heya,

it is a good thing at least the todo states that this thing will not scale (at least if hit by DoS / there is much traffic / low-power devices are involved) due to async crypto op per message. As that part of my emails was incorporated as feedback, I hope also the fact that DNCP _can_ be used to synchronize distinct subgraphs (think objective-specific state graphs, and/or per-link state graphs) makes it also to the edition that compares GDN with DNCP.

However, I am not sure what the new ’synchronization’ semantics really are. To me, they seem like the (old) req+response ’negotiation’ sprinkled with ‘you can also do unsolicited Trickled multicast / unicast if you feel like it’, without specifying any further behavior. Sure, saying all of that is objective-specific is a neat way of leaving all details/state out of the base protocol, but it also burdens specific objective definitions overmuch. Is the synchronization objective supposed to have some sort of TTL? Keep-alive indicator (to indicate unicast sync still makes sense - and what would it look like? not covered)? Something else? 

Similarly in case of unsolicited multicast, what _exactly_ is ’same state’ here? Most of the time I would imagine this exchange to be triggered initially via unicast, so odds of other nodes sending _exactly_ same packet (to make Trickle matter) is low. How to identify “same” synchronization state being sent on same link by other nodes? And if such thing does not exist, why use Trickle at all?

Cheers,

-Markus

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 07 Jan 2015 08:11:17 +1300

Hi Markus,
> it is a good thing at least the todo states that this thing will not scale (at least if hit by DoS / there is much traffic / low-power devices are involved) due to async crypto op per message. As t…

Yes. We didn't want to tear out the security text for this version,
but I certainly want to discuss this aspect. (And we owe you a mention
in the Acknowledgements.)

> 
> However, I am not sure what the new ’synchronization’ semantics really are. To me, they seem like the (old) req+response ’negotiation’ sprinkled with ‘you can also do unsolicited Trickled multicast / unicast if you feel like it’, without specifying any further behavior. Sure, saying all of that is objective-specific is a neat way of leaving all details/state out of the base protocol, but it also burdens specific objective definitions overmuch. 

True. But it didn't feel right to include specifics such the DNCP hash in
the base protocol. It may be that we need to define a standard template for
the objectives, which every specific objective would inherit by default.
And that template would need to answer all your questions below.

> Is the synchronization objective supposed to have some sort of TTL? Keep-alive indicator (to indicate unicast sync still makes sense - and what would it look like? not covered)? Something else? 
> 

Thanks for asking these questions. They raise another one in my mind: what
is the *scope* of a synchronization objective? In a large scale network,
it cannot reasonably be the whole network, but it needs to be more than
one link.

    Brian

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 7 Jan 2015 09:41:11 +0200

> And that template would need to answer all your questions below.

After hitting send I started to wonder actually about this bit more. There are two different paths on how the {negotiation,synchronization} objectives can be really specified; one option is to leave base protocol REALLY simple (and that would mean that you could even remove Trickle mention here). Second is that it will actually specify (or give examples) of how particular things can be done in practise but perhaps still not constrain the solution to e.g. Trickle only for dealing with multicast.

The ’simple base’ choice would mean that you would just say (roughly) that synchronization =~ negotiation, with optional unsolicited uni- or multicast response message(s) on top (specified in the objective). Mentioning Trickle here is just a half-way measure of sorts and that is why I reacted to it when I read it as ‘just use Trickle’ is not that helpful but may constrain solution space.

Personally I would probably rather leave base spec relatively bare, if you are shooting for universality. Perhaps provide an appendix or something with (non-exhaustive set of) examples of the different objectives at most.

> it cannot reasonably be the whole network, but it needs to be more than

Indeed. This is another thing I thought about yesterday a bit; as I read GDN-01 yesterday, the text almost made it seem just synchronization between two endpoints, although that sounds very limited. DNCP by default is graph-wide and as you stated, it is also undesirable in large networks (you do not want every node of the network in the same graph).

I _think_ that for ‘general’ case, it would be useful to have synchronization objectives of different scopes, and to some degree also with different synchronization mechanisms. For example, allow for single pub-sub style relationship (I subscribe to your updates of $FOO, you send it to me (and other subscribers) when it changes). On the other hand, if you have network-wide state of some sort that has potentially multiple sources of information, you might wind up with something DNCP-ish. 

Instead of scopes, in terms of design, to me it matters if there is more than one source for information of that particular type; for single source(/few ~static ones), ~tree(s) of subscriptions works fairly well although of course there is the reliable messaging angle to be considered. If there are multiple sources, then it gets complex and you may want something from the graph synchronization side of the fence. In-protocol prefix assignment with arbitrary set of egress points in the network qualifies for example ([1] - now it is actually just abstract algorithm that can be reused, with some glue in the HNCP document between it and DNCP profile).

Interestingly enough, on the HNCP front, we have been having occassional discussions on how to deal with scopes, or alternatively provide a way for non graph participating node to publish data, and subscribe to updates (think management host that is not around always, or some low-power device). So ultimately it might turn out that you may want _both_ even for same objective(s).

Cheers,

-Markus

[1] https://datatracker.ietf.org/doc/draft-ietf-homenet-prefix-assignment/

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Jan 2015 14:25:37 +1300

> After hitting send I started to wonder actually about this bit more. There are two different paths on how the {negotiation,synchronization} objectives can be really specified; one option is to leav…

Yes. I think you're right, and the GDN draft is a bit stuck in the
middle at the moment. We'll think about that, and the scope question,
before the next version.

Hello everybody else - we'd like some feedback from the rest of the WG
on whether GDN is heading in a reasonable direction. It's a complex
document and we don't want to worry about all the details unless people
think the general approach is correct.

    Brian

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 12 Jan 2015 08:13:24 +0000

>>>> However, I am not sure what the new ’synchronization’ semantics really
>are. To me, they seem like the (old) req+response ’negotiation’ sprinkled
>with ‘you can also do unsolicited Trickled multicast / unicast if you feel like
>it’, without specifying any further behavior. Sure, saying all of that is
>objective-specific is a neat way of leaving all details/state out of the base
>protocol, but it also burdens specific objective definitions overmuch.
>> After hitting send I started to wonder actually about this bit more. There are
>two different paths on how the {negotiation,synchronization} objectives can
>be really specified; one option is to leave base protocol REALLY simple (and
>that would mean that you could even remove Trickle mention here). Second is
>that it will actually specify (or give examples) of how particular things can be
>done in practise but perhaps still not constrain the solution to e.g. Trickle only
>for dealing with multicast.
>

In my opinion, the protocol itself should remain as simple as possible with necessary functionalities. However, validation examples are also important to demonstrate it can work in several essential scenarios.

Best regards,

Sheng

>    Brian
>
>>
>> The ’simple base’ choice would mean that you would just say (roughly)
>that synchronization =~ negotiation, with optional unsolicited uni- or
>multicast response message(s) on top (specified in the objective). Mentioning
>Trickle here is just a half-way measure of sorts and that is why I reacted to it
>when I read it as ‘just use Trickle’ is not that helpful but may constrain
>solution space.
>>
>> Personally I would probably rather leave base spec relatively bare, if you are
>shooting for universality. Perhaps provide an appendix or something with
>(non-exhaustive set of) examples of the different objectives at most.
>>
>>>> Is the synchronization objective supposed to have some sort of TTL?
>Keep-alive indicator (to indicate unicast sync still makes sense - and what
>would it look like? not covered)? Something else?
>>>>
>>>> Similarly in case of unsolicited multicast, what _exactly_ is ’same state’
>here? Most of the time I would imagine this exchange to be triggered initially
>via unicast, so odds of other nodes sending _exactly_ same packet (to make
>Trickle matter) is low. How to identify “same” synchronization state being
>sent on same link by other nodes? And if such thing does not exist, why use
>Trickle at all?
>> Indeed. This is another thing I thought about yesterday a bit; as I read
>GDN-01 yesterday, the text almost made it seem just synchronization
>between two endpoints, although that sounds very limited. DNCP by default is
>graph-wide and as you stated, it is also undesirable in large networks (you do
>not want every node of the network in the same graph).
>>
>> I _think_ that for ‘general’ case, it would be useful to have
>synchronization objectives of different scopes, and to some degree also with
>different synchronization mechanisms. For example, allow for single pub-sub
>style relationship (I subscribe to your updates of $FOO, you send it to me (and
>other subscribers) when it changes). On the other hand, if you have
>network-wide state of some sort that has potentially multiple sources of
>information, you might wind up with something DNCP-ish.
>>
>> Instead of scopes, in terms of design, to me it matters if there is more than
>one source for information of that particular type; for single source(/few
>~static ones), ~tree(s) of subscriptions works fairly well although of course
>there is the reliable messaging angle to be considered. If there are multiple
>sources, then it gets complex and you may want something from the graph
>synchronization side of the fence. In-protocol prefix assignment with arbitrary
>set of egress points in the network qualifies for example ([1] - now it is
>actually just abstract algorithm that can be reused, with some glue in the
>HNCP document between it and DNCP profile).
>>
>> Interestingly enough, on the HNCP front, we have been having occassional
>discussions on how to deal with scopes, or alternatively provide a way for non
>graph participating node to publish data, and subscribe to updates (think
>management host that is not around always, or some low-power device). So
>ultimately it might turn out that you may want _both_ even for same
>objective(s).
>>
>> Cheers,
>>
>> -Markus
>>
>Anima mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/anima