Subject: Re: [Anima] I-D Action: draft-ciavaglia-anima-coordination-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Jul 2015 12:11:23 +1200

Hi,

A few comments from a quick reading:

> 3.  Guiding principles
...
>    o  Be able to fully or partially suspend/stop one or multiple
>       autonomic functions, temporarily or an undetermined amount of time
>       until the situation evolves (Authority property).

To me this implies that the coordinator must be aware of what every ASA
is doing for every objective that requires coordination. It also implies
that the coordinator can request every ASA to suspend operation.

That implies in turn that every ASA must have a "coordination interface"
by which it can report its actions to the coordinator and receive "suspend"
and "run" requests from that coordinator.

Is that correct? If so we need to know soon, so that we can ensure that
the signaling protocol supports such an interface.

> 4.3.1.  Times of the identification of interactions between AF
...
>    At build-time, a common description of the autonomic function
>    attributes (metrics, parameters, actions, capabilities...) allows to
>    construct a "static interaction map" from the a-priori knowledge...

I don't know what you mean by "build-time." As I understand, we want
the creation of a network from factory-condition devices to be incremental
and autonomic, and there would be no such things as a static map.

> Requirements onto the AF -

The AF is a rather abstract concept. Don't we need concrete requirements
to be met by each ASA.

> Requirements onto the ACP -

We also need requirements on the signlaing protocol.

Regards
   Brian

Regards
   Brian Carpenter

---

From: "PELOSO, PIERRE (PIERRE)" <[email-masked]>
Date: Wed, 15 Jul 2015 11:53:33 +0000

Hi Brian and All,

Thanks for your reading/comments, please find in-line some additional elements/clarifications.

Regards,

Pierre

> -----Message d'origine-----
> De : Anima [mailto:[email-masked]] De la part de Brian E Carpenter
> Envoyé : mercredi 15 juillet 2015 02:11
> À : [email-masked]
> Cc : Anima WG
> Objet : Re: [Anima] I-D Action: draft-ciavaglia-anima-coordination-00.txt
> 
> Hi,
> 
> To me this implies that the coordinator must be aware of what every ASA is
> doing for every objective that requires coordination. It also implies that
> the coordinator can request every ASA to suspend operation.
> 
> Is that correct? If so we need to know soon, so that we can ensure that the
> signaling protocol supports such an interface.

Indeed, that is exact. We do really think such an interface is needed, what its signature is needs to be worked out (preferably collectively), though we have some preliminary ideas... (like: detail what an AF/ASA is meant to do, suspend or not the execution of the loop, etc...)

> I don't know what you mean by "build-time." As I understand, we want the
> creation of a network from factory-condition devices to be incremental and
> autonomic, and there would be no such things as a static map.

