Download The ANA Project Autonomic Network Architectures

My Research in Network Monitoring and
Measurements
Matti Siekkinen
University of Oslo
TKK / HIIT
April 9./10., 2008
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
25 May 2017
Root Cause Analysis of TCP Throughput
Joint work with:
Guillaume Urvoy-Keller, Ernst W. Biersack
Institut Eurecom, France
Denis Collange
France Télécom R&D, France
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
25 May 2017
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

5
Need techniques for traffic measurement and analysis
25 May 2017
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
25 May 2017
Background
 TCP Rate Analysis Tool (T-RAT) by Zhang et al.
(sigcomm 2002)
 Pioneering research work
o
o
o
Ground breaking insights
It is not all congestion!
Opened up many questions
 We implemented and tested it
o
o
Results are way off too often
Fundamental assumptions do not hold
 T-RAT analyzes unidirectional traffic
o
o
o
7
Passively collected measurements
Usable in more cases (asymmetric paths)
The source of the problems
25 May 2017
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 ISP’s network
o
Know all about clients’ downloads and uploads
 Bidirectional packet traces
 Connection level analysis
8
25 May 2017
Challenges (1/3)
 Single measurement point anywhere along the path
 Cannot/don’t want to control it
 Complicates estimation of parameters (RTT and cwnd)
A: RTT ~ d1
 piece of cake…
B: RTT ~ d3+d4
 How to get d4?
 (Did ack2 trigger
 data2?)
ack2
A
9
B
25 May 2017
Challenges (2/3)
 A lot of data to analyze
 Potentially millions of connections per trace
 Deep analysis
 For each connection of each trace
o
o
Compute a lot of metrics
Divide connections into pieces
• Analyse separately and compute more metrics
o
10
Need to keep track of everything
25 May 2017
Need solutions for
data management
InTraBase
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
o
o
o
Choose the “best” for the situation
Try to maximize correctness of results
E.g. 5 ways to estimate RTTs
 Careful validations
o
o
11
Benchmark with a lot of reference traces
Cross validate metrics
25 May 2017
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
25 May 2017
Scope
 Study long lived TCP connections
 Short connections are another topic
o
Dominated by slow start?
 Assume FIFO scheduling
 Necessary for link capacity estimations with packet dispersion
techniques
 Does not hold for all networks
o
13
E.g. cable modem and 802.11 access networks
25 May 2017
Limitation Causes for TCP Throughput
 Application
 Transport layer
 TCP receiver
o
Receiver window limitation
 TCP protocol
o
Congestion avoidance mechanism…
 Network layer
 Bottleneck link
14
25 May 2017
Application that sends small amounts of data at constant rate
40 bytes “pushed”
15
25 May 2017
Application that sends larger bursts separated by idle periods

BitTorrent, HTTP/1.1 (persistent)
transfer periods
only keep-alive messages
16
25 May 2017
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
o
Never run out of data in buffer B1
 Application Limited Period (ALP): opposite of BTP
o
TCP has to wait for data because B1 is empty
Sender
Application
buffers
Application
TCP
Network
TCP
B1
17
Receiver
25 May 2017
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
Sender
Application
Receiver
buffers
B2
TCP
Network
 Configuration problem (unintentional)
 default receiver advertized window is set too low
 window scaling is not enabled
18
Application
25 May 2017
TCP
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
25 May 2017
Our Approach to Root Cause Analysis
 Divide & Conquer
1. Partition connections into BTPs and ALPs
o
Filter out application impact
2. Analyze the bulk transfer periods for limitation by
o
o
o
TCP receiver
TCP protocol
Network
 Methods are based on metrics computed from packet
headers
20
25 May 2017
Why filter out application effect?
 We try to study TCP/IP path properties but end up
measuring application effect instead!
21
25 May 2017
Distinguishing BTPs from ALPs:
Isolate & Merge algorithm
 1. phase: Isolate


