Subject: Re: [Anima] DISCOVERY(ANY) mechanism was: RE: GDNP open issues (draft-carpenter-anima-gdn-protocol-01)

From: Michael Richardson <[email-masked]>
Date: Sun, 01 Feb 2015 13:36:52 -0500

Duzongpeng <[email-masked]> wrote:
    > In my understanding, Sheng is talking about the number of objectives,
    > and you are talking about the number of respondents.

That's why I asked, because I was unclear.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 02 Feb 2015 08:06:08 +1300

On 30/01/2015 20:28, Fuyu (Eleven) wrote:
> Hi Brian,
> 
> For example, the autonomic network node sends a discovery message try to discover the objective A. The counterpart responds it and then sends an unsolicited Response message including an objective B which is related to the objective A.  
> The objective B and the objective A have some relationship.

That relates to my idea that in such a case, there is no need to discover B
separately, because A implies B. I'm not sure of the best solution.

Regards
  Brian

> 
> Cheers
> Yu
> 
> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Thursday, January 29, 2015 11:59 AM
> To: Fuyu (Eleven); Sheng Jiang
> Cc: [email-masked]
> Subject: Re: [Anima] unsolicited Response message//RE: GDNP open issues (draft-carpenter-anima-gdn-protocol-01)
> 
> On 29/01/2015 15:09, Fuyu (Eleven) wrote:
>> Hi Sheng,
>>
>>> So, Brian, I guess Yu's message implied a suggestion: you may need to first describe a suitable requirement/scenario/use case. Without it, we may not be able to validate the design.
>>
>> Yes, a description of the requirement/scenario/use case will make sense.
> 
> It would have to be a negotiation objective that a majority of nodes will want to negotiate, to justify an unsolicited broadcast. And I'm not sure I have an eaxmple for that. Any ideas?
> 
>   Brian
> 
> 
>> Thanks
>> Yu
>>
>> -----Original Message-----
>> From: Sheng Jiang
>> Sent: Wednesday, January 28, 2015 2:02 PM
>> To: Fuyu (Eleven); Brian E Carpenter
>> Cc: [email-masked]
>> Subject: RE: [Anima] unsolicited Response message//RE: GDNP open 
>> issues (draft-carpenter-anima-gdn-protocol-01)
>>
>>>> For my opinion, I don't think it is reasonable to allow an 
>>>> unsolicited Response message in Discovery process.
>>>> It may increase extra traffic and the content in unsolicited 
>>>> Response message may not be exactly what the counterpart want.
>>
>>> Hi, Yu,
>>
>>> When discussion unsolicited Response message, it is based on there are some mechanism on the autonomic network node has some hints to predict the counterpart wants the objective in the message. Some example, could be based on previous discovery message or a current discovery message that tries to discover an associated objective.
>>
>>> So, Brian, I guess Yu's message implied a suggestion: you may need to first describe a suitable requirement/scenario/use case. Without it, we may not be able to validate the design.
>>
>>> Best regards,
>>
>>> Sheng
>>
>>>> So it may not speed up the discovery process. Another potential 
>>>> issues is that the Discovery initiator may be subjected to Dos attack.
>>>> But I think it is reasonable to design unsolicited Response message 
>>>> in Synchronization process to synchronize the status of the 
>>>> objective since the status of counterpart had been changed.
>>>
>>>> Cheers
>>>> Yu
>>>
>>> -----Original Message-----
>>> From: Anima [mailto:[email-masked]] On Behalf Of Brian E 
>>> Carpenter
>>> Sent: Tuesday, January 27, 2015 8:56 AM
>>> To: [email-masked]
>>> Subject: [Anima] GDNP open issues
>>> (draft-carpenter-anima-gdn-protocol-01)
>>>
>>> Hi,
>>>
>>> We'd like to get a sense of where to focus discussion leading up to Dallas.
>>> There are a lot of open issues in the -01 draft.
>>> Below I've extracted (and shortened) some that seem most important to 
>>> me personally. I've re-ordered them a bit too. Please send feedback 
>>> (maybe set the Subject of your message accordingly).
>>>
>>> Of course this list is not exclusive, and comments on any aspect of 
>>> the draft are welcome.
>>>
>>>  o  DTLS or TLS vs built-in security mechanism. The current
>>>     approach requires expensive asymmetric cryptographic
>>>     calculations for every message. (D)TLS has startup
>>>     overheads but cheaper crypto per message.
>>>
>>>  o  We mention convergence mechanisms and mechanisms to avoid
>>>     loop dependencies. These issues need more work.
>>>
>>>  o  Is it reasonable to consider that a Discovery Objective is really
>>>     just a set of specific Negotiation and/or Synchronization
>>>     Objectives?
>>>
>>>  o  Would a DISCOVERY(ANY) mechanism be useful during bootstrapping?
>>>
>>>  o  Would it be reasonable to allow an unsolicited Response message
>>>     with Discovery Objective content, to speed up discovery during
>>>     bootstrapping?
>>>
>>>  o  Should we consider a distributed or centralised DNS-like approach
>>>     to discovery (after the initial discovery needed for
>>>     bootstrapping)?
>>>
>>>  o  DoS Attack Protection needs work. Ideas welcome.
>>>
>>>  o  Alternatives to TLV format.  It may be useful to provide a method
>>>     of carrying negotiation/synch objectives in pre-existing formats.
>>>
>>>  o  UDP vs TCP: If messages exceed a reasonable MTU, a TCP mode
>>>     may be necessary.
>>>
>>> Regards,
>>>    Brian
>>>
>>> _______________________________________________
>>> Anima mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/anima
>>>
>>> _______________________________________________
>>> Anima mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/anima

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 02 Feb 2015 08:13:57 +1300

