From nobody Thu Nov 5 06:02:59 2015 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A7A1B2D4C for ; Thu, 5 Nov 2015 06:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.461 X-Spam-Level: X-Spam-Status: No, score=-1.461 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwdPK_3FKyfd for ; Thu, 5 Nov 2015 06:02:54 -0800 (PST) Received: from smtp.inf.ufrgs.br (smtp.inf.ufrgs.br [143.54.11.23]) by ietfa.amsl.com (Postfix) with ESMTP id B853B1B2D50 for ; Thu, 5 Nov 2015 06:02:52 -0800 (PST) Received: from air-de-lisandro.inf.ufrgs.br (Air-de-Lisandro.inf.ufrgs.br [143.54.13.228]) by smtp.inf.ufrgs.br (Postfix) with ESMTPSA id DB7D1120A56 for ; Thu, 5 Nov 2015 12:02:49 -0200 (BRST) From: Lisandro Zambenedetti Granville Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 5 Nov 2015 12:02:50 -0200 To: Network Management Research Group Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: [nmrg] Call for NMRG co-chair X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 14:02:58 -0000 Dear NMRG Olivier Festor, who has been serving as NMRG co-chair, needs to step = down because of profissional commitments as dean of Computer Science at = TELECOM Nancy. We are now starting the process of finding a new NMRG co-chair. If you = want to volunteer or know good candidates, you can either contact me = (granville@inf.ufrgs.br) or the IRTF chair, Lars Eggert = (lars@netapp.com). It would be also interesting to hear some words about = your occasional plans for NMRG (what would you like to keep/change, for = example). Best regards, Lisandro (NMRG Co-Chair) Lars (IRTF chair)=20= From nobody Mon Nov 16 01:57:48 2015 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620281B2F81 for ; Mon, 16 Nov 2015 01:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.164 X-Spam-Level: X-Spam-Status: No, score=0.164 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwxzdbDt-X3W for ; Mon, 16 Nov 2015 01:57:45 -0800 (PST) Received: from smtp.inf.ufrgs.br (smtp.inf.ufrgs.br [143.54.11.23]) by ietfa.amsl.com (Postfix) with ESMTP id 14C391B2F7F for ; Mon, 16 Nov 2015 01:57:44 -0800 (PST) Received: from air-de-lisandro.inf.ufrgs.br (Air-de-Lisandro.inf.ufrgs.br [143.54.13.228]) by smtp.inf.ufrgs.br (Postfix) with ESMTPSA id 758081208D5 for ; Mon, 16 Nov 2015 07:57:40 -0200 (BRST) From: Lisandro Zambenedetti Granville Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <752AC713-B9C0-46F9-9BB5-FD79213CD856@inf.ufrgs.br> Date: Mon, 16 Nov 2015 07:57:40 -0200 To: Network Management Research Group Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: [nmrg] Welcome to the new NMRG co-chair X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 09:57:47 -0000 Dear all I am happy to announce that Laurent Ciavaglia = is taking over the responsibility = of co-chairing with me the NMRG. We wish him success in this new role! = We want also to thank Olivier Festor for his contribution as NMRG = co-chair in the last year, a position which is now being occupied by = Laurent. Best regards, Lisandro Granville= From nobody Mon Nov 16 06:10:18 2015 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4358B1B2AD6 for ; Mon, 16 Nov 2015 06:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.086 X-Spam-Level: X-Spam-Status: No, score=-15.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYkPWUUZPYor for ; Mon, 16 Nov 2015 06:10:00 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF24D1A1A2E for ; Mon, 16 Nov 2015 06:09:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=647; q=dns/txt; s=iport; t=1447682992; x=1448892592; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=MbOhw+96GfA0rxJSJ6EALVtsIIRX8+7JEd+MIZQKAhM=; b=hyJjDj5FlLoedl5I53/9uCRgAgVg4gtYFgoSVXGZDrLot+zkyGiEufQF 5CMe3zFD+xfjMQxXGYnHbk8ivj5JeNQzJq/H607OQaHHYwXXKbJViJq1P VKRTJgasXWJ66wgWqjuOtC/TNehEKkkqd2iTyuWJA5RZBmSaEQr7Frt9I o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAgDZ4klW/4kNJK1egztTb75gAQ2BZ?= =?us-ascii?q?BcKhW8CgTo4FAEBAQEBAQGBCoQ1AQEEAQEBNzQLEAsYCSUPBRM2E4guDbosAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBFASLUoJxhTOBFQWOEYg3jR8InEUfAQFChCUdN?= =?us-ascii?q?IVLAQEB?= X-IronPort-AV: E=Sophos;i="5.20,303,1444694400"; d="scan'208";a="47297597" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-6.cisco.com with ESMTP; 16 Nov 2015 14:09:51 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tAGE9pRb030318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Nov 2015 14:09:51 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id tAGE9oWv029197; Mon, 16 Nov 2015 06:09:50 -0800 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id tAGE9n4w029195; Mon, 16 Nov 2015 06:09:49 -0800 Date: Mon, 16 Nov 2015 06:09:49 -0800 From: Toerless Eckert To: Lisandro Zambenedetti Granville Message-ID: <20151116140949.GA29056@cisco.com> References: <752AC713-B9C0-46F9-9BB5-FD79213CD856@inf.ufrgs.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <752AC713-B9C0-46F9-9BB5-FD79213CD856@inf.ufrgs.br> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Network Management Research Group Subject: Re: [nmrg] Welcome to the new NMRG co-chair X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 14:10:08 -0000 Congratulations, Laurent! On Mon, Nov 16, 2015 at 07:57:40AM -0200, Lisandro Zambenedetti Granville wrote: > Dear all > > I am happy to announce that Laurent Ciavaglia is taking over the responsibility of co-chairing with me the NMRG. We wish him success in this new role! We want also to thank Olivier Festor for his contribution as NMRG co-chair in the last year, a position which is now being occupied by Laurent. > > Best regards, > > Lisandro Granville > _______________________________________________ > nmrg mailing list > nmrg@irtf.org > https://www.irtf.org/mailman/listinfo/nmrg From nobody Tue Nov 17 07:15:15 2015 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3452E1A9047 for ; Tue, 17 Nov 2015 07:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.785 X-Spam-Level: X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5GRDObUTyg4 for ; Tue, 17 Nov 2015 07:15:08 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 284791A9046 for ; Tue, 17 Nov 2015 07:15:07 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id A3BD3746518CA for ; Tue, 17 Nov 2015 15:15:01 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id tAHFExQm027284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 17 Nov 2015 16:15:04 +0100 Received: from [172.27.205.132] (135.239.27.39) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 17 Nov 2015 16:15:01 +0100 From: Laurent Ciavaglia To: "nmrg@irtf.org" Organization: Alcatel-Lucent Bell Labs France Message-ID: <564B4474.30906@alcatel-lucent.com> Date: Tue, 17 Nov 2015 16:15:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------010404000001030909000001" X-Originating-IP: [135.239.27.39] Archived-At: Subject: [nmrg] NMRG 38th/IETF94 meeting minutes X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 15:15:13 -0000 --------------010404000001030909000001 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit 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! ***** --------------010404000001030909000001 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit 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!