packet smaller
than MSS
Fact: TCP always tries to send MSS size packets
Consequence: small packets (size < MSS) and idle time
indicate application limitation
o
Buffer between application and TCP is empty
ALP
ALP
…
…
large fraction of
small packets
Idle time > RTT
MSS packet
22
25 May 2017
Time
Distinguishing BTPs from ALPs:
Isolate & Merge algorithm
 2. phase: Merge
 Why?
o
o
After Isolate, BTPs may be separated by very short ALPs
Analyze impact of the application
• How much ALPs decrease overall throughput?
 How?
o
o
o
23
Merge subsequent transfer periods separated by ALP to create a new BTP
Mergers controlled with
drop parameter
Iterate until all possible
mergers are performed
25 May 2017
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 May 2017
BTP Analysis
1. Compute limitation scores for each BTP

4 quantitative scores
o
o
[0,1]
We use retransmission rates, inter-arrival time patterns, path
capacity, RTT etc.
2. Perform classification of BTPs into limitation causes


25
Map (combination of) limitation scores into a cause
Threshold-based scheme
25 May 2017
Classification scheme
Dispersion score
4 thresholds need to be
calibrated
Retransmission
score
Receiver window
limitation score
b-score
26
25 May 2017
Classification: calibrating the thresholds
 Difficult task: Diversity vs. Control
 Reference data needs to be representative & diverse enough
o
No simulations
 Need to control experiments in some way to get what we want
Australia
 Reference data with partially controlled experiments
 Try to generate transfers limited by certain cause
 FTP downloads from Fedora Core mirror sites
o
232 sites covering all continents
 Artificial bottleneck links with rshaper
o
network limitation
Japan
Interne
t
 Nistnet to add delay
Eurecom Rshaper
 Control the number of simultaneous downloads Nistnet
o unshared vs. shared bottleneck
o
27
receiver limitation (Wr/RTT < bw)
25 May 2017
Finland
USA
Classification: calibrating the thresholds
example
set th1 here
bottleneck set at 1 Mbit/s, 1 download at a time
28
25 May 2017
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
25 May 2017
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
25 May 2017
Motivation
 Stress test for our techniques
 Do we learn useful things?
 Knowing throughput limitations (=performance) is useful
 ISPs want satisfied clients
 Need to know what’s going on before things can be improved
 Applied root cause analysis toolkit on customer traffic of France
Telecom’s ADSL access network
31
25 May 2017
Measurement Setup
access
network
collect
network
Internet
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
25 May 2017
Warming up…
 Connections
 Size distribution highly skewed
 Use only 1% of them for RCA
o
Represent > 85% of all traffic
 Clients
 Heavy-hitters: 15% of clients generate 85-90% of traffic (up & down)
 Low access link utilization
o
33
Why?
25 May 2017
Results of Limitation Analysis
 Main observation


34
Application limits performance of over 80% of clients
What’s going on?
25 May 2017
Application analysis:
Application limited traffic
other
eDonkey
 Quite stable and symmetric volumes
 Over 80% of all traffic
 eDonkey and “other” dominate
35
25 May 2017
P2P
Application analysis:
Saturated access link
 No recognized P2P
 Asymmetric port 80/8080 downstream
 Real Web traffic?
36
25 May 2017
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
Interne
t
downloading
client
Low utilization
37
Low capacity+rate limiter
25 May 2017
uploading
clients
Concluding the case study
 “Client size” distribution skewed
 Heavy hitters dominate
 Majority of clients mostly throughput limited by applications
 Due to:
o
o

P2P clients throttle upload rate (Too much?)
Asymmetric link capacities
Consequences:
o
o
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
25 May 2017
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
25 May 2017
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
Outline
 Overview of the ANA Project
 Monitoring in ANA
 Approach, requirements, goals
 Monitoring architecture
 Information sharing
 Conclusions
41
25 May 2017
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
25 May 2017
ANA Project Partners











