SONATE Euro-NF PhD Course
description
Transcript of SONATE Euro-NF PhD Course
University of Kaiserslautern, GermanyDepartment of Computer ScienceIntegrated Communication Systems ICSYhttp://www.icsy.de
SONATEEuro-NF PhD Course
University of Kaiserslautern06 March 2012
Dr. Bernd Reuther
2Bernd Reuther, University of Kaiserslautern
Outline
Project Beyond-IP 1997-1999 Project DANCE 2001-2003
- Motivation- Terminology: Service, …- Abstraction of communication protocols
SONATE- Problem statement and goals- Overview of Basic Concepts- Building Block Interface- Service Selection- Service Composition
Considered Problem Approach Conclusion
Project Beyond-IP 1997-1999
4Bernd Reuther, University of Kaiserslautern
Considered Problem
ATM (Asynchronous Transfer Mode) a “new” technology with many new properties- Several service classes (CBR,VBR,UBR,ABR)- Bandwidth reservation- Virtual Channels in Virtual Paths on top of physical infrastructure- Connection oriented- New address types for hosts and services
Applications were design for TCP/IP- ATM was used as “just another Layer-2 technology”→ Nearly no application was able to utilize ATM features
5Bernd Reuther, University of Kaiserslautern
Approach
A common interface for accessing TCP/IP as well as ATM networks- Superset of the BSD socket API
A layer on top of ATM emulating TCP/IP behavior- A protocol for reliable transfer like TCP- Emulating TCP and UDP behavior
• Transparent connection establishment for UDP behavior• A Protocol for emulating TCP Halfclose• Rebuild Nagles Algorithm for TCP behavior• Interception of socket options and manage parameters
An extension of the socket API for QoS request- Use if ATM is available- Ignore if IP is used
Mapping of addresses using DNS, and a proprietary approach for port-numbers
Protocol selection: use ATM if available locally and the remote site has registered an ATM-Address with DNS
6Bernd Reuther, University of Kaiserslautern
Conclusion
Achievement:- Running native TCP/IP application on top of ATM possible
But:- Several proprietary protocols required- Still not all ATM features supported- No motivation to create native ATM applications
Imitate functionality of “standard” protocols is no appropriate evolution path- No incentive for application developers to support “new protocols”- Is costly because of emulating “all specific details” of old protocols
Motivation Terminology: Service, … Abstraction of communication protocols
Application of the SOA paradigm Service description Brokering and configuration of services
Project DANCE 2001-2003
8Bernd Reuther, University of Kaiserslautern
Project DANCE 2001-2003
Generalize Problem of Beyond-IP Project:- New (transport) protocols require adaption of applications
Without users (applications) there is no incentive for innovation!
9Bernd Reuther, University of Kaiserslautern
Innovation within Transport and Network Protocols
Innovation in the Internet- New Applications- New Network-Technologies
Few innovation within transportand network protocols- Extensions were possible only if they are transparent for users
and other systems- Alternatives are available
The problem is to implement new developments in practice and not the development itself!
Applications
Transport and NetworkProtocols
Network Technologies
Innovation is the implementation of new technical or organizational developments* (Schumpeter, 1934)* Original cite is German: Innovation ist die Durchsetzung einer technischen oder organisatorischen Neuerung.
10Bernd Reuther, University of Kaiserslautern
Considered Problem
Why is it so hard to implement new technical developments of transport and network protocols?
Precondition: Benefit of new development > effort of implementation
Problem: enormous effort is required- Tight coupling of applications and transport protocols- Limited availability of new protocols
11Bernd Reuther, University of Kaiserslautern
Reason 1: Tight Coupling
Today application are tightly coupled to protocols - Because of the BSD Socket Interface, e.g.:
• Specification of the protocol type• Address types are not transparent (e.g. port numbers)• Connection less and connection oriented behavior is not transparent• Protocol options (TCP_NODELAY, TCP Window Scaling)
- Because of application logic, e.g.:• When taking into account the Maxium Transfer Unit (MTU) for UDP/IP• When using TCP „halfclose“ for End-of-File signaling
Applications have to be adapted to new protocols!
Reality: few applications support “new protocols”
12Bernd Reuther, University of Kaiserslautern
Application design- Protocol independent BSD Socket API- Selection of protocols by applications- Protocol options (and thus optimization) not applicable
Middleware provides abstraction of communication protocols- Specialized for certain application classes, many MW exists- Technically usually part of applications
ApplicationApplication
Avoid tight coupling today?
Application
MiddlewareCommunication System
Middleware Middleware Middleware
13Bernd Reuther, University of Kaiserslautern
Reason 2: Limited Availability
Some functionalities are not available everywhere- Stepwise introduction of for example:
• IPv6• Explicit Congestion Notification (ECN)• SCTP, UDPLite, DCCP, ...
- Limitations exist even for established functionality• Blocking UDP or ports ≠ 80• NATs are blocking server
Applications must decide which (new) protocols may be used!Reality: use commonly available protocols, e.g. TCP Port 80 or HTTP
14Bernd Reuther, University of Kaiserslautern
Goal of DANCE
Applications should benefit of new technical developments in networks, without the need to adapt applications.
Steps: Achieve abstraction of protocols:
„Use communication services instead of protocols “ Autonomous selection and configuration of
Transport Service Provider (TSP) at runtime
Transport Service Provider (TSP) = protocol stack (OSI terminology)
Common terms: Service, Mechanisms, Techniques
“Our” terms: Service Elements Service Description Communication Services
Terminology
16Bernd Reuther, University of Kaiserslautern
Services, Mechanisms, Techniques
Service(the visible effects)
Mechanisms(algorithms / protocols)
Code(bits & bytes)
implement
implement
Example: reliable transferof a byte stream
Example: TCP
Example: Linux Kernel-Modulfor TCP
A „service“ denotes an abstraction level (like in the ISO/OSI model).
abst
ract
ion
17Bernd Reuther, University of Kaiserslautern
Service Roles
Ambiguous use of the term “service” in informatics
Service instance- Algorithms and resources
Service result- Immaterial benefit- Abstraction of Mechanisms
Interface- Defines communication
18Bernd Reuther, University of Kaiserslautern
Service Description
Mapping between Mechanism and Service
Approaches for descriptions- Mechanisms + Interface resulting in a
unique service
- Service + Interface may by implemented byseveral mechanisms→ need to select appropriate mechanisms Mechanisms
Services
1
n
19Bernd Reuther, University of Kaiserslautern
Communication service
The major benefit of a communication service is the transport of data.
Describe a communication service by:• Type of data to be transported• Endpoint entities involved• Properties of data exchange
Assume: There is one generic interface for all communication services
Key-functionality 1. Service description 2. Brokering and configuration of services 3. Interface
Project DANCE 2001-2003Abstraction of communication protocols
22Bernd Reuther, University of Kaiserslautern
b) Service brokering
3
SOA-Paradigm
Support of three key functionalities
ServiceUser
ServiceProvider
ServiceBroker
1
2
a) S
ervi
ce d
escr
iptio
n
4
5
c) Interface
23Bernd Reuther, University of Kaiserslautern
A service oriented Approach for Abstraction ofCommunication Protocols in the Internet
1. Description of offered services
2. Description of requested services
3. Broker result4. Configuration of
TSP5. Utilization
24Bernd Reuther, University of Kaiserslautern
Key-Functionality: Service description
ServiceUser
ServiceProvider
ServiceBroker
a) S
ervi
ce d
escr
iptio
n
25Bernd Reuther, University of Kaiserslautern
Steps of Service Brokering
Set of all appropriate
Service offerings
Ordered list of Service offerings
Mandatoryrequirements
Wantedrequirements
Set of all Service offerings
Set of all available Service offerings
Service usage
Preconditions+dynamic data
26Bernd Reuther, University of Kaiserslautern
Service Description
A communication service S is defined as a set of properties Ei :S = {E1 ,..., En }- Extendable- Types of properties (inherent and qualitative) support the service
brokering
Inherent properties (mandatory / guaranteed)- Determine appropriate services- Example: supported data or address types,
upper or lower bounds for MTU, costs or loss rate
Qualitative Properties (wanted / rating)- Determine ordering of service according to rating- Example: quality of cost level, quality of loss rate, efficiency
27Bernd Reuther, University of Kaiserslautern
Attributes of Inherent Properties
Unique identification of a property Ei using a URI- Bsp: http://www.icsy.de/xml/SOCS/IProp/tp/MTU
Optional: absolute boundaries- In requirements
• lbR lower boundary, ubR upper boundary
• Semantic with Ei valid for x
- In offerings
• lbO lower boundary, ubO upper boundary
• Semantic with Ei valid for x
An offering is appropriate if:
],[ RR ublbx
],[ OO ublbx
],[],[ OORR ublbublb
28Bernd Reuther, University of Kaiserslautern
Attributes of Qualitative Properties Unique identification of a property Ei using a URI
- Bsp: http://www.icsy.de/xml/SOCS/QProp/Loss
Relative rating- In requirements
• Weights of properties Ei
• Relative rating of properties
- In offerings
• Quality of a property Ei of a TSPk
• Relative rating of TSP regarding one specific property
Quality of an offering:
]1,0[iw
]1,0[,kiq
n
i kiiqw1 ,
→ wi determined by application developers
→ qi,k determined by …
29Bernd Reuther, University of Kaiserslautern
Determine the Quality of an Offering
Subjective method: qi,k „defined by experts“ Objective method based on benchmarks
- Benchmark Bi is neutral, delivers measurements• Used to compare TSP, no prediction
- Interpreting measurements by• Offerings must specify an interpretation f • Requirements may specify an alternative interpretation f´
)(, kiki TSPBQ
)( ,, kiki Qfq ]1,0[:)( xf
rating
Quality q
Spec
ific
mea
sure
30Bernd Reuther, University of Kaiserslautern
A service provider (TSP) may offer many services- Depended on environment, e.g. available bandwidth- Configuration (Service-Options)- Preconditions test if a service provider is applicable or if Service-
Options are applicable
Environmental data
Description of Service Provider
BasisService
User
Endsystem
Network
Configuration
Service-Option
Service-Option
Service-Option
Service
31Bernd Reuther, University of Kaiserslautern
Key-Functionality: Brokering and configuration of services
b) Service brokering
ServiceUser
ServiceProvider
ServiceBroker
a) S
ervi
ce d
escr
iptio
n
32Bernd Reuther, University of Kaiserslautern
Brokering of Services
For all service providers determine an optimal service configuration- Assume: there are “few” service providers (TSP)
Selection of Service-Options (SO) per service provider- Problem: 2 n possibilities for {SO1 ,..., SOn }
• Permutation are irrelevant- Dependencies of Service-Options SOi among each other
• Independent• Semantically dependent
→ must be specified explicitly• Implicitly dependent, i.e. mutual influence of ratings
→ will be recognized automatically
33Bernd Reuther, University of Kaiserslautern
Selection of Service-Options
iSOminiSO max
iSOEstimate effect of
worst: best:
),(),( maxi
RR SOSSMSSM
iSO iSOOptionenOptionen \:IF
THEN do not apply :
iSO OptionenSO j
),(),( mini
RR SOSSMSSM
iSO ii SOOptionenOptionenSOSS \:;:
IF
AND not semantically depended to any
THEN apply :
OptionsSOi FOR EACH
},...,{:: 1 nSOSOOptionsServiceBasisS INITIALZE
1. Sequential testing of applicability of SO
2. Test remaining combination of SO
34Bernd Reuther, University of Kaiserslautern
Performance Example: best case, independent SO
max. ~ 0,6ms
Plattform:•1 Core•2,44 Ghz CPU•Linux
Timer:•High resolution•Per process
No dependencies
Number of Service-Options
Tim
e ne
eded
for b
roke
ring
[µs]
35Bernd Reuther, University of Kaiserslautern
Performance Example: worst case, only dependent SO
max. ~ 200ms
Plattform:•1 Core•2,44 Ghz CPU•Linux
Timer:•High resolution•Per processTi
me
need
ed fo
r bro
kerin
g [µ
s]
Number of Service-Options
No dependenciesDependencies among all Service-Options
1. Problem statement and goals2. Overview of Basic Concepts3. Building Block Interface4. Service Selection5. Service Composition
SONATEService oriented Network Architecture
Problem Statement Implementing new developments Goals of the SONATE approach
SONATE1. Problem statement and goals
38Bernd Reuther, University of Kaiserslautern
Problem Statement
It is hard to integrate new mechanismsinto the current Internet
(and even harder to change existing ones)
Cause: Many implicit dependencies
(i.e. tight coupling)between existing mechanisms
The problem is not limitedto specific protocols ormechanisms
It is an architectural issue!
39Bernd Reuther, University of Kaiserslautern
Implementing new developments
Extendableprotocol header
Application Level Framing
New Layers
Dynamic composition of building blocks- Not available today- Issue of:
Future Network research
40Bernd Reuther, University of Kaiserslautern
Goal
A future network architecture should be flexible:
- Long term flexibility:Support evolution of networks
- Short term flexibility:Dynamically adapt to requirements and constraints
41Bernd Reuther, University of Kaiserslautern
Long Term Flexibility
Support evolution of networks- Enable: stepwise introduction of new functionality- Easy introduction of new functionality without being dependent on
agreements with vendors / providersReasons:• Enable utilization even of highly specific or experimental functionality• Reduce time to market• Opportunity even for small companies to provide
(network-) services- Of course standardization is still required
42Bernd Reuther, University of Kaiserslautern
Short Term Flexibility
Dynamic adaption of Networks to- Requirements of current application, e.g.
• Different behavior for regular or emergency phone calls- Current network constraints, e.g.
• Mobile or wired network access• A Network may require to use authentication, when prioritization is
requested- Capabilities of currently involved nodes
• Adapt to supported functionality. This is important to utilize new functionality
Building Blocks Protocol-Graphs SONATE Framework Signalling Protocol-Graphs
SONATE2. Overview of Basic Concepts
44Bernd Reuther, University of Kaiserslautern
Building Blocks
Functionality is provided by self-contained building blocks (BB)- Protocols (e.g. flow-control, retransmission or a video codec)- Other functionality (e.g. monitoring or lookup services)
BB have generic and well-defined interfaces
#17
BB Description (XML)→ the service, what application and other BB „see“
BB identifier→ reference the mechanism, communicating parties must use the same protocol
BB impementation→ local code
45Bernd Reuther, University of Kaiserslautern
Protocol-Graph
Interaction of BB is defined by a protocol-graph description- Order of building blocks- Possible data exchange
Descriptions can change easier than code Placement of a functionality is not fixed
Building Blocks & Protocol-Graph-Descriptions
→ Foster long term flexibility
46Bernd Reuther, University of Kaiserslautern
Framework
Protocol-graph processing Management of BB Interfaces implemented as building blocks
Repository of building blocks
Msg1 Msg2 Msg3
Timer, Events,debugging support, …
From previous node
To successor nodeManagement
Physical orvirtual link
Physical orvirtual link
P-GraphEngine
ToApplication
receive send
FromApplication
Msg1’ Msg3’Msg2’
47Bernd Reuther, University of Kaiserslautern
Selection & Composition
Create Protocol-Graph descriptions- Select building blocks to be
used- Compose (connect)
building blocks Adapt to (current)
requirements andconstraints
Selection &Composition
Application: Requirements
Network: Constraints
…
48Bernd Reuther, University of Kaiserslautern
Signal Protocol-Graphs
Be independent of Selection & Composition algorithms Intermediate nodes may
- alter workflows, i.e. act as gateways- provide feedback, i.e. request different behavior
Initiator Next Node
Msgs
Selection &Composition
Framework FrameworkMsgs
Gateway Node
Selection &Composition
FrameworkMsgsMsgs
Functional Composition& Processing of Workflow-Descriptions
→ Foster short term flexibility
49Bernd Reuther, University of Kaiserslautern
Protocol-Graph Signaling Considerations
Similar to Protocol-IDs used in layering
Many BB (nodes) and description of connections (edges) result in more complex description
Use heuristics to minimize signaling data- List BB identifiers- Define default connections, list exceptions only
• Based on sequence of BB list (up – down)• Based on data types
- Efficient (flat) numbering of ports in an graph• BB1.Port1 → 1, BB1.Port2 → 2, BB2.Port1 → 3, …
Building block interaction Ports Connections Threading
SONATE3. Building Block Interface
51Bernd Reuther, University of Kaiserslautern
Building block interaction (1)
BBs are self-contained, i.e. must not use implementation details of other BBs- A framework must manage data transfer between BBs
Incoming data (usually) triggers activity- Data flow and threading is related
Building blocks need to distinguish the meaning of data- Example: AES256 building block
• Is the data plaintext, ciphertext or the key?• What should the building block do with it?• Where to send the result?
Attach „meaning tag“ to data?- Meaning is building block specific- Meaning does not depend on data type
Better: use different „Ports“ to distinguish meaning of data
52Bernd Reuther, University of Kaiserslautern
Building block interaction (2)
AES256
plain
crypt
key
53Bernd Reuther, University of Kaiserslautern
Port details
Ports can be used to communicate- Arbitrary data types possible- Simple or standardized typed should be used
MessageList: default data type for networking data- Contains a list of „fields“ (byte arrays)- Field 0 used for payload- Can be (de)serialized to send over network or to apply
transformations
Data types must match- Framework will only do simple conversions
54Bernd Reuther, University of Kaiserslautern
Building Block Connections and Scope
Building blocks are hidden- BBs only see connections, not
what‘s behind- Rest of the graph is hidden
Connections are enumerated- Allows to distinguish different
partners
Building block
up
down
value
other Building block
other Building block
other Building block
other Building block
Building block scope
?
1 2
3
4
55Bernd Reuther, University of Kaiserslautern
Threading (1)
Threading is needed- Parallel streams- Parallel activities within a protocol-graph
When to do threading?- One thread per BB inefficient
How to synchronize threads?- Different BBs need different synchronization paradigms- Framework should not define paradigm
Leave it to the building blocks- „Filters“
56Bernd Reuther, University of Kaiserslautern
Threading (2)
Filters- Part of the port- Are called when messages come
in
Filter called by the sender- No unnecessary thread change
Code defined by the receiver- Can implement any
synchronization paradigm (Queuing, Blocking)
- Can inspect messages before switching threads
- Can simply „use“ the calling thread to circumvent threading
Building block
Port
FilterSender threadReceiver thread
Mes
sage
Service selection motivation Steps of service selection Analytical hierarchy process
SONATE4. Service Selection
58Bernd Reuther, University of Kaiserslautern
Service Selection Motivation (1)
Selection & Composition Approaches- Manually (supported by tools)- Templates (predefined structure, delayed completion)- Evolutionary algorithms (automatic but time consuming process)- Compose few coarse grain modules / partial protocol-graphs- Compose fine grained building blocks- …
59Bernd Reuther, University of Kaiserslautern
Service Selection Motivation (2)
Trade off: time available vs information available- Design time:
• Info: general requirements and protocols are known• Time: Nearly arbitrary time available
- Deployment time:• Info: also system constraints are known• Time: Several seconds available
- Run time:• Info: also user requirements are known and
available resources may be known• Time: should not exceed ~ 100ms
Approaches differ regarding- Flexibility- Quality of results- Effort for calculation
It is unlikely that one approach is always optimal
60Bernd Reuther, University of Kaiserslautern
Support several Protocol-Graph „generators“
Application
Requirements
Conventional
TCP/IPUDP/IPSCTP/IP…
Compound Template S&C
…
ServiceBroker
Offerings
Network Abstraction API
SelectedService
Requirements
Workflow
generators
Access SONATE Framework
Similar to selecting a protocol stack,but generators may take some time→ define time limitations
61Bernd Reuther, University of Kaiserslautern
Steps of Service Selection
Set of all possible Service offerings
Set of all available Service offerings
Mandatory & Wanted RequirementsService Composition
Set of all appropriate
Service offerings
Mandatoryrequirements
Check mandatoryrequirements
Service usage
Ordered list of Service offerings
Wantedrequirements
Multi-criteriadecision
62Bernd Reuther, University of Kaiserslautern
Multi-Criteria Decision Analysis
Selecting a service by comparing more than one criteria is a multi-criteria decision making problem
For solving such a problem, Multiple Criteria Decision Analysis (MCDA) methods exist- Several algorithms (MAUT, AHP, ELECTRE III, Evamix) exist for
doing this Analytical Hierarchy Process (AHP) allows interdependent
criteria- Checking consistency of evaluation measures
AHP must be adapted for automatic service selection - Was designed for human decision processes
63Bernd Reuther, University of Kaiserslautern
Service Selection: AHP
Fig. Analytic Hierarchy Process (AHP)
Absolutely More
Absolutely Less
9753-1 or 1-3-5-7-9
Moderately Less
Moderately MoreEqual
Fig. Pairwise comparison scale
64Bernd Reuther, University of Kaiserslautern
Service Selection: Usage of AHP
AHP in service description and selection- Input: a set of effects
• Requirements: importance of effects• Offerings: level of “quality”
- Requirements• Importance of effects given by application• Defined pairwise
- Offerings• Effects should be measured in well defined scenario• Mapping of measured values to level of “quality”
- Defines an interpretation of what is “good” and what is “bad”- Output
• A service with the highest priority value
65Bernd Reuther, University of Kaiserslautern
Mapping of measured values
The mapping must be generic The mapping must be monotonic A linear mapping is in general not adequate Use monotonic interpolation/extrapolation
- Enable simple as well precise mapping functions- Mapping parameters are part of requirements specification
Fig. Values in terms of hints
+/- 1
9
-9
HintsMeasured value
Prio
rity
Manual composition Evolutionary algorithm Template approach Early definition of partial protocol graphs
Service Description per BB Required
SONATE5. Service Composition
67Bernd Reuther, University of Kaiserslautern
Evolutionary algorithm (1)
Evolutionary algorithms1. Create new solutions by mutating existing ones2. Rank solutions using a metric3. Retain only the best solutions4. Got back to 1.- Can handle NP hard problems
Main issues when applied to protocol-graphs- How to evaluate a protocol graph?- How to mutate a protocol graph?
Building block interaction model needed Calculate expected effects of building blocks
- Part of BB description- Or as functions of BBs
68Bernd Reuther, University of Kaiserslautern
Evolutionary algorithm (2) Generators
- Create preliminary solutions- Used to fill the solution pool
Improvement cycle- Create new solutions by mutation- Try to fix mistakes- Retain only the best solutions- Runs very fast, thousands of cycles
possible per second
Termination criteria- Target quality- Number of improvement cycles- Limited time- Combinations possible
69Bernd Reuther, University of Kaiserslautern
Template Based Composition
Protocol-Graph with place-holders instead of Building Blocks
Split Composition between design- and run-time- Composition at design-time- Selection of implementation at
run-time Place-Holder examples
- Codecs or Encryption mechanisms• Required “strength” • Availability of codecs
- Functionality for reducing loss• Codecs sensibility to loss• Type of access network
Template
Place-Holders
70Bernd Reuther, University of Kaiserslautern
Place-Holder
Well-defined ports- Defines provided effects- Defines allowed data types
Place-Holder also acts as container- Enabling and Disabling a
functionality at runtime- Provide generic ports (e.g.
monitoring, administration)
Type: bin dataEffects: loss =0, MTU’ = MTU-16
Type: bin data
Type: avg_loss rate (optional)
Type: on/off
71Bernd Reuther, University of Kaiserslautern
Requirements Domain
(e.g. Telephony)
Application
Template Description
API
Selection of Template
Requirement Description+ Policies
Selection ofBB(s) to fillPlaceholder(s)
Domain specific templates
Pool ofBB
73Bernd Reuther, University of Kaiserslautern
Service Description per BB Required
Similar to descriptions of communication services
Describe modification of a Service
Describe modification ofParameters / Requirements
Determine effects analytically or by measurements
ARQavgLossRate <= 0,1%
avgLossRate’ = 0,0%
ARQavgPacketRate’ = 50+x/s
avgPacketRate = 50/s
Integrated Communication Systems ICSY
University of KaiserslauternDepartment of Computer ScienceP.O. Box 3049D-67653 Kaiserslautern
Dr. Bernd Reuther
Phone: +49 (0)631 205-2161Fax: +49 (0)631 205-30 56
Email: [email protected]: http://www.icsy.de