Autonomic computing and networking
This presentation is the property of its rightful owner.
Sponsored Links
1 / 46

Autonomic Computing and Networking PowerPoint PPT Presentation


  • 99 Views
  • Uploaded on
  • Presentation posted in: General

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 ?.

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


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

Outline

  • Research Context

  • Thin/Smart client computing

  • Autonomic Communications

  • Introduction to Demo’s


Why autonomic systems

Why autonomic systems ?

Autonomic systems :

Managing complex things is difficult


Autonomic systems

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


Autonomic systems1

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


Autonomic systems2

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


Autonomic computing

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


Acn @ future internet dpt

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


Outline1

Outline

  • Research Context

  • Thin/Smart client computing

  • Autonomic Communications

  • Introduction to Demo’s


Introduction

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


Objectives

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


Mobithin

MobiThin

  • FP7-STREP (call 1, Challenge 1.1 “Future Internet”)

  • Time frame

    • start : Jan 1st, 2008

    • end : June 30th, 2010


Mobithin system

MobiThin system

Build a mobilethin client service in

wirelessenvironment for heterogeneousapplications


System overview

System Overview


Project highlights integrated system

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


  • Possible actions per level

    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


    Server consolidation

    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


    Server consolidation1

    Server Consolidation

    P  CPU  #online servers

    Max. Energy Savings: 45%


    Mobithin gains

    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


    From thin to smart

    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)


    Smart client

    Smart client

    Only offload parts of the software


    Smart client1

    Only offload parts of the software

    Adapt the deployment to the changing context and the changing optimization goal

    Smart client


    Outline2

    Outline

    • Research Context

    • Thin/Smart client computing

    • Autonomic Communications

    • Introduction to Demo’s


    The goal of autonomic communications

    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#


    Computing vs communications

    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


    Complexity

    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


    Introducing intelligence into the network

    Introducing intelligence into the network

    Privacy

    Scalable

    HOW?

    Trustworthy

    Intelligent

    Human-governed

    Secure


    A federation of autonomic elements ae

    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


    Research focus

    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


    Research directions

    Research directions

    automated policy translation

    control loop design

    semantic inter-domain contract negotiation

    autonomic cloud management


    Automatic policy translation

    Automatic policy translation


    Fp7 ecode

    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


    Fp7 ecode1

    FP7 ECODE

    Experimental COgnitive Distributed Engine

    Cognitive engine on top of an existing router


    Integration of learning capability into self adaptive closed loop control process

    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


    Ecode machine learning in practice

    ECODE machine learning in practice

    Different TCP stacks cause different levels of fairness

    Highspeed

    Cubic

    Cubic

    Reno

    Vegas

    Cubic

    Vegas

    Reno

    Highspeed

    Vegas


    Ecode machine learning in practice1

    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


    Outline3

    Outline

    • Research Context

    • Thin/Smart client computing

    • Autonomic Communications

    • Introduction to Demo’s


    Demo 1 hybrid remote display

    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)


    Dynamically switching between protocols

    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


    Demo set up

    Demo set-up


    Demo 2 slrg inferencing

    Demo 2 – SLRG inferencing

    • Identification of Shared Link Resource Groups

    Shared Link Resource Group


    Demo 2 slrg inferencing1

    Demo 2 – SLRG inferencing

    • Goal: improve recovery time of link failures by learning.

    • OSPF area

    • One node is enabled with SLRG inference

      • Learns


    Demonstration ilab t setup

    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


    Demonstration video screen

    Demonstration – video screen

    • Showing three video streams


    Demonstration video screen1

    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.


    Demonstration status screen

    Demonstration – status screen


  • Login