43
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
25 May 2017
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
25 May 2017
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, …)
Everything
on IP
Application
layer
IP
Link
layer
IP
on
Everything
Ethernet, WIFI (802.11), ATM, SONET/SDH,
FrameRelay, modem, ADSL, Cable, Bluetooth…
45
25 May 2017
Homogeneous
networking
abstraction
Disruptive
approaches need
a disruptive
architecture
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
25 May 2017
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
25 May 2017
Scenario – with ANA
New ANA Compartment
ANA core
ANA core
ANA core
ANA core
48
• Self-organization
• Self-association
•• Self-optimization
determine comm. Protocol
• Node
bootstrapping
• enhanced
& integrated
(non-IP)
• neighborhood
discovery
monitoring
• form
compartment
• address
configuration
• functional
re-composition
• intra-compartment
routing
• functional
composition
• resilience
• service
discovery
(suitable network stack)
• Beyond IP!!!
25 May 2017
ANA core
ANA core
ANA core
The ANA Project
 To enable this vision we need:
 The ANA core
o





49
Highly configurable network stack
Self-association
Service discovery
Self-organization
Functional composition
Self-optimization
25 May 2017
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
..
.
IP
…
ANA framework
Link
layer
50
25 May 2017
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
25 May 2017
From Layers to Functional Composition
App Layer
Trans Layer
Net Layer
MAC Layer
Phy Layer
52
 Per application port
 UDP/TCP handling
 IP does defragmentation,
checksum,…
 All packets from Ethernet
with:
0x0800  IP
0x86DD  IPv6
25 May 2017
From Layers to Functional Composition
 At least same functionality as
Applications
before, but decomposed
 Allows for composition of
Checksum
Reliable
Transport
functionality / services
Routing
Also:
Mobility
Functional
Prediction
Compartment
 New functionality integrated in
Monitoring
protocol stack
Fragmentation
Not so novel, but we add
 Dynamic re-configuration
 Autonomic properties
53
Phy/MAC Layer
25 May 2017
ANA Blueprint
 ANA Blueprint offers a flexible and evolvable framework.
 Allows variability at all levels of the architecture: multiple
functionalities,
o variants to perform a given task,
o and compartments
o
 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
25 May 2017
ANA abstractions
 Compartment
 Information Channel (IC)
 Information Dispatch Point (IDP)
 Functional Block (FB)
55
25 May 2017
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.
Compartments decompose communication systems and
networks into smaller and easier manageable units.
56
25 May 2017
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
25 May 2017
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
25 May 2017
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
25 May 2017
How ICs, FBs, and IDPs fit together
Node compartment
FB1
a
Node compartment
FB2
IC
c
b
25 May 2017
60
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
o
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
Node Compartment
p
e
client
f
61
a
25 May 2017
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.
62
25 May 2017
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 = “.”
63
25 May 2017
Using the API: some examples
Publishing an IPv4 address in the Ethernet compartment.
IP-FB
y
ETH-FB
Ethernet
Compartment
z
publish
"10.1.2.3"  z
node M
z <-- publish(y, “*”, “10.1.2.3”)
64
25 May 2017
Outline
 Overview of the ANA Project
 Monitoring in ANA
 Approach, requirements, goals
 Monitoring architecture
 Information sharing
 Conclusions
65
25 May 2017
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!
66
25 May 2017
Monitoring: Classic vs. ANA
Classic approach
Autonomic approach
Monitoring
Managed Element
Examples of decisions:
- Compose functional blocks differently
- Move service or data elsewhere
- Change routing
67
25 May 2017
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)
o Provide resilient and flexible means to store and give access to monitored data
o Enable distributed monitoring
o
 Self-adaptation
o
o
To environment, system resources, and usage (non-functional requirements)
Individual components as well as the whole framework
 Extensibility and modularity
o
o
68
Framework allows cooperation among tools
New tools can be added
25 May 2017
Outline
 Overview of the ANA Project
 Monitoring in ANA
 Approach, requirements, goals
 Monitoring architecture
 Information sharing
 Conclusions
