Transcript Service Oriented Network Architectures (SONATE), Dr. Bernd

SONATE
Euro-NF PhD Course
University of Kaiserslautern
06 March 2012
Dr. Bernd Reuther
University of Kaiserslautern, Germany
Department of Computer Science
Integrated Communication Systems ICSY
http://www.icsy.de
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
Bernd Reuther, University of Kaiserslautern
2
Project Beyond-IP 1997-1999
 Considered Problem
 Approach
 Conclusion
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
Bernd Reuther, University of Kaiserslautern
4
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
Bernd Reuther, University of Kaiserslautern
5
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
Bernd Reuther, University of Kaiserslautern
6
Project DANCE 2001-2003
 Motivation
 Terminology: Service, …
 Abstraction of communication protocols



Application of the SOA paradigm
Service description
Brokering and configuration of services
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!
Bernd Reuther, University of Kaiserslautern
8
Innovation within Transport and Network Protocols
 Innovation in the Internet
 New Applications
 New Network-Technologies
 Few innovation within transport
and network protocols
Applications
Transport and Network
Protocols
Network Technologies
 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!
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.
Bernd Reuther, University of Kaiserslautern
9
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
Bernd Reuther, University of Kaiserslautern
10
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”
Bernd Reuther, University of Kaiserslautern
11
Avoid tight coupling today?
 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
Application
Application
Application
Middleware
Middleware
Middleware
Middleware
Communication System
Bernd Reuther, University of Kaiserslautern
12
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
Bernd Reuther, University of Kaiserslautern
13
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)
Bernd Reuther, University of Kaiserslautern
14
Terminology
Common terms:
 Service, Mechanisms, Techniques
“Our” terms:
 Service Elements
 Service Description
 Communication Services
Services, Mechanisms, Techniques
A „service“ denotes an abstraction level (like in the ISO/OSI model).
Service
(the visible effects)
Example: reliable transfer
of a byte stream
abstraction
implement
Mechanisms
(algorithms / protocols)
Example: TCP
implement
Code
(bits & bytes)
Bernd Reuther, University of Kaiserslautern
Example: Linux Kernel-Modul
for TCP
16
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
Bernd Reuther, University of Kaiserslautern
17
Service Description
 Mapping between Mechanism and Service
 Approaches for descriptions
 Mechanisms + Interface resulting in a
unique service
Services
1
 Service + Interface may by implemented by
several mechanisms
→ need to select appropriate mechanisms
Bernd Reuther, University of Kaiserslautern
n
Mechanisms
18
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
Bernd Reuther, University of Kaiserslautern
19
Project DANCE 2001-2003
Abstraction of communication protocols




Key-functionality
1. Service description
2. Brokering and configuration of services
3. Interface
Service
User
2
4
c) Interface
5
Service
Provider
a) Service description
SOA-Paradigm
b) Service brokering
3
Service
Broker
1
 Support of three key functionalities
Bernd Reuther, University of Kaiserslautern
22
A service oriented Approach for Abstraction of
Communication Protocols in the Internet
1. Description of
offered services
2. Description of
requested services
3. Broker result
4. Configuration of
TSP
5. Utilization
Bernd Reuther, University of Kaiserslautern
23
Service
User
Service
Provider
Bernd Reuther, University of Kaiserslautern
a) Service description
Key-Functionality: Service description
Service
Broker
24
Steps of Service Brokering
Set of all Service
offerings
Preconditions+
dynamic data
Set of all
available Service
offerings
Set of all
appropriate
Service offerings
Mandatory
requirements
Wanted
requirements
Ordered list of
Service offerings
Service usage
Bernd Reuther, University of Kaiserslautern
25
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
Bernd Reuther, University of Kaiserslautern
26
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
R
R
• Semantic x  [lb , ub ] with Ei valid for x
 In offerings
• lbO lower boundary, ubO upper boundary
• Semantic x [lb O , ubO ] with Ei valid for x
R
R
O
O
 An offering is appropriate if: [lb , ub ]  [lb , ub ]  
Bernd Reuther, University of Kaiserslautern
27
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 wi  [0,1]   of properties Ei
• Relative rating of properties
→ wi determined by application developers
 In offerings
• Quality qi ,k  [0,1]   of a property Ei of a TSPk
• Relative rating of TSP regarding one specific property
→ qi,k determined by …
 Quality of an offering:
Bernd Reuther, University of Kaiserslautern

n
i 1
wi qi ,k
28
Determine the Quality of an Offering
 Subjective method: qi,k „defined by experts“
 Objective method based on benchmarks
 Benchmark Bi is neutral, delivers measurements Qi ,k  Bi (TSPk )
• Used to compare TSP, no prediction
qi ,k  f (Qi ,k )
 Interpreting measurements by f ( x) :   [0,1]
• Offerings must specify an interpretation f
• Requirements may specify an alternative interpretation f´
Bernd Reuther, University of Kaiserslautern
Quality q
Specific
measure
rating
29
Description of Service Provider
 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 ServiceOptions are applicable
