Subject: [nmrg] NMRG 38th/IETF94 meeting minutes

From: Laurent Ciavaglia <[email-masked]>
Date: Tue, 17 Nov 2015 16:15:00 +0100

Dear NMRG,

The minutes of the 38th NMRG meeting have been uploaded: 
https://www.ietf.org/proceedings/94/minutes/minutes-94-nmrg. (and copied 
below for your convenience).

Thanks to John and Pierre for their notes.

Please let us now if things are missing or incorrect.

The complete set of slides is also now available at: 
https://www.ietf.org/proceedings/94/nmrg.html

Best regards,
Lisandro and Laurent.

*****
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).
         Agents can be used to perform specific tasks required by 
autonomic networking. This takes the form of distributed 
constraint-based optimization. It is unclear if selfish behavior of 
autonomic agents even fits the autonomic networking paradigm.
         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!

*****