Would the build-time be better understood, would we have said "at the time at which the code of the AF/ASA are being designed/implemented". Hence, when designing multiple AF it is possible (though it's conceptual which does not mean useless) to draw a static map, because the AF designer knows how the control loop work (which are their input and outputs) and hence how they are likely to interact. I am taking here the assumption that the AF are not coded one shot for a specific network, but that they can be "deployed" over different networks, which is why the static vocabulary is used, as the design/build time is prior any instantiation.

> The AF is a rather abstract concept. Don't we need concrete requirements to
> be met by each ASA.

That is indeed a possibility, and it is possible to implement it this way. Nevertheless, I believe that there is more than a concept to the AF, as it is defined out of a group of ASA, which should all-together pursue a common goal. I am then afraid that we elude completely the gathering opportunity provided by the AF concept when designing the ASA we're likely to forget some bits in the end. I am nonetheless convinced that the instantiation of the AF concept, should happen through the ASAs in fine. Actually, my point here is not to promote an extra element, but more to provide the possibility to consider either ASA when dealing with an Agent on a given equipment or AF when dealing with the group of Agents over a (part of) network...

> We also need requirements on the signlaing protocol.

Noted.
 
> Regards
>    Brian
> 
> 
> 
> Regards
>    Brian Carpenter
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Laurent Ciavaglia <[email-masked]>
Date: Wed, 15 Jul 2015 23:05:47 +0200

Hello,

Let me just add a few things to Pierre's answer.
Pleae see below inline, marked [LC].

Thanks, best regards, Laurent.

>> the coordinator can request every ASA to suspend operation.
[LC]: maybe a more correct formulation of the cited coordination 
function requirement would be to write: "_the result_ of the 
coordination function could result in fully or partially suspend/stop 
one or multiple autonomic functions, temporarily or an undetermined 
amount of time until the situation evolves (Authority property)."
Just to be sure that the "coordinator" Brian is talking about can be 
viewed/implemented as a single (centralized) entity or as a collective 
behavior (distributed).
>> signaling protocol supports such an interface.
{LC]: I would say that _each AF_ must have a coordination interface, but 
there are underlying model considerations on the 
roles/boundaries/responsabilities between AF and ASAs.
>> The AF is a rather abstract concept. Don't we need concrete requirements to
[LC]: Again, I don't think we have aligned our views about AF and ASA. 
In our model, AF have both concrete (paper) specifications and concrete 
implementation. The ASAs is one form/part of the AF, e.g. the ASAs exist 
only at the run-time (when the AF instantiates its agents to comply with 
the deployment/operation objectives).

-- 

Bien cordialement, Best regards,

*Laurent Ciavaglia*

Secure Cloud Networking

Bell Labs | Alcatel Lucent

phone: +33 160 402 636

email: [email-masked] 
<mailto:[email-masked]>

linkedin: laurentciavaglia <http://fr.linkedin.com/in/laurentciavaglia/>

address: Route de Villejust | 91620 Nozay | France

---

From: John Strassner <[email-masked]>
Date: Thu, 16 Jul 2015 21:26:01 -0700

Hi all,

please find some comments on the discussion, as well as some new issues,
using <jcs>..</jcs>. Apologies, I only made it to 4.3.1; I'll try and
finish later.

regards,
John

<jcs>
First, questions on new topics:
Page 4:

  "Maximize the autonomic network utility, i.e. mitigate the
   (observed or inferred) detrimental effects of conflicting
   autonomic functions (Efficiency property)."

I agree with the description from "i.e." onwards, but why is
this referred to as "autonomic network utility"? This doesn't
match the common definition of utility (i.e., preference to
consume something).

Page 5:
  "Deviate the least possible autonomic functions from their design
   objective(s) and individual goal(s) (Liberality property)."

Do you mean "Each autonomic function should deviate in the least
possible way from its design objective(s) and individual goal(s)?
Otherwise, I don't understand this sentence.

   "...autonomic function descriptor(s)/capabilities"

PLEASE don't use the word descriptor; I cannot help but think of
NFV descriptors, which are badly broken.

   "...internal specifications of autonomic functions"

s/specifications/implementations

   "Be able to cope with several thousands of simultaneous
    interactions"

I think this will cause a centralized system to melt down...
</jcs>

3.  Guiding principles

...

[LC]: maybe a more correct formulation of the cited coordination function
requirement would be to write: "*the result* of the coordination function
could result in fully or partially suspend/stop one or multiple autonomic
functions, temporarily or an undetermined amount of time until the
situation evolves (Authority property)."
Just to be sure that the "coordinator" Brian is talking about can be
viewed/implemented as a single (centralized) entity or as a collective
behavior (distributed).

<jcs>
I think that Laurent's clarification helps, but I still don't think that
this works. If the coordination function has to wait until an autonomic
function produces a result (even an intermediate one, though that didn't
seem to be covered), then harm (e.g., a conflict was produced) could have
still occurred. Unless you implement some type of transactional integrity
mechanism, I don't see how this could work.

I'm also concerned about the amount of state that the coordination function
would have to keep. I continue to believe that for the real-world, we
either have a fully distributed system, or what is known in network
management as an "umbrella system", where you have a hierarchy of managers.
</jcs>

{LC]: I would say that *each AF* must have a coordination interface, but
there are underlying model considerations on the
roles/boundaries/responsabilities between AF and ASAs.

<jcs>
I agree that a dedicated coordination interface is required. However, I'm
missing the point that you are making about model considerations, sorry.
</jcs>

        Indeed, that is exact. We do really think such an interface is
needed, what its signature is needs to be worked out (preferably
collectively),
        though we have some preliminary ideas... (like: detail what an
AF/ASA is meant to do, suspend or not the execution of the loop, etc...)

<jcs>
Page 6, new comment:
I realize that these three states are not exhaustive, but I think that
defining some additional states now, such as In Test, Failed, Started, and
Completed would help.
</jcs>

...

Would the build-time be better understood, would we have said "at the time
at which the code of the AF/ASA are being designed/implemented".

<jcs>
IFF you are referring to model-driven engineering, where code can be
dynamically defined and generated by a machine, then I'm happy. If you
aren't, then I'm lost.
</jcs>

Hence, when designing multiple AF it is possible (though it's conceptual
which does not mean useless) to draw a static map, because the AF designer
knows how the control loop work (which are their input and outputs) and
hence how they are likely to interact. I am taking here the assumption that
the AF are not coded one shot for a specific network, but that they can be
"deployed" over different networks, which is why the static vocabulary is
used, as the design/build time is prior any instantiation.

<jcs>
Sorry to be nit-picking, but this assumes that the control loop is static
(FOCALE's could be altered at runtime), and that it always behaves in known
ways, and that it has no side effects. That is a lot of ifs. Don't get me
wrong, it's a good starting point (this is really hard work), but I wanted
to plant a seed to be worked on in the future.
</jcs>

[LC]: Again, I don't think we have aligned our views about AF and ASA. In
our model, AF have both concrete (paper) specifications and concrete
implementation. The ASAs is one form/part of the AF, e.g. the ASAs exist
only at the run-time (when the AF instantiates its agents to comply with
the deployment/operation objectives).

<jcs>
I think what Brian was worried about is the case where an AF is implemented
by multiple agents from multiple nodes (unless I misunderstand what was
written in RFC7575). In that case, the ASA needs to have a definition
(FOCALE used software contracts, a la Eiffel, so that semantics could be
defined), and hence, it does need concrete requirements. Please correct me
if I am misunderstanding...
</jcs>

That is indeed a possibility, and it is possible to implement it this way.
Nevertheless, I believe that there is more than a concept to the AF,
as it is defined out of a group of ASA, which should all-together pursue a
common goal. I am then afraid that we elude completely the gathering
opportunity provided by the AF concept when designing the ASA we're likely
to forget some bits in the end. I am nonetheless convinced that the
instantiation of the AF concept, should happen through the ASAs in fine.
Actually, my point here is not to promote an extra element, but more to
provide the possibility to consider either ASA when dealing with an Agent
on a given equipment or AF when dealing with the group of Agents over a
(part of) network...

<jcs>
There's a bit of a chicken-and-egg problem here. Let's assume we define a
transfer function that specifies the desired behavior of an AF. In order to
implement said behavior, then each ASA would need to know what part of the
AF that it is implementing. In order to select appropriate ASAs that can
implement an AF, then each ASA needs its own robust definition. This is why
I used software contracts.

In FOCALE, I used the concept of capabilities, needs, and constraints,
expressed through metadata. This would allow a node to say "I want to
implement this AF" (need) and other nodes (including itself) that had ASAs
could then reply "I can do this part of the AF".
</jcs>

Noted.

On Wed, Jul 15, 2015 at 2:05 PM, Laurent Ciavaglia <
[email-masked]> wrote:

> De : Anima [mailto:[email-masked] <[email-masked]>] De la part de Brian E Carpenter
> function requirement would be to write: "*the result* of the coordination
> function could result in fully or partially suspend/stop one or multiple
> autonomic functions, temporarily or an undetermined amount of time until
> the situation evolves (Authority property)."
>  {LC]: I would say that *each AF* must have a coordination interface, but
> Anima mailing [email-masked]://www.ietf.org/mailman/listinfo/anima
>
>
> --
>

-- 
regards,
John

---

From: Laurent Ciavaglia <[email-masked]>
Date: Mon, 20 Jul 2015 18:42:26 +0200

Dear John, all,

Please find below some attempts to answer ;)

Best regards, Laurent.

On 17/07/2015 06:26, John Strassner wrote:
> Hi all,
>
> please find some comments on the discussion, as well as some new 
> issues, using <jcs>..</jcs>. Apologies, I only made it to 4.3.1; I'll 
> try and finish later.
>
> regards,
> John
>
> <jcs>
[LC]: We meant the autonomic network performance / efficiency / 
productivity. If utility (as in economics/game theory) is misleading, 
then we could change for one of the 3 other terms proposed, or a better 
one, any suggestion..?
[LC]: We believe it is also important to consider both the autonomic 
network "productivity" (A) and the autonomic function "productivity" 
(B). (A) could be defined (e.g. via the Intent) as a function (in the 
mathematical sense) of the (B)s present in the said network. Obviously, 
it might not always be possible to maximize all autonomic functions 
productivity at the same time.

> Otherwise, I don't understand this sentence.
[LC]: Yes.

> NFV descriptors, which are badly broken.
[LC]: In the UniverSelf project, we've used the term "manifest". I have 
no strong feeling about the term to use, as long as we agree on _what_ 
needs to be described and how to name it (for convenience).

> s/specifications/implementations
[LC]: Why do you propose this change? We wanted to say that the 
coordination function should not prescribe/specify how the internals of 
autonomic functions should look like / be organized.

> I think this will cause a centralized system to melt down...
[LC]: Good ;) This would argue in favor of distributed approaches ( but 
we have to evaluate / demonstrate first).
[LC]: When re-reading this requirement, I think it should be refined to 
precise the scope (domain, area...) where the coordination function 
applies. Also, we need to agree/provide reference(s) on the number of 
interactions we foresee.
     One example I have in mind is a mobile network with a dozen of SON 
