Hi Brian and Anima Folks,
Thanks for these interesting questions around coordination topic.
Before responding directly to Brian questions, I would suggest we keep in mind
a preliminary question:
Do we intend inside Anima to design coordination solutions that achieve
coordination in between
1 - a pre known set of (function, algorithm) pairs,
2 - any sets of (function, algorithm) pairs, that could be installed on
the network.
I use here the wording (function, algorithm) pair as I consider the autonomic
function along with its implemented ASA piece of code form such a pair. Exemple
of what I mean: e.g. function: load balancing inside an OSPF area ; algorithm:
re-inforcement learning based on links load ratios and modifying the metric of
links.
Dealing with the pros and cons of these approaches:
- Coordination type 1 solutions offer a specific (though tailored)
solution to a given problem (coordinating a given set of ASAs a priori known)
- Coordination type 2 solutions offer a generic (though not tailored)
solution to a wide range of problems (coordinating ASAs which are present in
the Autonomous network not precluding which ASAs they are).
Of course the specific solution is likely to converge faster on the problem it
is designed for but will not adapt to additional Autonomic functions.
[Extra comment: For coordination type 1 solution, I would even favor to embed
the coordination code directly inside the concerned ASA as those are a priori
known, this is a joint design, both the ASA and their coordination. Put simply
the feed-back loops being known, coordinating them is easy.*]
Moving to consensus-forming algorithm, it would be absolutely nice to have
them abroad, and the scope of the draft is quite open to those. This is more or
less simple to achieve depending whether we consider Coordination of type 1 or
Coordination of type 2. I am not versed that much in such algorithms, but the
case in which I have encountered those were addressing a specific problem, so I
cannot imagine whether making them generic is feasible and which are the meta
info they require on the functions to coordinate in order to drive them towards
a consensus. It would be interesting to know more...
The question of having a master is something that does not sound pretty
autonomic, once again I think this also looks quite differently depending of
the context of in which this master is emerging: coordination can either be
delegated to ASAs or achieved by a dedicated coordination function.
Coordination is required when we have a set (a herd) of ASAs instances which
are polling the network and enforcing actions onto the network, each pursuing
its own optimization goal.
- If coordination is delegated to ASAs and a "selected" instance will have the
power to lead the herd, we will have to convince the network operators that
this leader will not overlook the others ASAs optimization goals.
- If we provide a "kind of third-party" Coordination function which we ask the
network operator to entrust with the ability to coordinate this herd of ASAs,
this one having the only objective of getting the best of the others, is easier
to trust.
In draft-ciavaglia-anima-coordination we favor a coordination that is generic
and then external to ASAs**, in which case, the coordination itself may or may
not be based on a master, but it's in any case clearly a third-party
coordination. Then in a dedicated entity but not an ASA as a piece of an
autonomic loop polling the network and enforcing actions onto the network, it
is more a function enforcing settings onto the ASA instances.
Finally, I would clarify a point raised by Brian concerning
draft-ciavaglia-anima-coordination, though we could believe the coord
algorithms aim at avoiding simultaneous actions (and then avoiding collision)
by competing ASAs, they really aim at avoiding that the control loops either
annihilate each other or continuously diverge or continuously move back and
forth.
Regards,
Pierre
* That is also the reason why I consider that there is no need to have external
coordination between instances of a given ASA, I would expect the ASA designers
to have made their job properly and provide the appropriate mechanism to
coordinate the a priori known interacting instances. (There the feed-back loops
are known a priori)
** To be totally honest, there are some expected APIs in the ASA to support the
coordination (e.g. allowing the coordination function to control the pace of
the execution of an ASA control-loop)
> -----Message d'origine-----
> De : Anima [mailto:[email protected]] De la part de Brian E Carpenter
> Envoyé : lundi 13 juin 2016 00:44
> À : Anima WG
> Objet : [Anima] ASA coordination and consensus
>
> Hi,
>
> I was looking at draft-ciavaglia-anima-coordination, and noticed that
> although it mentions several possible algorithms for coordination, they are
> mainly aimed at avoiding simultaneous actions by competing ASAs.
>
> Is there also scope for applying explicit consensus-forming algorithms as
> well?
> There is quite a large literature on consensus algorithms, mainly starting
> with Paxos. I'm not saying that any of that is directly applicable to Anima,
> but it seems like a closely related problem space.
>
> What I did notice is that all consensus algorithms seem to assume that at any
> one moment, there is a designated "master" that is in effect the arbitrator.
> It would be nice to avoid that, if possible. It isn't clear to me whether
> draft-ciavaglia-anima-coordination assumes that the actual coordination
> function runs in a specific master.
>
> Regards
> Brian
>
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