*****



--------------010404000001030909000001-- From nobody Mon Nov 23 07:53:58 2015 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568AC1A891A for ; Mon, 23 Nov 2015 07:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NS4R5W32xvub for ; Mon, 23 Nov 2015 07:53:54 -0800 (PST) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id A54481A890F for ; Mon, 23 Nov 2015 07:53:54 -0800 (PST) Received: from [130.104.228.59] (ramin-THINK.dhcp.info.ucl.ac.be [130.104.228.59]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sadre@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 4BA2811E687 for ; Mon, 23 Nov 2015 16:53:48 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 4BA2811E687 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1448294028; bh=PBKZCHWqXFDv2IhRoCmXxT7rsKd5WDy6N2N5knPI1zo=; h=From:Subject:To:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=lVB+NEFjszPt29eiTEGN1U+OmpVyahsLjpofBBG5XLGgLLbsyLFEF/8fr8IkMlLK7 zJ0VVY32r8ZAWVGHK4OicYcDHqUCFHLr4B16KKy/b0FZsitZbOgGvEBzBqQPKIixDg CwvL7oT3noF3PuetdWN6cDXpvJGOK5BRr26xHna4= From: Ramin Sadre To: nmrg@irtf.org Message-ID: <56533693.5010204@uclouvain.be> Date: Mon, 23 Nov 2015 16:53:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99-beta1 at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 4BA2811E687.AD999 X-SGSI-MailScanner: Found to be clean X-SGSI-From: ramin.sadre@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: [nmrg] 2nd CFP: TMA 2016 X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 15:53:57 -0000 Dear NMRG members, Here is the 2nd CFP for TMA 2016. The workshop will take place at UCL in Belgium next year, so just around the corner for some of you. Please note the new submission deadline, which should give you plenty of time to prepare a lot of paper submissions :) Regards, Ramin (on behalf of the workshop chairs) ******************************************* 2nd CALL FOR PAPERS 8th International Workshop on Traffic Monitoring and Analysis (TMA 2016) http://tma.ifip.org/2016/ **** NEW SUBMISSION DEADLINE **** Location: Louvain-la-Neuve, Belgium Date: April 7-8 Submission deadline: December 22nd, 2015 (11:59 PM EST) Scope: The Traffic Monitoring and Analysis workshop (TMA) is a highly selective venue for the presentation of early-stage research and controversial works on all the aspects of network measurements. The focus is on improving the practice or application of measurements, across the entire network stack up to the application layer, with an emphasis on new areas of network communication such as Software-Defined Networks, Cloud services, Content Distribution Networks, social networks, mobile applications and data centers, but also including more traditional measurement topics, such as traffic classification, anomaly detection, network performance evaluation and traffic analysis. Some relevant topics include: - Measurements of data centers, virtualized systems and cloud-based services - Measurements of distributed systems, including content distribution and P2P networks - Application layer measurements, including web services, social networks, mobile applications - Traffic analysis, characterization, visualization and classification - Anomaly detection - Measurements of home, wireless and cellular networks - Security and privacy in network measurement and analysis - Network measurement and monitoring methods and techniques - Network monitoring systems and distributed monitoring architectures - Network performance evaluation, troubleshooting and topology measurements - Measurement based experiments: repeatability tests, shared datasets, collaborative platforms - Measurements of the Quality of Service and Quality of Experience - Measurement in Software-Defined Networks - Measuring the impact of Big Data processing on networks - Traffic measurement and analysis using Big Data frameworks Accepted papers will be published in the IFIP Digital Library. The best paper will receive an award sponsored by IFIP. Extended versions of the two best papers on machine learning, data mining and Big Data for network monitoring and analysis will be fast-tracked for publication in a Special Issue of Elsevier Computer Networks, subject to further revision: http://www.journals.elsevier.com/computer-networks/call-for-papers/special-issue-on-machine-learning-data-mining-and-big-data/ Papers describing experiments with users or user data (e.g., passwords, social network information), should follow the basic principles of ethical research, e.g., beneficence (maximizing the benefits to an individual or to society while minimizing harm to the individual), minimal risk (appropriateness of the risk versus benefit ratio), voluntary consent, respect for privacy, and limited deception. When appropriate, authors are encouraged to include a subsection describing these issues, and the review process may examine the ethical soundness of the paper just as it would examine the technical aspects. Authors unsure about topical fit or ethical issues are welcome to contact the program committee co-chairs at tma2016-chairs@googlegroups.com Submission guidelines: Authors should only submit original work that has not been published before and is not under submission to any other venue. Submissions must not exceed 8 pages in IEEE 2-column style. A template is available on: http://www.ieee.org/conferences_events/conferences/publishing/templates.html Submissions that do not comply with these requirements will be rejected without review. Important dates: Submission deadline: Tuesday, December 22, 2015 (11:59 PM EST) Notification to authors: Monday, February 1, 2016 Camera-ready deadline: Monday, February 15, 2016 TMA workshop: April 7-8, 2016 Please visit the workshop homepage for further information: http://tma.ifip.org/2016/ From nobody Mon Nov 23 08:52:16 2015 Return-Path: X-Original-To: nmrg@ietfa.amsl.com Delivered-To: nmrg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917F51A906B for ; Mon, 23 Nov 2015 08:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jj6E2RESyokd for ; Mon, 23 Nov 2015 08:52:14 -0800 (PST) Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03E0B1A9079 for ; Mon, 23 Nov 2015 08:52:12 -0800 (PST) Received: from Macintosh-2.fritz.box ([83.163.239.181]) by smtp-cloud3.xs4all.net with ESMTP id l4s81r00g3vXPcr014s9dV; Mon, 23 Nov 2015 17:52:10 +0100 To: Ramin Sadre , nmrg@irtf.org References: <56533693.5010204@uclouvain.be> From: "Bert Wijnen (IETF)" Message-ID: <56534438.8040607@bwijnen.net> Date: Mon, 23 Nov 2015 17:52:08 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56533693.5010204@uclouvain.be> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [nmrg] 2nd CFP: TMA 2016 X-BeenThere: nmrg@irtf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Management Research Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 16:52:15 -0000 That is in the same week as IETF in Bueanos Aires, isn't it? Not so good planning I would think. Bert On 23/11/15 16:53, Ramin Sadre wrote: > Location: Louvain-la-Neuve, Belgium > Date: April 7-8