Service
Configuration
Environmental data
Service-Option
Service-Option
Service-Option
Bernd Reuther, University of Kaiserslautern
User
Basis
Service
Endsystem
Network
30
Service
User
Service
Provider
Bernd Reuther, University of Kaiserslautern
a) Service description
Key-Functionality: Brokering and configuration of services
b) Service brokering
Service
Broker
31
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
Bernd Reuther, University of Kaiserslautern
32
Selection of Service-Options
1. Sequential testing of applicability of SO
INITIALZE
S : Basis Service Options : {SO1 ,..., SOn }
SOi  Options
FOR EACH
Estimate effect of
min
worst: SOi
SOi
max
best: SOi
IF M ( S , S )  M ( S , S  SOi
R
THEN do not apply
R
SOi :
max
Optionen : Optionen \ SOi
IF M ( S , S )  M ( S , S  SOi
R
R
)
min
)
SOi not semantically depended to any SO j  Optionen
S : S  SOi ; Optionen : Optionen \ SOi
THEN apply SOi :
AND
2. Test remaining combination of SO
Bernd Reuther, University of Kaiserslautern
33
Performance Example: best case, independent SO
No dependencies
Time needed for brokering [µs]
max. ~ 0,6ms
Plattform:
• 1 Core
• 2,44 Ghz CPU
• Linux
Timer:
• High resolution
• Per process
Number of Service-Options
Bernd Reuther, University of Kaiserslautern
34
Performance Example: worst case, only dependent SO
No dependencies
Dependencies among all Service-Options
Time needed for brokering [µs]
max. ~ 200ms
Plattform:
• 1 Core
• 2,44 Ghz CPU
• Linux
Timer:
• High resolution
• Per process
Number of Service-Options
Bernd Reuther, University of Kaiserslautern
35
SONATE
Service oriented Network Architecture
1.
2.
3.
4.
5.
Problem statement and goals
Overview of Basic Concepts
Building Block Interface
Service Selection
Service Composition
SONATE
1. Problem statement and goals
 Problem Statement
 Implementing new developments
 Goals of the SONATE approach
Problem Statement
It is hard to integrate new mechanisms
into 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 limited
to specific protocols or
mechanisms
 It is an architectural issue!
Bernd Reuther, University of Kaiserslautern
38
Implementing new developments
 Extendable
protocol header
 Application Level Framing
 Dynamic composition of
building blocks
 Not available today
 Issue of:
Future Network research
 New Layers
Bernd Reuther, University of Kaiserslautern
39
Goal
 A future network architecture should be flexible:
 Long term flexibility:
Support evolution of networks
 Short term flexibility:
Dynamically adapt to requirements and constraints
Bernd Reuther, University of Kaiserslautern
40
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 / providers
Reasons:
• 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
Bernd Reuther, University of Kaiserslautern
41
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
Bernd Reuther, University of Kaiserslautern
42
SONATE
2. Overview of Basic Concepts




Building Blocks
Protocol-Graphs
SONATE Framework
Signalling Protocol-Graphs
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
BB Description (XML)
→ the service, what
application and other
BB „see“
#17
BB identifier
→ reference the mechanism,
communicating parties must
use the same protocol
BB impementation
→ local code
Bernd Reuther, University of Kaiserslautern
44
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
Bernd Reuther, University of Kaiserslautern
45
Framework
 Protocol-graph processing
 Management of BB
 Interfaces implemented as building blocks
To
Application
From
Application
Msg1
Msg2
From previous
node
Msg3
P-Graph
Engine
receive
Timer, Events,
debugging support, …
Physical or
virtual link
send
Management
Msg1’
Msg2’
Msg3’
To successor
node
Physical or
virtual link
Repository of building blocks
Bernd Reuther, University of Kaiserslautern
46
Selection & Composition
 Create Protocol-Graph
descriptions
Application: Requirements
Network: Constraints
 Select building blocks to be
used
 Compose (connect)
building blocks
 Adapt to (current)
requirements and
constraints
Bernd Reuther, University of Kaiserslautern
…
Selection &
Composition
47
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
Selection &
Composition
Functional Composition
& Processing of Workflow-Descriptions
Selection &
Composition
→ Foster short term flexibility
Framework
Framework
Msgs
Initiator
Framework
Msgs
Next Node
Bernd Reuther, University of Kaiserslautern
Msgs
Msgs
Gateway Node
48
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, …
Bernd Reuther, University of Kaiserslautern
49
SONATE
3. Building Block Interface




Building block interaction
Ports
Connections
Threading
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
Bernd Reuther, University of Kaiserslautern
51
Building block interaction (2)
plain
AES256
key
crypt
Bernd Reuther, University of Kaiserslautern
52
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
Bernd Reuther, University of Kaiserslautern
53
Building Block Connections and Scope
other Building
block
1
other Building
block
?
up
2
Building block
value
3
 Building blocks are hidden
 BBs only see connections,