functions deployed per base station. Depending on the deployment model / 
size of the network, this could rapidly grow in numbers.

> I think that Laurent's clarification helps, but I still don't think 
> that this works. If the coordination function has to wait until an 
> autonomic function produces a result (even an intermediate one, though 
> that didn't seem to be covered), then harm (e.g., a conflict was 
> produced) could have still occurred. Unless you implement some type of 
> transactional integrity mechanism, I don't see how this could work.
[LC]: Trying to clarify on the comments from Brian and John:
     -@Brian: there are various degrees to treat the "conflicts", not 
necessarily requiring that the coordinator is aware of everything.
     -@John: we do NOT set a goal for the coordination function to avoid 
all and every conflicts (especially the initial ones), however once 
conflicts occur / are detected, the coordination function shall mitigate 
/ remove them to the best of its / the system capabilities.
     Another approach is to initially set all AFs in off/idle mode, and 
only start them (on/active mode) when a proper coordination mechanism is 
in place or when the coordination mechanism has adapted to the new AFs 
starting.

>
> I'm also concerned about the amount of state that the coordination 
> function would have to keep. I continue to believe that for the 
> real-world, we either have a fully distributed system, or what is 
> known in network management as an "umbrella system", where you have a 
> hierarchy of managers.
[LC]: I agree with you. And this one of the big challenge for the 
coordination function, and I expect we can propose a good solution in 
ANIMA to this problem.
[LC]: However, we already have some hints / guidelines: the problem 
space can be split into smaller ones (e.g. using clusters or conflict 
groups), some coordination strategies are simple (e.g. time separation, 
hierarchy) and may cover most of the operator's need, there are 
several/multiple distributed mechanisms available that could be used.