69
25 May 2017
Node architecture for monitoring:
Conceptual view
Anomaly
detection
Topology
prediction
Vivaldi
Adaptive
routing
Peer
selection
…
Figure out how to
fulfill requests, i.e.
how and what to
measure.
Context
data mgmt
Context
mapping
Orchestration
– Handle requests
– Manage measuring bricks
– Optimization
Adaptive
sampling
Aggregation
ping
System
monitoring
MCIS
Avail. bw
meas.
Packet
capturing
Link quality
prediction …
Monitoring
data storage
(RAM, DB, …)
Node architecture for monitoring:
Implementation view
Peer
selection
Orchestration
Dispatcher
Latency
Connectivity
Link
quality
Vivaldi
ping
Link quality
prediction
Knows the network
related metrics it
needs (e.g. latency)
• Discovers ”metric” bricks
• Decomposes & forwards
requests
Achievable
tput
Avail. bw
Passive av
bw meas.
Packet
capturing
Metric bricks
Metric bricks decide
how to measure the
metrics, i.e. which other
metric bricks or
measuring bricks to use
depending on:
• context (e.g. wireless
or wired nw)
• non-functional
requirements (e.g. max
tolerated error)
MCIS
Monitoring
data storage
(RAM, DB, …)
System
monitoring
Example: Monitoring latency
 Latency brick adapts to environment and qualitative parameters
context
wireless,
mobile
Ping
wired,
static
Use Vivaldi with error prediction
Ping
high error
low error
tolerance
tolerance
non-functional requirements
72
25 May 2017
Outline
 Overview of the ANA Project
 Monitoring in ANA
 Approach, requirements, goals
 Monitoring architecture
 Information sharing
 Conclusions
75
25 May 2017
Information sharing in monitoring
 Efficient, robust access to data
 Mechanisms for publishing and querying/finding data
 Multi-attribute range queries
o
E.g. SELECT srcip from flow_records WHERE bytes>108 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)
76
25 May 2017
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
Query
[240, 320)
[160, 240)
Rx
50 ≤ x ≤ 100
150 ≤ y ≤ 250
[0, 105)
[0, 80)
Ry
Data item
x = 100
y = 200
[80, 160)
[210, 320)
[105, 210)
From ”Mercury: Scalable Routing for Range Queries”by Ashwin R. Bharambe, SIGCOMM 2004
77
25 May 2017
Data compartments
Metadata cmpt
data3 cmpt
data1 cmpt
 Metadata compartment enables
discovery of data compartments
 Kind of catalog of data stored in the
whole system
 One data compartment per data type
data2 cmpt
 E.g. Cisco Netflow records
data4 cmpt
 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
78
25 May 2017
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
79
25 May 2017
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
80
25 May 2017
Querying MCIS
1.
Search for MCIS service

2.
Search for data type


3.
lookup(i,”*”,”querystring”,e): returns matching data types
stored currently in the system
Query string example (MIB style) X.Y.* returns data1
MCIS
Resolve the data1 compartment

4.
resolve(n,”.”,”MCIS”,e): returns IDP i to the metadata cmpt
MCIS
resolve(i,”*”,”X.Y.data1”,e): returns IDP j
MCIS
Make the query

lookup(j,”*”,”a<x&b>y”,e): returns matching
data records
Client
e
k l
i
j
n
81
25 May 2017
m
MCIS
MCIS
Storing data into MCIS
1.
Search for MCIS service

2.
Resolve the X.Y.data2 compartment

3.
resolve(n, ”.”, ”MCIS”, e): returns IDP i to the metadata cmpt
resolve(i, ”*”, ”X.Y.data2”, e): returns IDP r
Store data item

MCIS
publish(r, dataitem, NULL)
MCIS
MCIS
Client
e
i
r
n
82
25 May 2017
MCIS
MCIS
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
 We programmed
 MCIS brick code
 ANA nw “layer”
83
bricks
•MCIS
apps
tools
mercury
wan-env
sim-env
25 May 2017
util
ana-env
Next steps wrt. MCIS
 Self-adaptation features
 Adaptive index structures
o
o
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 don’t
require range queries
 Multi-compartment load balancing
o
Now only within a single compartment
 Other features
 Multi-attribute indexes
 Joins
 Security…
84
25 May 2017
Outline
 Overview of the ANA Project
 Monitoring in ANA
 Approach, requirements, goals
 Monitoring architecture
 Information sharing
 Conclusions
85
25 May 2017
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
25 May 2017
Thank you!
Questions?