not what‘s behind
 Rest of the graph is hidden
other Building
block
down
4
Building block scope
other Building
block
Bernd Reuther, University of Kaiserslautern
 Connections are
enumerated
 Allows to distinguish
different partners
54
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“
Bernd Reuther, University of Kaiserslautern
55
Threading (2)
 Part of the port
 Are called when messages
come in
 Code defined by the receiver
 Filter called by the sender
 No unnecessary thread
change
Filter
Sender thread
Receiver thread
 Can implement any
synchronization paradigm
(Queuing, Blocking)
 Can inspect messages before
switching threads
 Can simply „use“ the calling
thread to circumvent
threading
Message
 Filters
Port
Building block
Bernd Reuther, University of Kaiserslautern
56
SONATE
4. Service Selection
 Service selection motivation
 Steps of service selection
 Analytical hierarchy process
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
…
Bernd Reuther, University of Kaiserslautern
58
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
Bernd Reuther, University of Kaiserslautern
59
Support several Protocol-Graph „generators“
Application
Requirements
Similar to selecting a protocol stack,
but generators
may take
some time
Access SONATE
Framework
→ define time limitations
Network Abstraction API
Selected
Service
Service
Broker
Requirements
Offerings
Compound
TCP/IP
UDP/IP
SCTP/IP
…
Bernd Reuther, University of Kaiserslautern
Template
S&C
…
Workflow generators
Conventional
60
Steps of Service Selection
Set of all possible
Service offerings
Service Composition
Mandatory & Wanted
Requirements
Set of all
available Service
offerings
Check mandatory
requirements
Multi-criteria
decision
Set of all
appropriate
Service offerings
Mandatory
requirements
Wanted
requirements
Ordered list of
Service offerings
Service usage
Bernd Reuther, University of Kaiserslautern
61
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
Bernd Reuther, University of Kaiserslautern
62
Service Selection: AHP
Moderately
Less
Absolutely
Less
-9
-7
-5
Moderately
More
Equal
-3
-1 or 1
3
5
Absolutely
More
9
7
Fig. Pairwise comparison scale
Fig. Analytic Hierarchy Process (AHP)
Bernd Reuther, University of Kaiserslautern
63
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
Bernd Reuther, University of Kaiserslautern
64
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
Priority
9
Hints
Measured value
+/- 1
-9
Fig. Values in terms of hints
Bernd Reuther, University of Kaiserslautern
65
SONATE
5. Service Composition




Manual composition
Evolutionary algorithm
Template approach
Early definition of partial protocol graphs
 Service Description per BB Required
Evolutionary algorithm (1)
 Evolutionary algorithms
1.
2.
3.
4.

Create new solutions by mutating existing ones
Rank solutions using a metric
Retain only the best solutions
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
Bernd Reuther, University of Kaiserslautern
67
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
Bernd Reuther, University of Kaiserslautern
 Termination criteria




Target quality
Number of improvement cycles
Limited time
Combinations possible
68
Template Based Composition
Template
Place-Holders
 Protocol-Graph with placeholders 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
Bernd Reuther, University of Kaiserslautern
69
Place-Holder
 Well-defined ports
Type: bin data
Effects: loss =0, MTU’ = MTU-16
 Defines provided effects
 Defines allowed data types
Type: avg_loss rate (optional)
 Place-Holder also acts as
container
Type: bin data
 Enabling and Disabling a
functionality at runtime
 Provide generic ports (e.g.
monitoring, administration)
Type: on/off
Bernd Reuther, University of Kaiserslautern
70
Domain specific templates
Application
Requirements
Domain
Requirement Description
+ Policies
(e.g. Telephony)
API
Selection of Template
Template
Description
Selection of
BB(s) to fill
Placeholder(s)
Pool of
BB
Bernd Reuther, University of Kaiserslautern
71
Service Description per BB Required
 Similar to descriptions of communication services
 Describe modification of a Service
avgLossRate’ = 0,0%
ARQ
avgLossRate <= 0,1%
 Describe modification of
Parameters / Requirements
avgPacketRate = 50/s
ARQ
avgPacketRate’ = 50+x/s
𝑛
𝑥=
𝑎𝑣𝑔𝑃𝑎𝑐𝑘𝑒𝑡𝑅𝑎𝑡𝑒 ∗ 𝑎𝑣𝑔𝐿𝑜𝑠𝑠𝑅𝑎𝑡𝑒 𝑖
𝑖=1
 Determine effects analytically or by measurements
Bernd Reuther, University of Kaiserslautern
73
Dr. Bernd Reuther
Integrated Communication Systems ICSY
University of Kaiserslautern
Department of Computer Science
P.O. Box 3049
D-67653 Kaiserslautern
Phone:
Fax:
+49 (0)631 205-2161
+49 (0)631 205-30 56
Email:
Internet:
[email protected]
http://www.icsy.de