My Research in Network Monitoring and Measurements

1
My Research in Network Monitoring and Measurements

• Matti Siekkinen
• University of Oslo
• TKK / HIIT
• April 9./10., 2008

2
Outline

• Part 1 Root Cause Analysis of TCP Throughput
• What limits the throughput of a given TCP
  transfer?
• Main results from my Ph.D. work
• Part 2 Monitoring as a First Class Citizen in an
  Autonomic Network Architecture
• Building monitoring support within autonomic
  network architecture
• Work is part of the EU funded ANA project

2
3
Root Cause Analysis of TCP Throughput

• Joint work with
• Guillaume Urvoy-Keller, Ernst W. Biersack
• Institut Eurecom, France
• Denis Collange
• France Télécom RD, France

4
Root Cause Analysis of TCP Throughput

• Introduction and Motivation
• Root cause analysis techniques
• Taxonomy of TCP rate limitation causes
• Our approach to infer limitation causes
• Case study on Performance Analysis of ADSL
  Clients
• Conclusions

4
5
Motivation

• ISPs would like to know how clients are doing
• What are the performance limitations that
  Internet applications are facing?
• Why does a client with 4Mbit/s ADSL access obtain
  only total download rate of few KB/s with
  eDonkey?
• Why, after upgrading my subscription, I see no
  improvement in throughput?
• The network provides few answers directly
• The network elements are by design not
  intelligent
• Need techniques for traffic measurement and
  analysis

5
6
Root Cause Analysis of TCP Throughput

• What?
• Analysis and inference of the reasons that
  prevent a given TCP connection from achieving a
  higher throughput.
• Reasons are called limitation causes
• Why TCP?
• TCP typically over 90 of all traffic

6
7
Background

• TCP Rate Analysis Tool (T-RAT) by Zhang et al.
  (sigcomm 2002)
• Pioneering research work
• Ground breaking insights
• It is not all congestion!
• Opened up many questions
• We implemented and tested it
• Results are way off too often
• Fundamental assumptions do not hold
• T-RAT analyzes unidirectional traffic
• Passively collected measurements
• Usable in more cases (asymmetric paths)
• The source of the problems

7
8
Our approach

• We analyze only passive traffic measurements
• Capture and store all TCP/IP headers, analyze
  later off-line
• Observe traffic at a single measurement point
• Applicable in diverse situations
• E.g. at the edge of an ISPs network
• Know all about clients downloads and uploads
• Bidirectional packet traces
• Connection level analysis

8
9
Challenges (1/3)

• Single measurement point anywhere along the path
• Cannot/dont want to control it
• Complicates estimation of parameters (RTT and
  cwnd)

• A RTT d1
• ? piece of cake
• B RTT d3d4
• ? How to get d4?
• (Did ack2 trigger
• data2?)

ack2
A
B
9
10
Challenges (2/3)

• A lot of data to analyze
• Potentially millions of connections per trace
• Deep analysis
• For each connection of each trace
• Compute a lot of metrics
• Divide connections into pieces
• Analyse separately and compute more metrics
• Need to keep track of everything

Need solutions for data management ?InTraBase
10
11
Challenges (3/3)

• Find the right metrics to characterize all
  limitations
• Need to gather a lot of experience
• Get it right!
• Several methods for computing a particular
  metrics
• Choose the best for the situation
• Try to maximize correctness of results
• E.g. 5 ways to estimate RTTs
• Careful validations
• Benchmark with a lot of reference traces
• Cross validate metrics

11
12
Root Cause Analysis of TCP Throughput

• Introduction and Motivation
• Root cause analysis techniques
• Taxonomy of TCP rate limitation causes
• Our approach to infer limitation causes
• Case study on Performance Analysis of ADSL
  Clients
• Conclusions

12
13
Scope

• Study long lived TCP connections
• Short connections are another topic
• Dominated by slow start?
• Assume FIFO scheduling
• Necessary for link capacity estimations with
  packet dispersion techniques
• Does not hold for all networks
• E.g. cable modem and 802.11 access networks

13
14
Limitation Causes for TCP Throughput

• Application
• Transport layer
• TCP receiver
• Receiver window limitation
• TCP protocol
• Congestion avoidance mechanism
• Network layer
• Bottleneck link

14
15

• Application that sends small amounts of data at
  constant rate

40 bytes pushed
15
16

• Application that sends larger bursts separated by
  idle periods
• BitTorrent, HTTP/1.1 (persistent)