On 31/01/2015 16:34, Duzongpeng wrote:
> Hi Michael:
> 
>     In my understanding, Sheng is talking about the number of objectives, and you are talking about the number of respondents.

In a sense, it doen't matter, because the total response traffic generated
will be proportional to the product of the two.

> 
>   	Some other comments here. 
> The objectives needed to be broadcasted can be further classified.
> 	1. in size, maybe some key elements are short and do not occupied too much bandwidth, but others not

In discovery, I think all the responses will be short.

> 	2. in frequency, maybe some objectives are needed to be updated frequently, but others not

For synchronization, that's true, but we would expect to use some algorithm
such as Trickle to optimize the rate of traffic. For discovery, we do need
to decide how long responses are cached.

   Brian

> 	3. in importance, it is impossible to always broadcast everything, and some essential objectives should be identified
> 	...
> 
> Best regards,
> 
> Zongpeng Du
> 
> 
> From: Anima [mailto:[email-masked]] On Behalf Of Michael Richardson
> Sent: Saturday, January 31, 2015 8:49 AM
> To: [email-masked]
> Subject: Re: [Anima] DISCOVERY(ANY) mechanism was: RE: GDNP open issues (draft-carpenter-anima-gdn-protocol-01)
> 
> 
> Sheng Jiang <[email-masked]> wrote:
>     > This depends on a) how many are ANY, b) how many counterpart may be
>     > discovered.
> 
>     > If ANY is less than twenty or thirty, it may not be a very big
>     > impact. But if ANY is more than a hundred, it may be too much for both
>     > the autonomic network and the initiated node. My guess is we could not
>     > limit how many objectives may be developed in the future.
> 
> I'm confused in this thread if the cardinality we are talking about is the number of objectives,or the number of respondants.
> 
> If we are talking about how many peers there might be, then I wonder how many links are actually natively multicast.  We don't have coax and ethernet hubs anymore, so a device (L3-aware L2-switch) is always involved in multicasting among a network.  If that device speaks GNDP, then the LAN only has two ends.
> 
> While there likely are lots of L2 switches that won't speak GNDP, I would think that where this is first deployed, in operator and backbone DC
> networks, that this won't be the case.   Even modern wifi
> is a star-configuration with MIMO antenna, etc.
> 
> (this scenario is not dissimilar from CDP/LLDP)
> 
> 
> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-
> 
> 
> 
>

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 2 Feb 2015 02:04:33 +0000

>will be proportional to the product of the two.

Exactly! That's what I am talking about. The total response is decided by both the number of objectives and the number of respondents. So, even the topic is mainly initiated by the number of objectives, the discussion cannot omit the number of respondents. The ambition of GDNP is to be able to do L3 discovery. So, in a large scale autonomic networks, if there is no autonomic partition mechanisms deployed, there may be hundreds counterparts.

Best regards,

Sheng

>> 	3. in importance, it is impossible to always broadcast everything, and
>some essential objectives should be identified
>> 	...
>>
>> Best regards,
>>
>> Zongpeng Du
>>
>>
>> Subject: Re: [Anima] DISCOVERY(ANY) mechanism was: RE: GDNP open
>> I'm confused in this thread if the cardinality we are talking about is the
>number of objectives,or the number of respondants.
>>
>> If we are talking about how many peers there might be, then I wonder how
>many links are actually natively multicast.  We don't have coax and ethernet
>hubs anymore, so a device (L3-aware L2-switch) is always involved in
>multicasting among a network.  If that device speaks GNDP, then the LAN
>only has two ends.
>>
>> While there likely are lots of L2 switches that won't speak GNDP, I would
>think that where this is first deployed, in operator and backbone DC

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 18 Feb 2015 16:47:04 +0000

