Minutes for NMRG at IETF-94
minutes-94-nmrg-3

*****
Minutes of the 38th NMRG meeting - IETF-94 (Yokohama, Japan)

Special session on Managing Networks of Adaptive and Cooperative Agents
Session Chair: Laurent Ciavaglia

Monday (November 2nd, 2015) 2-hour session:

17:10-19:10      Afternoon Session III, Room 413

1.      Session introduction - 10 min
17:00 - 17:10, by Laurent Ciavaglia (session chair)
                https://www.ietf.org/proceedings/94/slides/slides-94-nmrg-1.pdf
                Thanks to the note takers (John and Pierre), and jabber scribe
                (?). The IETF Note Well applies for the meeting. Laurent
                presented the Agenda. The main goal of the meeting is to
                identify topics of high interest for further research and
                investigations by the network management community,
                highlighting the potential needs for future standardization. To
                this end, the meeting will have a few (5) short presentations
                and hopefully enough time for open and fruitful discussions.

2.      Population Management in Clouds is a Do-It-Yourself Technology - 20 min
17:10 - 17:30, by Marat Zhanikeev
                https://www.ietf.org/proceedings/94/slides/slides-94-nmrg-0.pdf
                The presentation will end up connecting to standards and topics
                outlined in the call (cf slide #2). Most things are
                heterogeneous environments and the complexity problem arises
                from this heterogeneity. A network of DCs is a cloud; a network
                of clouds is a federation. This creates inherent heterogeneity
                in software; everyone talks and sends different types of data.
                Cloudify - putting the cloud platform into the device. We are
                still at a relative large abstraction (e.g., DCs or intelligent
                vehicles). Next is desktops/notebooks. Probably should NOT
                cloudify anything below a sensor; smartphones and sensors may
                or may not be cloudified. Bert: if you say you can use your
                phone, this is another device, but this provides yet another
                point of failure. It is more complex than simply having devices
                speak IPv6. Marat: IPv6 is not working today. The purpose of
                Cloudlets is to move processing to the edge to help mitigate
                this. Fundamental problem is complexity. OSPF optimizes one
                parameter for one physical graph, and is NP-hard. VNE maps one
                virtual graph on top of a physical graph, so is even more
                complex. There are two solutions to the complexity problem:
                non-cooperative vs. cooperative (clouds/networks can implement
                local awareness features to improve self-optimization).
                Non-cooperative way is based on probing the cloud, migrating
                some services to gradually optimize, and repeating. Cooperative
                way uses Local Hardware Awareness. For example, different types
                of caching methods can be defined. Because of hotspot traffic,
                cut-through circuits are key. Such circuits are similar to
                Y.mnm (Y.2173), which is made of two key parts: active probing
                and distributed management. Self-optimization, whether
                non-cooperative or cooperative, is based on probing and
                developing intelligence to optimize.

3.      Intent Based NEtwork MODeling (IBNEMO) - 20 min
17:30 - 17:50, by Bert Wijnen
                https://www.ietf.org/proceedings/94/slides/slides-94-nmrg-3.pdf
                Users can build applications with a few set of commands (80/20
                rule) without having to specify all of the details of the
                configuration of devices, flow entries, tunneling, ACLs, etc.
                NEMO app guides the user to program their service. The NEMO
                engine will translate this into a form that NEs can use. NEMO
                defines a very small model (3 object types) with some behavior
                that is used to create a simple domain-specific language (DSL).
                This lets the use specify high-level goals. The NEMO engine is
                network middleware that translates the DSL into network
                configuration from the user 'intent'. NEMO talks to SDN
                controller(s) and could talk to any other control interfaces.
                NEMO is an OpenDaylight project, and part of the Beryllium
                release. Showed a simple script for bandwidth-on-demand DOCSIS
                example. NEMO project has defined an Eclipse plug-in that
                highlights NEMO keywords. The input gets parsed and turned into
                a NEMO REST API. Available in Hackathon. NEMO can dynamically
                update the network behavior if it gets an alert. Question:
                should NEMO also monitor the network? Marat: is there a market?
                Bert: ... Marat: are agents coordinated? Bert: no, it is a
                centralized application Marat: are graphs supported Bert: not
                directly, though nodes and flows are

4.      SUPA Declarative Model - 20 min
17:50 - 18:10, by Jun Bi
                https://www.ietf.org/proceedings/94/slides/slides-94-nmrg-4.pdf
                Goal: declarative, high-level request. Express what should be
                done without telling how. Example: want to travel from A to B -
                don't care which transportation method is offered as long as it
                is within a prescribed budget and meets conditions (e.g.,
                arrive before a certain time). Policy is used to manage service
                behavior. Policy defines rules for governing managed objects
                and service relationships. There are two types of policies: ECA
                and Goal Policies. ECA defines a set of actions to take if the
                conditions are met; event says when to evaluate the condition.
                This explicitly defines what next state to transition to. Goal
                (declarative) policies express what should be done, but not how
                to accomplish the goal. This results in specifying criteria for
                choosing a set of states, any of which is acceptable. Hence,
                rationality is generated by the planner. Declarative: only
                describe the constraints, no information on how to achieve the
                desired state. Example: Seven Bridges of Konigsberg. Procedural
                is extremely complex; declarative is simple. Policy rules can
                manage the behavior of managed entities. They are defining a
                declarative (i.e., logic-based) policy demo, where an external
                interface and API is used to program a core engine that accepts
                declarative and ECA policies. It outputs a solution in YANG.
                Demo on Thursday at Bits and Bytes. Laurent: How to get from
                High Level Policy to Low Level Policy? Tina: ?Use the
                conditions to create ECA level Policy. Bert: ...? Tina : You
                can embed Yang in the policy.


5.      Towards trustworthy interworking of autonomous agents - 20 min
18:10 - 18:30, by Pierre Peloso
                https://www.ietf.org/proceedings/94/slides/slides-94-nmrg-5.pdf
                This is about how you can build trust into behavior of
                autonomous agents. Autonomous: an agent keeps its own
                decision-making process. Learning agent: agents that can also
                perform reasoning (e.g., learn beliefs about the environment).
                Analogy: Agents are people playing instruments, but they
                collectively make music under guidance of conductor. John: this
                is a blending of choreography and orchestration. Pierre: yes.
                We must therefore be able to trust what the agent is doing.
                Characterize-Test-Verify-Certify the performance and
                conformance of the function/system wrt referential functions.
                We also need to ensure that trusted agents can work together,
                even if each agent has its own goal. This means they need to be
                coordinated, and resolve their own conflicts. There are eight
                approaches, consisting of two types of conflict maps (static
                and dynamic), two different schemes (static and dynamic) that
                can each be centralized or distributed. Example context: radio
                access networks using SON. Challenge: rapidly varying traffic.
                Solution: Dynamically adapting network. Induced Issues: chaos
                in network due to conflicts, caused by competition between
                autonomous behaviors (e.g., two SONs will fight over the same
                radio resources). Challenge #1: identify conflicts, both prior
                to deployment and after deployment. Must avoid false positives
                without missing true positives. Made a static conflict map of
                parameters, controls, KPIs, unified metrics, and controls. This
                doesn't take into account things like overlapping base station
                coverage. Another way to do this is to wait until agents are
                deployed, and then use self-description from autonomic
                functions to make inventory of metrics monitored, of actions
                performed, and how they are computed. Build graphs showing
                control loops, and identify conflicting control loops. Yet
                another way is during deployment, after the agents are running,
                by being able to either find new dependencies between metrics
                or being able to determine that different autonomic functions
                are conflicting. For example, infer conflicts on monitored
                metrics. Challenge #2: coordination mechanisms.
                Self-orchestration: each agent provides an estimated utility
                for the next time slot, and an orchestrator gives the token to
                the agent having the highest utility. Hierarchical
                optimization: one control loop has precedence over others
                (e.g., via time). This is a family of operations. Centralized
                multi-objective optimization: aggregation of the weighted
                utilities of each agent, find a Pareto optimal solution. A
                "super-agent" decides. Use of control theory: weight each
                control loop. Marat: Comment to use attractors to achieve
                coordination? Bert: are they open source implementations and
                are those available? Laurent: in the frame of the EU funded
                project UNIVERSELF (www.univerself-project.eu), software has
                been developed and showcased. The open source availability has
                to be checked. If interested, please contact me.

6.      Reconciling autonomic networking with agent-based modelling - 20 min
18:30 - 18:50, by Dimitri Papadimitriou
                https://www.ietf.org/proceedings/94/slides/slides-94-nmrg-6.pdf
                Note: due to technical issues, Dimitri was not able to give the
                presentation remotely. Laurent presented the slides on behalf
                of Dimitri. Adaptivity: the ability to react and/or change
                decisions in a timely and cost-effective manner when events
                occur that affect the delivery of services. An agent-based
                model consists of a set of agents, with their attributes and
                behaviors, as well as their interactions. The goal of
                autonomics is to hide, or reduce, complexity. However, the goal
                of agents is to model emergent behavior (i.e., produce
                complexity). Agent-based model (ABM): primary goal is to search
                for explanatory insight into the collective behavior of agents
                (which don't necessarily need to be "intelligent"); the ability
                of agents to be autonomous fits a-priori self-X principles by
                hiding real complexity to the “outsider” and handle more and
                more complexity on their own. ABM, technique to model
                decentralized optimization/decision problem solving with agents
                having individual goals and constraints, negotiate to reach a
                global satisfactory/ acceptable state.
                        - Fits policy framework (map state to action and
                        enforcement) - Example: DCOP, ACO, particle swarm
                        optimization
                But only if some level of cooperation can be considered. Then
                autonomic management framework (and objectives) coupled to
                agent-based model leads to distributed version of constraint
                optimization problems as main research goal. Otherwise, if
                selfish behavior (thus, self-interested agents) considered as
                main characteristic of Internet environments then
                (non-cooperative) game theoretic models for distributed
                optimization would better fit this objective (but does it still
                fit the autonomic framework ?) No questions received.

7.      Open discussion - 20 min
18:50 - 19:10
                https://www.ietf.org/proceedings/94/slides/slides-94-nmrg-2.pdf
                Laurent highlighted some items/ideas to discuss: Towards
                smarter, more powerful network operations... (cf slide #2)
                        New (autonomic) functionalities? ; Human in the loop,
                        reliability, trust? ; (vertical) Integration? Agent <->
                        Node, Operator <-> Agent ; Application domains? 5G, IoT
                        … ; First areas in need for standards?
                Bert: what do we want the nmrg to do in the short term?
                Laurent: possibly a report, or possibly a wider event. why not
                an article to IETF journal? We could also document the problem
                space/challenges and/or use cases/techniques. Develop link with
                other research/working groups, other organizations, other
                communities. cf slide #3. Marat is suggesting that networks
                advertise their functions It isn't what the agents want, it is
                what the network can provide. You need a coordination function
                to do this. Similar to the three problems of social
                engineering: cognition, coordination, cooperation. Marat: what
                is meant by coordination w/r economy and draws a parallel with
                economy concepts. Pierre: what about conflicts in the intents
                (i.e requesting agents to do congestion avoidance on one side
                and others to do energy efficiency while their utility metrics
                do contradict). End of the meeting, thanks to the presenters,
                the note takers and jabber scribe, and to all the participants!

*****