transfer periods
only keep-alive messages
16
17
Limitation Causes Application

• The application does not even attempt to use all
  network resources
• TCP connections are partitioned into two periods
• Bulk Transfer Period (BTP) application provides
  constantly data to transfer
• Never run out of data in buffer B1
• Application Limited Period (ALP) opposite of BTP
• TCP has to wait for data because B1 is empty

B1
17
18
Limitation Causes TCP Receiver

• Receiver advertized window limits the rate
• max amount of outstanding bytes min(cwnd,rwnd)
• ? Sender is idle waiting for ACKs to arrive
• Flow control
• Sender application
• overflows receiving
• application
• Buffer B2 is full
• Configuration problem (unintentional)
• default receiver advertized window is set too low
• window scaling is not enabled

B2
18
19
Limitation Causes Network

• Limitation is due to congestion at a bottleneck
  link
• Shared bottleneck obtain only a fraction of its
  capacity
• Non-shared bottleneck obtain all of its capacity

19
20
Our Approach to Root Cause Analysis

• Divide Conquer
• Partition connections into BTPs and ALPs
• Filter out application impact
• Analyze the bulk transfer periods for limitation
  by
• TCP receiver
• TCP protocol
• Network
• Methods are based on metrics computed from packet
  headers

20
21
Why filter out application effect?

• We try to study TCP/IP path properties but end up
  measuring application effect instead!

21
22
Distinguishing BTPs from ALPsIsolate Merge
algorithm

• 1. phase Isolate
• Fact TCP always tries to send MSS size packets
• Consequence small packets (size lt MSS) and idle
  time indicate application limitation
• Buffer between application and TCP is empty

packet smaller than MSS
ALP
ALP


large fraction of small packets
Idle time gt RTT
Time
MSS packet
22
23
Distinguishing BTPs from ALPsIsolate Merge
algorithm

• 2. phase Merge
• Why?
• After Isolate, BTPs may be separated by very
  short ALPs
• Analyze impact of the application
• How much ALPs decrease overall throughput?
• How?
• Merge subsequent transfer periods separated by
  ALP to create a new BTP
• Mergers controlled with
• drop parameter
• Iterate until all possible
• mergers are performed

23
24
More about Application and TCP interactions

• See
• M. Siekkinen, G. Urvoy-Keller, E. W. Biersack On
  the Interaction Between Internet Applications and
  TCP. ITC 2007.

24
25
BTP Analysis

• Compute limitation scores for each BTP
• 4 quantitative scores
• ?0,1
• We use retransmission rates, inter-arrival time
  patterns, path capacity, RTT etc.
• Perform classification of BTPs into limitation
  causes
• Map (combination of) limitation scores into a
  cause
• Threshold-based scheme

25
26
Classification scheme
Dispersion score

• 4 thresholds need to be calibrated

Retransmission score
Receiver window limitation score
b-score
26
27
Classification calibrating the thresholds

• Difficult task Diversity vs. Control
• Reference data needs to be representative
  diverse enough
• No simulations
• Need to control experiments in some way to get
  what we want
• Reference data with partially controlled
  experiments
• Try to generate transfers limited by certain
  cause
• FTP downloads from Fedora Core mirror sites
• 232 sites covering all continents
• Artificial bottleneck links with rshaper
• network limitation
• Nistnet to add delay
• receiver limitation (Wr/RTT lt bw)
• Control the number of simultaneous downloads
• unshared vs. shared bottleneck

Australia
Japan
Internet
Rshaper Nistnet
Eurecom
USA
Finland
27
28
Classification calibrating the thresholdsexample
set th1 here
bottleneck set at 1 Mbit/s, 1 download at a time
28
29
More details about BTP analysis

• Have a look at
• M. Siekkinen, G. Urvoy-Keller, E. W. Biersack A
  Root Cause Analysis Toolkit for TCP. To appear in
  Computer Networks, 2008

29
30
Root Cause Analysis of TCP Throughput

• Introduction and Motivation
• Root cause analysis techniques
• Taxonomy of TCP rate limitation causes
• Our approach to infer limitation causes
• Case study on Performance Analysis of ADSL
  Clients
• Conclusions

30
31
Motivation

• Stress test for our techniques
• Do we learn useful things?
• Knowing throughput limitations (performance) is
  useful
• ISPs want satisfied clients
• Need to know whats going on before things can be
  improved
• Applied root cause analysis toolkit on customer
  traffic of France Telecoms ADSL access network

31
32
Measurement Setup
Internet
access network
collect network