Sorry for the late reply. This discussion touches on one of the points I made in my review of the GNDP. 

I think GNDP is a fairly low level protocol, in the sense that it allows sending and receiving of information, but without the understanding of that information. It is a semantic-free protocol.  Any negotiation, synchronisation, etc will have its own semantic. Therefore, the "logic" of any particular autonomic transaction is not in the GNDP, but in the Autonomic Service Agent which implements the function, and merely uses GNDP to send and receive the information it requires. 

A "TTL" may be required for some state machines, but not for others. In my mind, this is just another TLV to be added to the protocol, if and when needed, and it should probably not be a generic field in all packets. I can't think of any example right now where we would need it. Can you? 

Michael

> From: Anima [mailto:[email-masked]] On Behalf Of Sheng Jiang
> Sent: 28 January 2015 01:59
> To: Brian E Carpenter; [email-masked]
> Subject: Re: [Anima] Mechanisms to avoid loop dependencies was: RE:
> GDNP open issues (draft-carpenter-anima-gdn-protocol-01)
> 
> >> Personally, I don't think we could complete these mechanisms to avoid
> >> loop
> >dependencies. These mechanisms are specific with certain autonomic
> >network agents, who use GDNP to make decisions. On another side, a
> >generic mechanism to detect looped message may be needed. Also some
> >guidance for autonomic network agents design on how to avoid loop
> >dependencies would be great. But I am not sure it is in the scope of GDNP
> design document.
> >It may worth a separated document, I guess.
> >
> >Well, we do need to add a section setting out general guidelines for
> >the definition of negotiation objectives. Mechanisms to guarantee
> >convergence should probably be mentioned there.
> >
> >Maybe we need to add a countdown field (like a TTL) to each negotiation.
> 
> This sounds a reasonable design. :)
> 
> Best regards,
> 
> Sheng
> 
> >    Brian
> >
> >>
> >> Best regards,
> >>
> >> Sheng
> >>
> >>> Regards,
> >>>    Brian
> >>>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Feb 2015 08:11:59 +1300

Hi Michael,
On 19/02/2015 05:47, Michael Behringer (mbehring) wrote:
> A "TTL" may be required for some state machines, but not for others. In my mind, this is just another TLV to be added to the protocol, if and when needed, and it should probably not be a generic field in all packets. 

Well, my opinion is that we always have a risk of a lost message or a dead
state machine, so a timeout is always needed. As for a loop count, I think I
disagree - while you are correct that a specific type of negotiation
should have intrinsic termination conditions, what happens (especially in
a multi-vendor situation) if one side is buggy or for some unpredicted
reason never gives up in an "after you..., no after you..." situation?

But I do agree that the TTL field (which we plan to call "loop-count"
for clarity) should only be present if you actually need it.

Anyway let's discuss the concrete proposal which will be in the -02
draft, rather than discussing in the abstract.

> I can't think of any example right now where we would need it. Can you?

Hmm... that's a good question to ask, but the inverse question is
whether you can prove that every plausible use case will have a
definite termination condition.

Rgds
   Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 20 Feb 2015 17:01:37 +0000

> Sent: 18 February 2015 20:12
> To: Michael Behringer (mbehring); Sheng Jiang; [email-masked]
[...]
> > A "TTL" may be required for some state machines, but not for others. In my
> mind, this is just another TLV to be added to the protocol, if and when
> needed, and it should probably not be a generic field in all packets.
> 
> disagree - while you are correct that a specific type of negotiation should
> have intrinsic termination conditions, what happens (especially in a multi-
> vendor situation) if one side is buggy or for some unpredicted reason never
> gives up in an "after you..., no after you..." situation?
> 
> Anyway let's discuss the concrete proposal which will be in the -02 draft,
> rather than discussing in the abstract.

Thanks for the response. I haven't read -02 yet, will do that.

For now, I'm not convinced yet :-)  
 
> Hmm... that's a good question to ask, but the inverse question is whether
> you can prove that every plausible use case will have a definite termination
> condition.

It depends entirely how you construct the autonomic service agent. To me, there is a logic like "I'll ask my neighbour", which will result in a GDNP packet to be sent. If there is no reply, the state machine will send another packet, and after 3 tries it will report an error or do something else. In other words, the decision on retry, timeout, etc, are not made on the GDNP level, but one level above. 

But, no doubt, we need to continue that discussion ;-) 
 
Michael