1 / 46

Autonomic Computing and Networking

Autonomic Computing and Networking. Pieter Simoens , Steven Latré Filip De Turck , Bart Dhoedt Future Internet Department 17/05/2011 Gent. Outline. Research Context Thin/Smart client computing Autonomic Communications Introduction to Demo’s. Why autonomic systems ?.

azriel
Download Presentation

Autonomic Computing and Networking

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Autonomic Computing and Networking Pieter Simoens, Steven Latré Filip De Turck, Bart Dhoedt Future Internet Department 17/05/2011 Gent

  2. Outline • Research Context • Thin/Smart client computing • Autonomic Communications • Introduction to Demo’s

  3. Why autonomic systems ? Autonomic systems : Managing complex things is difficult

  4. Autonomic Systems Observation Complexity of ICT-systems is growing Issues • Management gets complex (high opex) • System configuration error-prone and sub-optimal • Difficult to recover from unforeseen situations

  5. Autonomic Systems Inspiration : The Human Body • Distributed responsibilities • Collaborating control systems • Each system: optimised for specific task • Under control of central system • Learns and adapts online • Governed by high-level goal: Stay Alive

  6. Autonomic Systems Autonomic systems decrease management complexity by performing low-level configurations themselves • The system adapts its behavior to changes in • The environment • End-user needs • Service requirements • It is governed by high-level policies • Representing business goals • Defined and managed by human operators

  7. Autonomic Computing "Civilization advances by extending the number of important operations which we can perform without thinking about them.” - Alfred North Whitehead • MAPE control loop (IBM 2001) • Knows itself and its context • Configures, reconfigures, heals and protects itself • Optimizes continuously • Can interact with outside world • Anticipates to balance resources and needs, without involving users

  8. ACN @ Future Internet Dpt. • 1. Autonomic Technologies • - Automatic policy translation • - Autonomic adaptation • - Scalability and multi-agent management • - Learning • - Design and implementation of an autonomic service platform • 2. Autonomic Communication • 3. Autonomic Distributed Computing • 4. Integrated infrastructures • 5. Smart Client Computing • 6. Autonomics for IoT • - Sensor networks • - ICT for Green

  9. Outline • Research Context • Thin/Smart client computing • Autonomic Communications • Introduction to Demo’s

  10. Introduction • Thin client ? • ideallylimited to I/O functions (display, network) • CPU and storagehosted in the network • Rationale : • Enhanced software life cycle management • Data security, privacy and integrity • Increased terminal lifetime • Data is available optimized for wired LAN environments, non I/O intensive applications

  11. Objectives mobile multimedia QoE energy-efficient intelligent • X-layer optimization for better performance • wireless link optimizations • image transmission optimizations • optimized management(profiling, migration, reservations, ...) public hotspot core network access network

  12. MobiThin • FP7-STREP (call 1, Challenge 1.1 “Future Internet”) • Time frame • start : Jan 1st, 2008 • end : June 30th, 2010

  13. MobiThin system Build a mobilethin client service in wirelessenvironment for heterogeneousapplications

  14. System Overview

  15. Project Highlights - Integrated System Management Server SLM Thin Client Server SLM (physical host) User Session SLM (VM that runs apps) Channel server side SLM Channel clientside SLM Mobile Device SLM • Fully functional E2E system has been built, based on requirements analyzed at the start of the project • Cross-layer optimizations = the core business of the project 1) wireless X-layer mechanisms (thin client protocol - PHY-MAC) 2) thin client protocol optimizations • scheduled updates • event buffering • 3) self-management of the service • VM migration supporting QoS, peak load avoidance, … • server consolidation for green computing • 4) SLM framework spanning the complete system developed

  16. Relocate session to other server, start/stop extra server Redistribution of resources to certain session, compensating over-spenders by under-spenders Choice of channel (= image transmission protocol) Tuning of channel parameters: color depth, UDP/TCP, user event buffering, scheduled updates, streaming (Semi-) Physical changes: display brightness, wireless interface sleep time Possible actions per level Management Server SLM Thin Client Server SLM (physical host) User Session SLM (VM that runs apps) Channel serverside SLM Channel clientside SLM Mobile Device SLM

  17. Server Consolidation System load • When there is low work load on the system, energy can be saved by shutting down redundant thin client servers. • When the work load raises, extra thin client servers should be powered on. t Server Consolidation Algorithm Decide how many servers are needed in the (near) future based on the system load in a previous time frame

  18. Server Consolidation P  CPU  #online servers Max. Energy Savings: 45%

  19. MobiThin Gains • Successful project, rated “Excellent” by EU • Strong partnership, good prospects for future collaborations • Foundation laid for innovative research ideas • Good output in publications • > 20 accepted publications • Best paper award • Standardisation through ETSI (ISG-MTC) • 2 work items completed

  20. From Thin to Smart Thin client : Run the whole application on a server Problems Constant and high bandwidth needed Always extra latency introduced Doesn't work well with some multimedia applications (e.g. augmented reality)

  21. Smart client Only offload parts of the software

  22. Only offload parts of the software Adapt the deployment to the changing context and the changing optimization goal Smart client

  23. Outline • Research Context • Thin/Smart client computing • Autonomic Communications • Introduction to Demo’s

  24. The goal of autonomic communications Optimize the Quality of Experience, maximize the revenue … and do it fast! From high-level goals To low-level device configurations • Router> enable • Router# configure terminal • Router(config)# interface ethernet 1/1 • Router(config-if)# ethernet • Router(config-line)# exit • Router(config)# end • Router#

  25. Computing vs. Communications Autonomic Computing Autonomic Communications Extension to IBM’s model Heterogeneous devices Networked system More complex control loops Model-based translation Semantically enriched Reasoning & learning Policy-based management • Presented by IBM in 2001 • Homogeneous components • 1 computing environment • MAPE control loop • Monitor • Analyze • Plan • Execute

  26. Complexity • Manage complexity of an Operations Support System • Real-time dynamic management • Per service or per subscriber management Will we ever be able to tackle such complexity? • Parallel with robotics • Millions of interactions • Trying to “mimic” human behavior • Still in early stages

  27. Introducing intelligence into the network Privacy Scalable HOW? Trustworthy Intelligent Human-governed Secure

  28. A federation of autonomic elements (AE) distributed reasoning service discovery context exchange contract negotiation AE AE AE AE AE AE AE AE AE AE AE AE AE AE AE

  29. Research focus Design and implementation of architectural components for federated management of future networks and services policy driven loosely coupled management components end-to-end federation of management domains semantic communication and collaboration

  30. Research directions automated policy translation control loop design semantic inter-domain contract negotiation autonomic cloud management

  31. Automatic policy translation

  32. FP7 ECODE • Introducing autonomic behaviour in today’s routers • FP7 Strep (Call 1.6 “New paradigms and experimental facilities”) • Timeframe • Start: September 2008 • End: December 2011

  33. FP7 ECODE Experimental COgnitive Distributed Engine Cognitive engine on top of an existing router

  34. Router Router Learning Weak coupling Routing Routing Routing + Learning Strong Coupling Forwarding Forwarding Forward + Learning Today Step 1: overlay Step 2: integrated Integration of learning capability into self-adaptive closed-loop control process Communication systems autonomously interrelated and controlled, dynamically adapting to changing environments Role of learning • How to diagnose their own state, own activity/behavior, and environment over time (thus detect, identify, & analyze problems) • How (cost-effective) and when (timely) to adapt decisions and to tune react/execute (and thus capable to increase their functionality and performance) • When to operate autonomously and to cooperate Augment control paradigm of pre-defined decision making process, and pre-determined execution, with learning component

  35. ECODE machine learning in practice Different TCP stacks cause different levels of fairness Highspeed Cubic Cubic Reno Vegas Cubic Vegas Reno Highspeed Vegas

  36. ECODE machine learning in practice • Different TCP stacks  different responsiveness • Variations due to • Different TCP dialects • Defective stacks: ignores congestion warnings • Profile Based Accountabilityholding subscribers (i.e. stacks) accountable for their behaviour reward stacks in the good zone Good zone responsiveness punish stacks in the bad zone aggressiveness

  37. Outline • Research Context • Thin/Smart client computing • Autonomic Communications • Introduction to Demo’s

  38. Demo 1 – hybrid remote display Motivation: graphical content diversity multimedia application video streaming, 3D game office applicationtext editor, spreadsheet, e-mail client • large areas of solid color • few colors • updates cover small part of screen • low update frequency • no homogeneous areas • fine-grained complex color patterns • updates cover whole screen • high update frequency Encode through remote display protocol (VNC) Encode through video codec(H.264)

  39. Dynamically switching between protocols Decision on output encoding format based on amount of motion between subsequent frames • inefficient transport of multimedia data via a thin client protocol • high bandwidth • irresponsive user interface • video codecs are designed for transport of video • minimal bandwidth requirements for a given amount of motion • higher client CPU load due to decoding

  40. Demo set-up

  41. Demo 2 – SLRG inferencing • Identification of Shared Link Resource Groups Shared Link Resource Group

  42. Demo 2 – SLRG inferencing • Goal: improve recovery time of link failures by learning. • OSPF area • One node is enabled with SLRG inference • Learns

  43. Demonstration – iLab.t setup • Using three nodes ctl vhost-0 vid OSPF area n1 n2 n3 n4 n5 n6 n7 n8 Demo control Video streaming video output n9 n10

  44. Demonstration – video screen • Showing three video streams

  45. Demonstration – video screen • What to look for? • Video interruptions; • standard OSPF (left side) and SRG inference enabled OPSF (right side). • For learned SRGs • compare left and right parts of astream; • compare streams; • compare local andremote link failures.

  46. Demonstration – status screen

More Related