• Two pcap probes here

• 24 hours of traffic on March 10, 2006
• 290 GB of TCP traffic
• 64 downstream, 36 upstream
• Observed packets from 3000 clients, analyze only
  1335
• Excluded clients did not generate enough traffic
  for RCA

32
33
Warming up

• Connections
• Size distribution highly skewed
• Use only 1 of them for RCA
• Represent gt 85 of all traffic
• Clients
• Heavy-hitters 15 of clients generate 85-90 of
  traffic (up down)
• Low access link utilization
• Why?

33
34
Results of Limitation Analysis

• Main observation
• Application limits performance of over 80 of
  clients
• Whats going on?

34
35
Application analysisApplication limited traffic
other
eDonkey

• Quite stable and symmetric volumes
• Over 80 of all traffic
• eDonkey and other dominate

P2P
35
36
Application analysisSaturated access link

• No recognized P2P
• Asymmetric port 80/8080 downstream
• Real Web traffic?

36
37
Connecting the evidence

• Most clients performance limited by applications
• Very low link utilizations for application
  limited traffic
• Most of application limited traffic seems to be
  P2P
• Peers often have asymmetric uplink and downlink
  capacities
• P2P applications/users enforce upload rate limits
• ? Most clients download performance seems
  to suffer from P2P clients drastically limiting
  their upload rates

uploading clients
Internet
downloading client
Low utilization
Low capacityrate limiter
37
38
Concluding the case study

• Client size distribution skewed
• Heavy hitters dominate
• Majority of clients mostly throughput limited by
  applications
• Due to
• P2P clients throttle upload rate (Too much?)
• Asymmetric link capacities
• Consequences
• Low utilization of the core access network
• Client would benefit little from subscription
  upgrade
• See also
• M. Siekkinen, D. Collange, G. Urvoy-Keller, E.W.
  Biersack Performance Limitations of ADSL Users
  A Case Study. PAM 2007

38
39
Conclusions for Part 1

• We can infer root causes for TCP throughput using
• bidirectional packet traces at
• single measurement point located anywhere on the
  TCP/IP path.
• Useful for
• Performance evaluation of applications
• Evaluation of network utilization
• Identification of TCP configuration problems
• For future
• Wireless traffic
• On-line analysis
• Analysis of user behavior

39
40
Monitoring as First Class Citizen in an Autonomic
Network Architecture

• Joint work with
• Vera Goebel, Thomas Plagemann, Karl-Andre Skevik
• University of Oslo
• Martin May, Theus Hossmann, Ariane Keller
• ETH Zurich
• Guy Leduc, Bamba Gueye
• University of Liége
• Ranganai Chaparadza, Lorenzo Peluso, Rudolf Roth
• Fraunhofer FOKUS Institute

41
Outline

• Overview of the ANA Project
• Monitoring in ANA
• Approach, requirements, goals
• Monitoring architecture
• Information sharing
• Conclusions

41
42
www.ana-project.org

• ANA facts
• 4 years January 2006 to December 2009
• 10 European partners, 1 Canadian partner
• Roughly 30-40 researchers involved
• A Future and Emerging Technologies (FET) project
• Forward looking and "risky" research
• Proactive initiative on Situated and Autonomic
  Communications (SAC)
• New paradigms for communication/networking
  systems
• 4 projects ANA, BIONETS, Haggle, Cascadas

42
43
ANA Project Partners

• ETH Zurich
• University of Basel
• NEC
• Lancaster University
• Fokus
• University of Liege
• University Pierre et Marie Curie
• NKUA
• University of Oslo
• Telekom Austria
• University of Waterloo

43
44
Motivation

• The Internet suffers from architectural stress
• not ready to integrate and manage the envisaged
  huge numbers of dynamically attached devices
  (wireless revolution, mobility, personal area
  networks, etc)
• Lacks integrated monitoring and security
  mechanisms

Consensus in the research community that a next
step beyond the Internet is needed.
as seen by the number of recent related
projects and initiatives (FIRE, GENI, FIND)
44
45
The Internet Hourglass
Voice, Video, P2P, Email, youtube, . Protocols
TCP, UDP, SCTP, ICMP,
Changing/updating the Internet core is difficult
or impossible ! (e.g. IPv6, Multicast, Mobile IP,
QoS, )
Homogeneous networking abstraction
Disruptive approaches need a disruptive architect
ure
Ethernet, WIFI (802.11), ATM, SONET/SDH,
FrameRelay, modem, ADSL, Cable, Bluetooth
45
46
Objectives