> {LC]: I would say that _each AF_ must have a coordination interface, 
> but there are underlying model considerations on the 
> I agree that a dedicated coordination interface is required. However, 
> I'm missing the point that you are making about model considerations, 
> sorry.
> </jcs>
[LC]: Through the discussions on the ANIMA mailing lists, we have 
repeatedly touched on various concepts and definitions. For the AF and 
ASA, I think the views are not all aligned yet.
[LC]: For instance, in UniverSelf, the AF is the central element and the 
ASAs are instantiated by the AF. Only the AF is addressable, and the AF 
redirects the commands/information back/forth to/from the ASAs. That's 
why I was saying the AF should have a coordination interface and not 
necessarily (all) the ASAs. Again, I am not saying that this model is 
better than another one, but as long as we have not defined more clearly 
the relationships between AF, AN, ASA... then we will keep bumping into 
some misunderstandings. Same stands for the AF lifecycle (cf your below 
point, the manifest/descriptor...

> defining some additional states now, such as In Test, Failed, Started, 
> and Completed would help.
> </jcs>
[LC]: Sure! for the -00 version of the draft we stayed minimalist. We 
are currently writing a draft describing the Autonomic Function, its 
manifest, lifecycle/states... we will be glad to include comments/inputs 
from the group.
[LC]: This stands also for the coordination draft: feel free to send us 
your comments/inputs for modification, and thanks for the initial feedback.

>> Would the build-time be better understood, would we have said "at the 
>> time at which the code of the AF/ASA are being designed/implemented".
>> **
>> <jcs>
>> dynamically defined and generated by a machine, then I'm happy. If 
>> you aren't, then I'm lost.
>> </jcs>
[LC]: We mean the time when the AF is designed/specified/implemented 
(and its description made available to the customer). The example I have 
in mind is the 3GPP SON functions which are described in the different 
releases. From these specification, a static (in the sense that what 
those function will do, and use as parameters will not change anymore / 
will remain valid in all cases) map can be constructed.
[LC]: Such a (3GPP SON functions) static map shows the possible 
interactions among the SON functions, independent of their eventual 
deployment. If for instance, SON function A and SO function B will both 
set / measure an antenna power, the static map identifies this 
interaction. Whether this interactions really happen at run-time depends 
if the two functions are deployed/instantiated on the same resources 
(e.g. the same base station antenna), but this we don't know and don't 
need to know to draw the static map.

>>
>> Hence, when designing multiple AF it is possible (though it's 
>> conceptual which does not mean useless) to draw a static map, because 
>> the AF designer knows how the control loop work (which are their 
>> input and outputs) and hence how they are likely to interact. I am 
>> taking here the assumption that the AF are not coded one shot for a 
>> specific network, but that they can be "deployed" over different 
>> networks, which is why the static vocabulary is used, as the 
>> design/build time is prior any instantiation.
>>
>> **
>> <jcs>
>> Sorry to be nit-picking, but this assumes that the control loop is 
>> static (FOCALE's could be altered at runtime), and that it always 
>> behaves in known ways, and that it has no side effects. That is a lot 
>> of ifs. Don't get me wrong, it's a good starting point (this is 
>> really hard work), but I wanted to plant a seed to be worked on in 
>> the future.
>> </jcs>
[LC]: I see your point, and I don't think Pierre was saying that the 
control loop are static. Rather he was mentioning that the control loop 
has some defined inputs/outputs/parameters that are known at the 
design/implementation time and that this information is enough (in a 
first place) to infer possible interactions. The run-time (hidden) 
behaviors, side effects... should be captured in the deployment- and 
run-time interaction maps which are really the dynamic ones (and the 
ones used to actually resolves the conflicts).
[LC]: It would be nice to incorporate run-time adaptation of the control 
loops in the coordination function mechanics (e.g via dynamic 
capabilities updates/exchanges).

> In our model, AF have both concrete (paper) specifications and 
> concrete implementation. The ASAs is one form/part of the AF, e.g. the 
> ASAs exist only at the run-time (when the AF instantiates its agents 
> to comply with the deployment/operation objectives).
>
> <jcs>
> I think what Brian was worried about is the case where an AF is 
> implemented by multiple agents from multiple nodes (unless I 
> misunderstand what was written in RFC7575). In that case, the ASA 
> needs to have a definition (FOCALE used software contracts, a la 
> Eiffel, so that semantics could be defined), and hence, it does need 
> concrete requirements. Please correct me if I am misunderstanding...
> </jcs>
[LC]: You are correct, and in UniverSelf, we also have concrete 
requirements (and specifications) for respective the AFs and ASAs 
concepts. As mentioned above, we should align an a "reference" model for 
the AF/ASA in order to align our views/proposals and see if/how we agree 
on the common ground.

>> That is indeed a possibility, and it is possible to implement it this 
>> way. Nevertheless, I believe that there is more than a concept to the 
>> AF,
>> as it is defined out of a group of ASA, which should all-together 
>> pursue a common goal. I am then afraid that we elude completely the 
>> gathering opportunity provided by the AF concept when designing the 
>> ASA we're likely to forget some bits in the end. I am nonetheless 
>> convinced that the instantiation of the AF concept, should happen 
>> through the ASAs in fine. Actually, my point here is not to promote 
>> an extra element, but more to provide the possibility to consider 
>> either ASA when dealing with an Agent on a given equipment or AF when 
>> dealing with the group of Agents over a (part of) network...
>>
>> <jcs>
>> There's a bit of a chicken-and-egg problem here. Let's assume we 
>> define a transfer function that specifies the desired behavior of an 
>> AF. In order to implement said behavior, then each ASA would need to 
>> know what part of the AF that it is implementing. In order to select 
>> appropriate ASAs that can implement an AF, then each ASA needs its 
>> own robust definition. This is why I used software contracts.
>>
>> In FOCALE, I used the concept of capabilities, needs, and 
>> constraints, expressed through metadata. This would allow a node to 
>> say "I want to implement this AF" (need) and other nodes (including 
>> itself) that had ASAs could then reply "I can do this part of the AF".
>> </jcs>
[LC]: We should probably submit (yet) another research project on 
autonomic networks? ;p
[LC]: More seriously, I am not sure we talking about the same concepts 
(or at least not to the same extent).
[LC]: If I understand you correctly John, you are referring to the 
ability to build an AF out of modules, said modules being ASAs, it that 
correct? I agree this is something desirable, but I am not sure this is 
the model ANIMA has n mind for the moment (others, please correct me if 
I am wrong). I would call this modularity and composability.
[LC]: In my understanding, the ANIMA model is the following: As an 
exmaple, an AF is doing load-balancing. When deployed, the AF is 
instantiated as 3 agents (3 load balancing ASAs), each running over 3 
different nodes. Each ASA is a full copy of the AF function (the 
complete control loop). For me this is different from (though not 
incompatible with ) the model you propose above (modularity and 
composability).
[LC] This reminds me of the initial discussion we had on the ANIMA 
charter, and especially Dimitri Papadimitriou's proposal phrased as: 
"[...] can _*inter-agent protocol primitives be unified*_ and can 
_*agent functionality be factorized *_[...]" and "[...] common AN 
infrastructure, specification (in particular, _*cross-function single AN 
vs. cross-element multi AN*_) following the design goals of 
factorization, distribution, and unification required across use cases 
[...]"
> On Wed, Jul 15, 2015 at 2:05 PM, Laurent Ciavaglia 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hello,
>
>>>     À :[email-masked]  <mailto:[email-masked]>
>>>     Cc : Anima WG
>     coordination function could result in fully or partially
>     suspend/stop one or multiple autonomic functions, temporarily or
>     an undetermined amount of time until the situation evolves
>     (Authority property)."
>     Just to be sure that the "coordinator" Brian is talking about can
>     be viewed/implemented as a single (centralized) entity or as a
>     collective behavior (distributed).
>     {LC]: I would say that _each AF_ must have a coordination
>     interface, but there are underlying model considerations on the
>     [LC]: Again, I don't think we have aligned our views about AF and
>     ASA. In our model, AF have both concrete (paper) specifications
>     and concrete implementation. The ASAs is one form/part of the AF,
>     e.g. the ASAs exist only at the run-time (when the AF instantiates
>     its agents to comply with the deployment/operation objectives).
>
>>>     [email-masked]  <mailto:[email-masked]>
>     linkedin: laurentciavaglia
>     <http://fr.linkedin.com/in/laurentciavaglia/>
>
>     [email-masked] <mailto:[email-masked]>

-- 

*Laurent Ciavaglia*

Secure Cloud Networking

phone: +33 160 402 636

---

From: John Strassner <[email-masked]>
Date: Fri, 24 Jul 2015 09:59:24 -0700

Hi Laurent,

thanks for your additional clarification. In general, I think I understand
what you would like to do. Some small additional comments (<jcs2/>) on the
relevant extracted text follow.

<jcs>
productivity. If utility (as in economics/game theory) is misleading, then
we could change for one of the 3 other terms proposed, or a better one, any
suggestion..?

<jcs2>
To me, mitigating detrimental effects is more of a productivity problem.
</jcs2>

 [LC]: We believe it is also important to consider both the autonomic
network "productivity" (A) and the autonomic function "productivity" (B).
(A) could be defined (e.g. via the Intent) as a function (in the
mathematical sense) of the (B)s present in the said network. Obviously, it
might not always be possible to maximize all autonomic functions
productivity at the same time.

<jcs2>
To me, this has more of a performance or efficiency connotation (something
like, the autonomic network should be capable of correctly executing n
autonomic functions, and 0.8n was achieved. Of course, this could get very
complex (just think of adding one simple parameter, such as priority), but
it is still appealing (at least to me).
</jcs2>

...

   "...autonomic function descriptor(s)/capabilities"
PLEASE don't use the word descriptor; I cannot help but think of
 NFV descriptors, which are badly broken.
[LC]: In the UniverSelf project, we've used the term "manifest". I have no
strong feeling about the term to use, as long as we agree on what needs to
be described and how to name it (for convenience).

<jcs2>
how about just saying "autonomic function capabilties"?
</jcs2>

<jcs2>
What confuses me is "internal specifications", which is why I thought you
were talking about implementation. Do you instead me something like a
software contract?
</jcs2>

...

3.  Guiding principles
...
I think that Laurent's clarification helps, but I still don't think that
this works. If the coordination function has to wait until an autonomic
function produces a result (even an intermediate one, though that didn't
seem to be covered), then harm (e.g., a conflict was produced) could have
still occurred. Unless you implement some type of transactional integrity
mechanism, I don't see how this could work.
[LC]: Trying to clarify on the comments from Brian and John:
     -@Brian: there are various degrees to treat the "conflicts", not
necessarily requiring that the coordinator is aware of everything.
     -@John: we do NOT set a goal for the coordination function to avoid
all and every conflicts (especially the initial ones), however once
conflicts occur / are detected, the coordination function shall mitigate /
remove them to the best of its / the system capabilities.
     Another approach is to initially set all AFs in off/idle mode, and
only start them (on/active mode) when a proper coordination mechanism is in
place or when the coordination mechanism has adapted to the new AFs
starting.

<jcs2>
I'm feeling a lot better. Perhaps the original sentence could be improved,
but also perhaps I read it too literally. :-)
Certainly, one possible solution to a dependency conflict is that if an AF
named Foo does not execute correctly, other AFs that depend on Foo should
not be started. In FOCALE, we handled this using formal software contracts,
which may also be of use here.
</jcs2>
...
4.3.1.  Times of the identification of interactions between AF
...
<jcs>
There's a bit of a chicken-and-egg problem here. Let's assume we define a
transfer function that specifies the desired behavior of an AF. In order to
implement said behavior, then each ASA would need to know what part of the
AF that it is implementing. In order to select appropriate ASAs that can
implement an AF, then each ASA needs its own robust definition. This is why
I used software contracts.
In FOCALE, I used the concept of capabilities, needs, and constraints,
expressed through metadata. This would allow a node to say "I want to
implement this AF" (need) and other nodes (including itself) that had ASAs
could then reply "I can do this part of the AF".
</jcs>
[LC]: We should probably submit (yet) another research project on autonomic
networks? ;p

<jcs2>
Probably :-)
</jcs2>

[LC]: More seriously, I am not sure we talking about the same concepts (or
at least not to the same extent).
 [LC]: If I understand you correctly John, you are referring to the ability
to build an AF out of modules, said modules being ASAs, it that correct? I
agree this is something desirable, but I am not sure this is the model
ANIMA has n mind for the moment (others, please correct me if I am wrong).
I would call this modularity and composability.
 [LC]: In my understanding, the ANIMA model is the following: As an
exmaple, an AF is doing load-balancing. When deployed, the AF is
instantiated as 3 agents (3 load balancing ASAs), each running over 3
different nodes. Each ASA is a full copy of the AF function (the complete
control loop). For me this is different from (though not incompatible with
) the model you propose above (modularity and composability).
 [LC] This reminds me of the initial discussion we had on the ANIMA
charter, and especially Dimitri Papadimitriou's proposal phrased as: "[...]
can inter-agent protocol primitives be unified and can agent functionality
be factorized [...]" and "[...] common AN infrastructure, specification (in
particular, cross-function single AN vs. cross-element multi AN) following
the design goals of factorization, distribution, and unification required
across use cases [...]"

<jcs2>
I agree, we are talking about slightly different things. I was indeed
talking about being able to dynamically composit an AF, in which case it
doesn't matter if the AF is operating on a single ASA or if its
functionality is provided by multiple ASAs. I do think that this is much
harder, though, and that it would be perfectly reasonable to postpone such
functionality to a future phase of ANIMA.
</jcs2>

regards,
John

On Mon, Jul 20, 2015 at 9:42 AM, Laurent Ciavaglia <
[email-masked]> wrote:

> network "productivity" (A) and the autonomic function "productivity" (B).
> (A) could be defined (e.g. via the Intent) as a function (in the
> mathematical sense) of the (B)s present in the said network. Obviously, it
> might not always be possible to maximize all autonomic functions
> no strong feeling about the term to use, as long as we agree on *what*
> [LC]: Good ;) This would argue in favor of distributed approaches ( but we
> have to evaluate / demonstrate first).
> conflicts occur / are detected, the coordination function shall mitigate /
> remove them to the best of its / the system capabilities.
> only start them (on/active mode) when a proper coordination mechanism is in
> place or when the coordination mechanism has adapted to the new AFs
> starting.
>
>
> function would have to keep. I continue to believe that for the real-world,
> we either have a fully distributed system, or what is known in network
> coordination function, and I expect we can propose a good solution in ANIMA
> to this problem.
> [LC]: However, we already have some hints / guidelines: the problem space
> can be split into smaller ones (e.g. using clusters or conflict groups),
> some coordination strategies are simple (e.g. time separation, hierarchy)
> and may cover most of the operator's need, there are several/multiple
> distributed mechanisms available that could be used.
>
>  </jcs>
>
>   {LC]: I would say that *each AF* must have a coordination interface,
> repeatedly touched on various concepts and definitions. For the AF and ASA,
> I think the views are not all aligned yet.
> redirects the commands/information back/forth to/from the ASAs. That's why
> I was saying the AF should have a coordination interface and not
> [LC]: Sure! for the -00 version of the draft we stayed minimalist. We are
> currently writing a draft describing the Autonomic Function, its manifest,
> lifecycle/states... we will be glad to include comments/inputs from the
> group.
> (and its description made available to the customer). The example I have in
> mind is the 3GPP SON functions which are described in the different
> releases. From these specification, a static (in the sense that what those
> function will do, and use as parameters will not change anymore / will
> remain valid in all cases) map can be constructed.
> deployment. If for instance, SON function A and SO function B will both set
> / measure an antenna power, the static map identifies this interaction.
> Whether this interactions really happen at run-time depends if the two
> functions are deployed/instantiated on the same resources (e.g. the same
> base station antenna), but this we don't know and don't need to know to
> draw the static map.
>
>
>
> control loop are static. Rather he was mentioning that the control loop has
> some defined inputs/outputs/parameters that are known at the
> design/implementation time and that this information is enough (in a first
> place) to infer possible interactions. The run-time (hidden) behaviors,
> side effects... should be captured in the deployment- and run-time
> interaction maps which are really the dynamic ones (and the ones used to
> actually resolves the conflicts).
> loops in the coordination function mechanics (e.g via dynamic capabilities
> updates/exchanges).
>
> implemented by multiple agents from multiple nodes (unless I misunderstand
> what was written in RFC7575). In that case, the ASA needs to have a
> definition (FOCALE used software contracts, a la Eiffel, so that semantics
> could be defined), and hence, it does need concrete requirements. Please
> correct me if I am misunderstanding...
> </jcs>
>
> requirements (and specifications) for respective the AFs and ASAs concepts.
> As mentioned above, we should align an a "reference" model for the AF/ASA
> in order to align our views/proposals and see if/how we agree on the common
> ground.
>
> way. Nevertheless, I believe that there is more than a concept to the AF,
> [LC]: More seriously, I am not sure we talking about the same concepts (or
> at least not to the same extent).
> [LC]: If I understand you correctly John, you are referring to the ability
> to build an AF out of modules, said modules being ASAs, it that correct? I
> agree this is something desirable, but I am not sure this is the model
> ANIMA has n mind for the moment (others, please correct me if I am wrong).
> I would call this modularity and composability.
> different nodes. Each ASA is a full copy of the AF function (the complete
> control loop). For me this is different from (though not incompatible with
> ) the model you propose above (modularity and composability).
> charter, and especially Dimitri Papadimitriou's proposal phrased as: "[...]
> can *inter-agent protocol primitives be unified* and can *agent
> functionality be factorized *[...]" and "[...] common AN infrastructure,
> specification (in particular, *cross-function single AN vs. cross-element
> multi AN*) following the design goals of factorization, distribution, and
> unification required across use cases [...]"
>
>> function requirement would be to write: "*the result* of the
>> coordination function could result in fully or partially suspend/stop one
>> or multiple autonomic functions, temporarily or an undetermined amount of
>> time until the situation evolves (Authority property)."
>>  {LC]: I would say that *each AF* must have a coordination interface,

-- 
regards,
John