• Goal To demonstrate the feasibility of autonomic
  networking.
• Identify fundamental autonomic networking
  principles.
• Design and build an autonomic network
  architecture.
• ANA in a blink
• Network must scale in size and in functionality.
• Evolving network variability at all levels of
  the architecture.
• ANA framework for function (re-)composition.
• Dynamic adaptation and re-organization of
  network.
• Networks have to work? do research through
  prototypes
• Build an experimental network architecture early
  on
• Prototype used as feedback to refine
  architectural models.

Architectures are not built, they grow!
46
47
Scenario today

• all device have to know IP
• IP address configuration through DHCP, zeroconf,
  ad hoc mode
• routing protocol has to be agreed on
• ? Always require manual configuration

47
48
Scenario with ANA
New ANA Compartment

• Self-organization
• determine comm. Protocol (non-IP)
• form compartment
• intra-compartment routing
• service discovery

• Self-association
• Node bootstrapping
• neighborhood discovery
• address configuration
• functional composition (suitable network stack)
• Beyond IP!!!

• Self-optimization
• enhanced integrated monitoring
• functional re-composition
• resilience

48
49
The ANA Project

• To enable this vision we need
• The ANA core
• Highly configurable network stack
• Self-association
• Service discovery
• Self-organization
• Functional composition
• Self-optimization

49
50
ANA ? "one-size-fits-all"

• ANA does not propose another "one-size-fits-all
  network waist".
• ANA is a framework to host, interconnect, and
  federate multiple heterogeneous networks.
• ANA introduces the core concept of "network
  compartments."

Application layer
Multiple "network compartments" can co-exist

ANA framework
.
IP
.
.
Link layer
50
51
ANA a meta-architecture

• ANA does not impose how network compartments
  should work internally
• ?the ANA framework specifies how networks
  interact.

ANA specifies interfaces and interactions
with network compartment
Internal operation is not imposed
leading to multiple and heterogeneous
compartments but generic interaction
ANA framework
51
52
From Layers to Functional Composition

• Per application port
• UDP/TCP handling
• IP does defragmentation, checksum,
• All packets from Ethernet with 0x0800 ?
  IP0x86DD ? IPv6

App Layer
Trans Layer
Net Layer
MAC Layer
Phy Layer
52
53
From Layers to Functional Composition

• At least same functionality as before, but
  decomposed
• Allows for composition of functionality /
  services
• Also
• New functionality integrated in protocol stack
• Not so novel, but we add
• Dynamic re-configuration
• Autonomic properties

Applications
Reliable Transport
Checksum
Routing
Mobility Prediction
Functional Compartment
Monitoring
Fragmentation
Phy/MAC Layer
53
54
ANA Blueprint

• ANA Blueprint offers a flexible and evolvable
  framework.
• Allows variability at all levels of the
  architecture multiple
• functionalities,
• variants to perform a given task,
• and compartments
• co-exist and (can) compete, open for extensions
  (evolution).
• Where does autonomic fit into the Blueprint?
• Blueprint provides a well-defined structure on
  which to operate in an autonomic way
• Easy to test/replace/upgrade parts of the system
  (except for minimal core)
• Generic set of abstractions provides "common
  language" for algorithms and protocols

54
55
ANA abstractions

• Compartment
• Information Channel (IC)
• Information Dispatch Point (IDP)
• Functional Block (FB)

55
56
The Compartment

• Compartment wrapper for networks
• Implements operational rules and administrative
  policies for a given communication context
• Defines
• How to join and leave a compartment member
  registration, trust model, authentication, etc.
• How to reach (communicate with) another member
  peer resolution, addressing, routing, etc.
• The compartment-wide policies interaction rules
  with "external world", the compartment boundaries
  (administrative or technical), peerings with
  other compartments, etc.

56
57
What about addresses and names?

• Addressing and naming are left to compartments.
• Each compartment is free to use any addressing
  and naming schemes
• Can choose not to use addresses (e.g. in sensor
  networks)
• Main advantages
• No need to manage a unique global addressing
  scheme
• No need to impose a unique way to resolve names
• ANA is open to future addressing and naming
  schemes
• Main drawback
• Global routing becomes something similar to
  searching
• (if communicating parties are not all members
  of a given compartment)

57
58
Information dispatch point (IDP) and Information
channel (IC)

• Startpoints instead of endpoints
• In ANA communication is always towards a
  startpoint, or information dispatch point (IDP)
• Bind to destinations in an address agnostic way
• Support many flavors of compartments that can use
  different types of addresses and names
• Useful decoupling between identifiers and means
  to address them

IC
A
data is sent to IDP which has state to reach
destination
58
59
Functional blocks (FBs)

• Code and state that can process data packets
• Protocols and algorithms are represented as FBs
• Access to FBs is also via information dispatch
  points (IDPs)
• FBs can have multiple input and output IDPs
• FB internally selects output IDP(s) to which data
  is sent

FB
FB
data is sent to IDP which has state to call
correct function inside FB
59
60
How ICs, FBs, and IDPs fit together
Node compartment
Node compartment
FB1
FB2
IC
c
b
a
60
61
Node is also a compartment

• Organize a node's functionalities as
  (compartment) members
• Member database catalog of available functions
• Resolution step to access a given function
• Also implements access control
• Resolution instantiates functional blocks (FBs)
• The node compartment hosts/executes FBs and IDPs
• The node compartment is the "startpoint" of any
  communication

61
62
The ANA communications API

• Network compartments are free to internally run
  whatever addressing/naming schemes, routing
  protocols, etc.
• The "glue" for all interactions in ANA is the
  compartment API.
• All network compartments must support the API in
  order to allow all possible interactions between
  compartments.

63
API primitives

• The API offers 5 fundamental primitives
• IDPp publish(IDPc, CONTEXT, SERVICE)
• int unpublish(IDPc, IDPp, SERVICE)
• IDPr resolve(IDPc, CONTEXT, SERVICE)
• void lookup(IDPc, CONTEXT, SERVICE)
• int send(IDPr, DATA)
• SERVICE what is published or looked up
• e.g., an address, a name, a file, a printing
  service, etc.
• The CONTEXT defines some scope inside a
  compartment.
• e.g. global scope , node local scope .

64
Using the API some examples

• Publishing an IPv4 address in the Ethernet
  compartment.

z lt-- publish(y, , 10.1.2.3)
65
Outline

• Overview of the ANA Project
• Monitoring in ANA
• Approach, requirements, goals
• Monitoring architecture
• Information sharing
• Conclusions

65
66
Role of monitoring

• Monitoring is essential for autonomic behaviour
• Need to know system state at all times
• Adapt to the environment automatically
• Monitoring gives awareness and therefore enables
  autonomic features, such as
• Functional composition
• Service placement and selection
• Advanced routing
• Topology optimization
• BUT the monitoring framework must exhibit some
  level of autonomy as well!

67
Monitoring Classic vs. ANA
Classic approach
Monitoring
Managed Element

• Examples of decisions
• Compose functional blocks differently
• Move service or data elsewhere
• Change routing

67
68
Goals

• Monitoring framework provides service to all ANA
  functional blocks that need some network state
  awareness
• Goals
• Efficiency and accuracy
• Avoid duplication of monitoring tasks at many
  levels of the architecture (typically in many
  overlays)
• Provide resilient and flexible means to store and
  give access to monitored data
• Enable distributed monitoring
• Self-adaptation
• To environment, system resources, and usage
  (non-functional requirements)
• Individual components as well as the whole
  framework
• Extensibility and modularity
• Framework allows cooperation among tools
• New tools can be added

69
Outline

• Overview of the ANA Project
• Monitoring in ANA
• Approach, requirements, goals
• Monitoring architecture
• Information sharing
• Conclusions

69
70
Node architecture for monitoring Conceptual view
71
Node architecture for monitoring Implementation
view
72
Example Monitoring latency

• Latency brick adapts to environment and
  qualitative parameters

72
73
System Monitoring
Measurement Plugins

• Measures critical system parameters
• Manages interactions between consumer bricks and
  measurements bricks (plug-ins)
• Measurement brick subscribes (1) and gives IDP to
  receive requests
• Provides a multi-mode interface
• On-request
• On-timer
• On-condition

System Monitoring
1 Subcription
SYSTEM MONITORING BRICK
Measurement Brick
IDPc
2 Measurement Requests
74
Multi-mode interface
On Request

• On Request
• Standard request/response approach
• Consumer specifies which parameter to measure
• On Timer
• Consumer specifies timer value
• Will receive periodic measures
• On Condition
• Consumer specifies a condition (e.g. cpu_load gt
  v)
• Will receive a notification when condition gets
  true

On TimerOn Condition
75
Outline

• Overview of the ANA Project
• Monitoring in ANA
• Approach, requirements, goals
• Monitoring architecture
• Information sharing
• Conclusions

75
76
Information sharing in monitoring

• Efficient, robust access to data
• Mechanisms for publishing and querying/finding
  data
• Multi-attribute range queries
• E.g. SELECT srcip from flow_records WHERE
  bytesgt108 AND
• One-time queries and subscriptions
• Information sharing functional block
• Based on Mercury
• What is Mercury?
• A. Bharambe, M. Agrawal and S. Seshan. Mercury
  Supporting Scalable Multi-Attribute Range Queries
  (SIGCOMM 2004)

77
Multi-attribute range queries à la Mercury

• One ring per attribute
• Each ring behaves like DHT without hashing, i.e.
  contiguous value ranges
• Explicit load balancing scheme to cope with
  popular value ranges

• Send data to all rings

• Send query to only one ring

Rx
Ry
From Mercury Scalable Routing for Range
Queriesby Ashwin R. Bharambe, SIGCOMM 2004
78
Data compartments

• Metadata compartment enables discovery of data
  compartments
• Kind of catalog of data stored in the whole
  system
• One data compartment per data type
• E.g. Cisco Netflow records

• Each data compartment represents a single Mercury
  system
• Is distributed over several ANA nodes
• Has an attribute hub per attribute of this data
  type
• Organizes data independently from other data
  compartments

79
How does the IS system fit into ANA architecture?

• A data compartment is a usual ANA compartment
• Uses the proposed primitives of ANA compartment
  API
• Each node has an MCIS functional block
• MCIS Multi-compartment Information Sharing
• Gives access to all data compartments (including
  meta-data compartment)
• Entry point for accessing data and storing data

80
Using the MCIS

• Metadata compartment
• resolve() get IDP to a data compartment
• lookup() get datatype tuples matching the query
• publish() store a new data type, i.e.
  establish a new data cmpt, get IDP to that cmpt
• Data compartment
• resolve() not currently supported
• lookup() get data records of the data cmpt
  matching the query
• publish() store a new data record into that data
  cmpt
• Two exercises
• Querying the IS system
• Storing data into the IS

81
Querying MCIS

• Search for MCIS service
• resolve(n,.,MCIS,e) returns IDP i to the
  metadata cmpt

• Search for data type
• lookup(i,,querystring,e) returns matching
  data types stored currently in the system
• Query string example (MIB style) X.Y. returns
  data1

• Resolve the data1 compartment
• resolve(i,,X.Y.data1,e) returns IDP j

• Make the query
• lookup(j,,altxbgty,e) returns matching data
  records

MCIS
82
Storing data into MCIS

• Search for MCIS service
• resolve(n, ., MCIS, e) returns IDP i to the
  metadata cmpt

• Resolve the X.Y.data2 compartment
• resolve(i, , X.Y.data2, e) returns IDP r

• Store data item
• publish(r, dataitem, NULL)

MCIS
83
Importing Mercury software to ANA

• 80 000 lines of C code
• No documentation ?
• One major source of headache
• Identifiers in Mercury are IP address TCP/UDP
  port number
• Needed to introduce generic identifiers

• Original code quite modular

apps

• bricks
• MCIS

tools
mercury
util

• We programmed
• MCIS brick code
• ANA nw layer

sim-env
ana-env
wan-env
84
Next steps wrt. MCIS

• Self-adaptation features
• Adaptive index structures
• Adapt to environment (e.g. nb of nodes,
  resources) and usage (e.g. query and data rates
  and patterns)
• E.g, shut down unused attribute hubs and use DHT
  for attributes that dont require range queries
• Multi-compartment load balancing
• Now only within a single compartment
• Other features
• Multi-attribute indexes
• Joins
• Security

85
Outline

• Overview of the ANA Project
• Monitoring in ANA
• Approach, requirements, goals
• Monitoring architecture
• Information sharing
• Conclusions

85
86
Conclusions

• Monitoring as an integral part of the
  architecture
• To enable autonomic behavior
• Goals of monitoring framework
• Efficiency and accuracy
• Adaptability
• Extensibility and modularity
• Current status
• Still immature
• Some FBs are already there, some under
  development, some in design phase
• Implementation and evaluation
• Through use case scenarios
• E.g. P2P VoD streaming (Advanced peer selection)
• Some of the future research topics
• self-adaptive MCIS
• self-organized coordinate system (University of
  Liege)
• mobility monitoring and link quality prediction
  (ETHZ)

86
87
Thank you!
Questions?