Traffic Shaping PDF

9.
Multimedia Communication Systems

Contents
Multimedia Kommunikation SS‘99

1 / 92
9.1 Overview 9.7 Resource Admission Control

9.2 Cooperative Computing – Reservation Model
– Cooperation Awareness 9.8 Resource Management
– Group Communication Architecture – Scheduling
9.3 Application Sharing Approach – Traffic Shaping
– Architecture – End-to-End Error Control
9.4 Audio/Video Conferencing – Resource Monitoring and Adaptation
– Control 9.9 Architecture
– Session Management
9.5 Transport Subsystems
9.6 Quality of Service
– Resource Management
– QoS Negotiation
– Translation & Scaling
9. Multimedia Communication Systems
9.1 Overview

2 / 92
In this chapter we discuss issues related to multimedia communication systems

above the data link layer.
7 Appl.
For this, we subdivide the higher layers of the Multimedia
Communication System into two subsytems: 6 Present. Appl.
5 Session
applictaion subsystem, which is responsible for management 4 Transp.

Transp.
and service issues for group cooperation and session 3 Net
2 Link
orchestration (supporting a large scale of multimedia
1 PHV
applications)
transport subsytsems (here transport and network layer protocols
for multimedia applications are presented).
9.1 Overview

3 / 92
Some multimedia applications:

– Multimedia Mail
– Virtual Reality Applications
Application Subsystems
– Video Conferencing
– CSCW (Computer Supported Cooperative Work)
Communication Requirements:
– Highspeed networks with high transfer rates
e.g.: FDDI, Switched Ethernet, Fast Ethernet,
Gigabit Ethernet, DQDB, ATM, ... Transport Subsystems
– High performance transport protocols
e.g.: TCP, XTP, ATM transport protocols
9.2 Cooperative Computing / Application Subsystem

4 / 92
Cooperative Computing is generally known as Computer-Supported-

Cooperative-Work (CSCW).
Tools for cooperative computing:

– Electronic mail
– Bulletin boards
– Screen sharing tools
– Application sharing
– Text-based conferencing systems
– Video conference systems (e.g. MBone Tools, ProShare from Intel, PictureTel,
Teles Online, NetMeeting from Microsoft)
9.2 Cooperative Computing / Cooperation Dimension

5 / 92
Computer-Supported cooperation may be categorized according to the

following parameters:
Time:
– Asynchronous cooperative work (not at the same time)
– Synchronous cooperative work (at the same time)
User Scale:
– Single users, two users (“dialogue, point to point“, direct cooperation) or groups
with more than two users
– Static or dynamic groups, if either the members are pre-determined or not
Control:
– Centralized - when controlled by a “chairman“
– Distributed - when control provide consistent cooperation
Locality:
– Cooperation at the same place
– Tele-cooperation of users at different places
9.2 Cooperative Computing / Cooperation Awareness

6 / 92
Cooperation-transparent systems
– Existing application extended for cooperation
(Single user document editors expanded for simultaneous editing of a shared
document among several users, e.g. some text processors)
Cooperation-aware systems
– Dedicated software application for CSCW
(e.g. Lotus Notes, conferencing systems)
9.2 Cooperative Computing / Group Communication Architecture

7 / 92
Group Communication Agent Group Communication Agent
Application Application
Sharing Group Sharing Group
Rendevous Rendevous
Conferencing Conferencing
Communication Communication
(Transport) Support (Transport) Support
Group Communication Agent

Multicast Application
Communication Sharing Group
Network Rendevous
Conferencing
Communication
(Transport) Support

8 / 92
Group communication:
– synchronous or
– asynchronous communication of multiple users
Support Model:
– With group communication agents (cooperating via a multicast network)
– Group rendevous (organization of meetings and delivering information)
– Shared applications (simultaneous replication and modification of information
to multiple users, e.g. telepointing, joint editing)
– Conferencing
System Model:
– client-server model
Interface Model:
– exchanging information within the support model (object oriented)

9 / 92
Clients:
– User interfaces supporting interaction between group memebrs and the system
Servers:
– Specialized servers for different tasks of the group communication work, e.g.
· Directory server (for group rendezvous services)
· Application sharing server
· Conference server
· Multimedia server (for intermedia synchronization)


10 / 92
User Presentation Protocols:

Between the clients, e.g.
– Open, close, dynamically join or leave a meeting
– Floor passing
Group Work Management Protocols:

Between the clients and the servers, e.g.
– Registration of meetings
– Queries for information about meetings
9.2 Cooperative Computing / Group Rendezvous

11 / 92
Setting up of group and delivering information about groups and meetings

Synchronous Rendezvous Methods (e.g. sdr - MBone´s session directory tool):
Explizit invitations (point-to-point or point-to-multipoint)
– Initiator of a meeting has to know where users reside
Using directory services (X.500), knowledge base with information about the
meeting, e.g.
– Name of the meeting/conference
– Registered or authorized participants
– Role of participants
Asynchronous Rendezvous Methods:
– Using e-mail
– Using bulletin boards (local bulletin boards or World Wide Web)
– Simple Conference Announcement Protocol (Draft, 1996)
9.2 Cooperative Computing / Group Rendezvous

12 / 92
Used in tele-conferencing for cooperative document editing and software

development
Shared objects (documents) displayed in shared windows
Shared application program (e.g. text processor) executes input from a
participant
Execution results on the document distributed among all participants
Application sharing architecture
– Centralized
– Replicated
Consistency of shared objects
Floor passing control
9.3 Application Sharing Approach

13 / 92
Centralized:
é Single copy of the shared application runs at one site
é All input forwarded to the local site
é Output (shared document) distributed to all sites
+ Easy consistency maintenance (only one copy of the application)
− High network traffic (for output distribution)
− Relatively unreliable (if central fails then everything is down)
Replicated:
é Copy of the shared application runs locally at each site
é Input distributed to all sites
+ Low network traffic and response times (only distribution) apart from the
(enormous?) traffic arising from consistency maintenance
− Difficult consistency maintenance
9.3 Application Sharing Approach / Architecture

14 / 92
centralized
Floor Holder
output
Shared Window Shared Window
Network
Input Output
Shared Application Ì bottleneck
replicated
Floor Holder Floor Holder
input
Shared Window Shared Window
Network
Input Output Input Output
Shared Application Shared Application

consistency trouble
9.3 Application Sharing Approach / Replicated Architecture

15 / 92
Consistency Maintenance of Shared Documents, e.g.

– Centralized locks
– Dependency detections
– Floor passing
Floor Passing Control:

Floor holder has right to manipulate shared documents in shared windows, e.g.
– Open or close shared windows
– Load a document into a shared window
– Issue input to shared application

16 / 92
CSCW CSCW CSCW

Control Control Control
Input Input Input
Merged Merged Merged

Input Input Input
Shared Shared Shared
Shared Data Shared Data Shared Data
Program Program Program
Display Display Display


17 / 92
CSCW (computer supported cooperative work)
control component checks wether the active site is floor holder

– floor holder accepts and processes inputs; distributes inputes to other sites
– no floor holders: discards its own inputs; accepts input which comes from other
sites
9.4 Audio/Video Conferencing

18 / 92
Management service which controls simultaneous face-to-face communictaion

between multiple users using multiple media (video, audio etc.)
Video:
– Conference participants (all, a few, speaker or moderator only)
– Large video walls with multiple high-resolution screens may be used especially for
· Conferences with more than four participants
· Display of view-graphs, images, animations etc.
Audio (true full-duplex high-quality communictaion with echo cancellation):

– Discussions
– Important for clarifying visual information
9.4 Audio/Video Conferencing Services

19 / 92
Requirements:
– High bandwidth (for data-intensive media)
– Low latency (for user interactivity)
– Distributed messaging of data and control information
Conference Control:
– Management of conferences (Establishing, Closing, Adding/removing users)
– Providing information about conferences (Conference name, duration, etc.)
Centralized or distributed control

– Centralized control is easy to implement
– Distributed control is much more complicated but less sensitive to failure
(central control does not work if cenral is inoperative)
9.4 Audio/Video Conferencing / Control

20 / 92
State Information of the Conference, e.g.:

– Conference name
– Start of the conference
– Policies associated with the conference
– Participants
– Duration
– Topic
Functions:
– Establishing a conference (users agree upon a common conference state, e.g.
encoding rules, access rights, chairman of the conference)
– Adding new participants and removing participants during a conference
– Closing a conference
9.4 Audio/Video Conferencing / Control - Centralized

21 / 92
Central Server:
– Stores the conference state (i.e. conference state is cenrally organized)
– Manages conference control
– Is able to exchange explicity the conference state
Establishment of a Conference with Centralized Control:
1. Initiation (of the chairman) of the conference selects an initial group of participants
2. He inquires addresses of the conference participants from a cenral directory sever.
3. These participants are explicitly invited.
4. Each invited client responds to the invitation
Í initiator is informed who will participate.
5. Negotiation of conference policies and admission of resources are performed.
This shared confernce state is stored on a central server and distributed to all
participants using a reliable messaging service.
9.4 Audio/Video Conferencing / Control - Distributed

22 / 92
Distributed Control:
– Manages no global notions of group membership
– Gives no consistency guarantees (same state view by all participants)
– Exchanges periodically the conference status between the participants to
minimize the loose of control by an unreliable messaging service
Establishment of a Conference with Distributed Control:

1. Initiator of the conference establishes a multicast space (multicast tunnel in
MBone) with multicast entries.
2. Participants join the conference by tuning into a particular multicast entry
(multicast address) announced by group rendezvous means (sdr in MBone)
3. Each participant informs the others about his own status.
9.4 Audio/Video Conferencing / Session Management Architecture

23 / 92
Centralized Conference Control:

+ Guaranteed consistency of the conference state
+ Easy to implement
– Adding of a new participant causes large delays (explicit exchange of the conference
state among all participants)
– Difficult reestablishment of the conference state after a link failure
Distributed Conference Control:
+ Fault tolerance (easy reestablishment after network link failures)
+ Well suited for small conferences
– The conferences participants may not have the same view of the state space
– Hard to implement, costly, difficult to understand
Replicated Conference Control:
+ Low “request response time“
– Adding of a new participants causes large delays (explicit exchange of the conference
state among all participants)
– Higher network load
9.4 Audio/Video Conferencing / Session Management Architecture

24 / 92
Session Management:
– Important part of the multimedia architecture
– Separates the control part and the data part from the actual transport
The entity which takes this on is called Session Manager:
– Including local and
– Remote functonalities
Media Agents:
– Are separate from the sesson manager and
– have the Responsibility for decisions specific to each type on media
Shared Workspace Agent:
– Transmits shared objects among the shared applications
9.4 Audio/Video Conferencing / Session Management Functionalities

25 / 92
Local functionalities:
– Membership control management (e.g.: participant authentication)
– Control management (for shared workspace, such as floor control)
– Media control management (e.g.: communication among media agents)
– Configuration management (such as exchange of interrelated QoS parameters or
selection of appropriate services according to QoS)
– Conference control management (such as establishment, modification and
closing of a conference)
9.4 Audio/Video Conferencing / Session Management Functionalities

26 / 92
Management tasks:
– configuration management
– fault management
– performance management
– accounting management
– security management
Remote functionalities:
– Communication with other session managers
– Exchange of state information which may include floor information,
configuration information, etc.
9.4 Audio/Video Conferencing / Media- and Shared Workspace Agent

27 / 92
Media Agents:
– Are separated from the session manager
– Each type of media owns its personal media agent
– Each Media Agent performs its own control mechanism over the particular
medium, such as
· Mute / unmute
· Change video quality
· Start / stop sending
Shared Workspace Agent: Transmits shared objects among the shared

applications, such as
– Telepointer coordinates
– Graphical or textual objects
9.4 Audio/Video Conferencing / Session Control Architecture

28 / 92
Session Manager
Conference Membership
Control Control
Floor Session Control Protocol
Control
Configuration Media
Control Control
Shared Reliable Transport Protocol

Whiteboard
Workspace
Agent Real-Time Protocol
Agent Video
Agent Real-Time Protocol
Media Audio
Agent Agent Sensory
Real-Time Protocol
Data
Agent
9.4 Audio/Video Conferencing / Session Control Architecture

29 / 92
Each session is described through its session state, e.g.:

– start time of session
– policies associated with a session
– session name
The session state information is either
– Private (e.g.: local resources) or
– Public and shared among all sessions participants
Session states are changed during establishment or modification of a session:
– Session manager negotiates, agrees and sets the logical state of its own session
– It negotiates, agrees and sets billing policy with other session managers
· Further, it permits “publishing“ a session, allowing others to join a session
9.4 Audio/Video Conferencing / Further Controls

30 / 92
Tasks of the Floor Control:

– Provides access to the shared workspace
– Maintains data consistency
Controls the level of simultanity and granularity for access control, fine
granularity
– for simultaneous use
– for number locks
Example for a simple floor control: floor-passing mechanism
– At any time only one participant has the floor (token principle)
– The floor is handed off to another participant when requested
– To obtain the floor; the participant must explicity take action to signal a floor
change
With real-time audio the floor control promotes turn-takings
Floor control for real-time audio is often used to control bandwidth usage
9.4 Audio/Video Conferencing / Further Controls

31 / 92
Conference Control:
– For a comparison between centralized and distributed replicated conferencing
control please see further literature.
Media Control:
– Includes mainly a functionally for the synchronization of media streams.
Configuration Control:
– Includes a control of media quality, QoS handling, resource availability and
other systems components to provide a session according to users requirements.
Membership Control:
– Includes services for invitation to and registration into a session as well as
modification of the membershipship during a session.

32 / 92
Multimedia applications demand high requirements on network protocols:
1. High data throughput

– deliver as much data as possible
2. Fast data forwarding
– deliver data as fast as possible
3. Service guarantees
– deliver data with the negotiated policies
4. Multicasting
– 1:n and n:m point communication

33 / 92
Most transport protocols are designed for unreliable and “relative slow“
networks.
Modern highspeed networks, such as ATM, need new transport protocols that
consider the properties of this new network technology.
Error rate 10-14
Fiber
wireless
Error rate 10-14

34 / 92
1. Data throughput:
– Audio and video data resemble a stream-like behavior
– Even in compressed mode, they demand high data throughput (16 kbit/s for
compressed Audio, 64 kbit/s for original PCM-audio, 2 Mbit/s for MPEG-coded
video)
– In a workstation or network several of those streams may exist concurrently
– Telephone services or video conferencing demand real-time computing of the
data streams
This requires high performance workstations which are able to compute several
multimedia streams simultaneously and can transmit the packets in appropriate
speed to the network interface.

35 / 92
data rate peak rate
average rate
sustainable rate
I-frame time
If allocated capacity is too low at a given time:

1. Maybe buffering will help
2. Graceful degradation of quality; e.g.
· skip on more B-frames in an MPEG stream
· reduce number of colours
· reduce number of frames

36 / 92
2. Fast data forwarding:

– End-to-end delay is limiting in the end by the speed of light but also by the
intermediate network nodes (router)
– Different applications require data movement ranging from normal error free
data transmission to time-constrain traffic
– Real time communication demands low end-to-end delays - typically max. 200
msec - and low jitter - variation of packet-inter-arrival-time.
– Fast data delivering forces intelligent acknowledgment mechanisms, because
send-and-wait strategies are not suitable.
– Error free data delivering and real time communication requirements are
difficult to grant at the same time, because error free data delivering forces data
retransmission which will lead the high delays and large jitters!
Í This requires fast delivering from the network and intelligent protocols which
transmit only necessary traffic!

37 / 92
3. Service guarantees:
– Service guarantees are important for the acceptance of distributed multimedia
applications
– Distributed multimedia applications need guarantees, such as
throughput ≥ minvalue, delay ≤ maxvalue and jitter ≤ maxjitter
– To achieve service guarantees, resource management must be used - without
this in end-systems and switches/routers, multimedia systems cannot provide
reliable QoS to their users because transmission over unreserved resources may
lead to dropped or delayed packets
4. Multicasting:
– Multicasting is important for multimedia-distributed appications in terms of
sharing resources like the network bandwidth
– Many multimedia applications, such as video conferencing, have multicasting
characteristics

38 / 92
Multimedia applications generate and consume huge amount of data and lay
high claims to the underlying infrastructure and communication architecture:
– Data should be copied directly from adapter to adapter to reduce copy overhead e.g.:
from the video board to the network interface by using direct memory access (DMA).
With DMA technique, the application itself never really touches the data, it only sets the
correct switches for the data flow by connecting sources to sinks.
– The data movement involved by the layered structure of the protocols form a bottleneck,
hence other mechanisms must be found.
– For error-recovery some protocols use retransmission techniques which impose
requirements on buffer space for queues at the expanse of larger end-to-end delays
– The synchronous behavior of most multimedia traffic streams must be mapped on the
asynchronous transfer mode of the underlying networks
Are the “old“ transport protocols like TCP and UDP suitable for multimedia
transmission and which new protocols do exist?
9.6 Quality of Service / Resource Management

39 / 92
Endsystem Endsystem
Application Level Application Level Resource Application Level

Management Protocol
System Level System Level Resource System Level

Management Protocol
Switch
MM Network Network Level MM Network

Device Level Device Level
Resource Management
Resource Management
Level Level
Resource
Management
Network Network
9.6 Quality of Service / Resource Management

40 / 92
Main goal of Resource Management:

– providing guaranteed delivery of multimedia data
Í three main actions:
– reserve and allocate resources (end-to-end) during establishment
– provide resource according to QoS specification
– adapt to resource changes during data processing
Relations between QoS and resources:

– QoS paramenters ⇔ resource quantity allocated to the service and resource
scheduling Í Resource Management handles different mappings between QoS
parameters and their corresponding resources
9.6 Quality of Service / QoS Negotiation

41 / 92
Peer-to-Peer Bilateral Peer-to-Peer-Negotiation:

Caller Callee
Negotiation – takes place between two service users
– service provider is not allowed to modify
Requested proposed values
QoS Value
– Callee may modify proposed QoS values
Changed
QoS Value
Bilateral Layer-to-Layer-Negotiation:
Connect Connect – takes place between service user and service
Connect Request Indication Connect provider
Confirm Response
– Callee may modify proposed QoS values
Unilateral Negotiaiton:
t4 t1 t2 t3 – Service user or service provider is not allowed
to modify proposed values
Service Provider – take it or leave it
9.6 Quality of Service / QoS Negotiations

42 / 92
Peer-to-Peer Triangular Negotiation for a Bounded Target:

Caller Callee
Negotiation QoS represented through two bounds:
Target – target (average value)
Available – lowest quality available (minimal value)
QoS Value
Goal: negotiate target value
Selected Selected
QoS Value
QoS Value QoS Value Triangular Negotiation for Contractual Value:
Lowest Quality
QoS represented through two bounds:
Acceptable – minimal requested value
– bound of strengthening
Connect Connect Connect Connect
Confirm Request Indication Response Goal: agree on a contractual value “Triangular“:
t4 t1 t2 t3
Calling user Called User
Service Provider
Provider
9.6 Quality of Service / QoS Negotiations

43 / 92
QoS negotiation are provided by different Reservation Protocols, e.g.

ST-II: (Stream Protocol II)
QoS parameters related to throughput are negotiated with triangular negotiation
for a bounded target
QoS parameters related to delay are not negotiated
– calling user specifics maximum transit delay
– each ST-agent estimate the average transit delay
– provider presents total estimated transit dealy in the indication
– called user decides if the (expected) delay is sufficient
QoS parameters related to error control are not negotiated
RSVP (Reservation Protocol), RCAP:
QoS parameters are negotiated with triangular negotiation
9.6 Quality of Service / Translation

44 / 92
Different components require different QoS parameters

Í translation during connection establishment between layers:
Human Interface - Application QoS
– tuning service: provides Graphical User Interface (GUI) for input/output of
application QoS
Application QoS - System QoS
– e.g. translates video frame size to transport packet size
– may be connected with segmentation/reassembly functions
System QoS - Network QoS
– maps system QoS (e.g. transport packet end-to-end delay) to the network QoS
parameters (e.g. end-to-end delay of cells in ATM)
9.6 Quality of Service / Translation & Scaling

45 / 92
Translation is bidirectional Í causes problems:

Example: video rate and video frame size determine the throughput for the
network - if the throughput is relaxed, it may translate into either lowering the
quality of the image (frame size) or the frame rate
Scaling: subsample a data stream to present a fraction of its original contents

– transparent scaling: can be aplied independently from upper protocol layers, e.g.
dropping some identifiable portions of data stream
– non-transparent scaling: requires interactions of the transport system with upper
layers, e.g. modification of some coding algorithm parameters or recording in a
different format
9.6 Quality of Service / Scaling

46 / 92
Scaling can be applied to audio and video data:

transparent scaling is difficult for audio, because presenting a fraction is easily
noticed by the human listener Í non-transparent scaling, e.g. changing the
sample rate
For video, scaling method depends on the underlying compression methods:

– Temporal scaling reduces number of transmitted video frames, best suited for
video with individual self-contained frames
– Spatial scaling reduces number of pixels of each image
– Frequency scaling reduces te number of DCT coefficients in coding algorithm
– Amplitude scaling reduces the color depth by introducing a coarser quantization
of the DCT coefficients
– Color space scaling, e.g. switching from color to grey-scale presentation
9.7 Resource Admission Control / Reservation Model

47 / 92
Admission Control checks resources along the network path for availability
Three reservation models:
– Single Server/Single Receiver (e.g. RCAP)
– Single Server/Multiple Receiver (e.g. ST-II)
– Multiple Server/Multiple Receiver (e.g. RSVP)
Two reservation directions:
– sender-oriented (e.g. ST-II)
– receiver-oriented (e.g. RSVP)
Reservations are made:
– immediate
– in advance
9.7 Resource Admission Control / Example: RCAP in Tenet Suite

48 / 92
RCAP is a Single Server/single Receiver sender-oriented reservation protocol with

immediate allocation in one round trip
Sender Node 1 Node n Receiver
ADM_ Server
R EQ Tests ...
ADM_ Server
REQ
Tests
ADM_R Destination
EQ Tests
Adjust
Resources DM_ CONF
A
...
Adjust M _ C ONF
AD
Resources
ON F
ADM_C
Data

49 / 92
Server Tests allocate resources by

– pessimistic approach: worst case allocation, e.g. alocating bandwidth according
to peak rate
– optimistic approach: allocates resource to an average workload, e.g. allocating
bandwidth according to average rate over a specific time
Destination Tests in receiver computes local constraints of the intermediate
nodes
– Adjust resources at way back to the sender
Server Tests:
– Deterministic Test: deterministic bandwidth test for guaranteed services
– Statistical Test: statistical bandwidth test for guaranteed services
– Delay Bound Computation: computes minimalnode dealy, depends on
scheduling strategy
– Buffer Test: allocates buffer and computes maximum node delay according to
reserved buffer

50 / 92
Destination Test:
– D-Test: tests if minimal delay is less than maximal specified delay
– W-Computation: computes all local probabilities of packet loss due to buffer
overflow
– Z-Test: computes alllocal probabilities of packet loss due to delay violation
– Delay Computation: computes local node delays
– J-Test: necessary for rate controllled schedulers - computes deadline to
guarantee jitter
Bandwidth tests can be made pessimistic (peak rate allocation) or optimistic
(maximum average allocation)
Several improvements of the Tenet approach exist (including predictive
service)
9.7 Resource Admission Control

51 / 92
Network
User 1
User 4
Requirements
(Bandwidth, Delay, ...) Router
Jitter User 3
User 2
Admission control: Can the user requirement be accepted?

Traffic shaping: How to avoid that the network is overloaded?
Scheduling strategies in the routers:
How to handel different connections such that deadlines are satisfied.
9.8 Resource Management / Scheduling

52 / 92
Existing scheduling strategies (e.g. FIFO) are not suitable for QoS based scheduling
because strict performance guarantees are not provided
There are different schedulers providing these guarantees:
– Weighted Fair Queueing
– Virtual Clock
Router
– Delay Earliest Due Date (D-EDD) inputs outputs
– Jitter Earliest Due Date (J-EDD) Queues
– Stop-and-Go Buffers
– Rate Controlled Static Priority
how to do a scheduling?
Differences to simple scheduling strategies:
– more complex queueing
– often time-stamped
– more complex computation e.g. of deadlines
– non-workconserving (workconserving = server serves whenever there is something to do)
9.8 Resource Management / Traffic Shaping

53 / 92
Why traffic Shaping?

– description of the flow´s characteristics to the network provider (admission
control)
– network provider can determine if the flow is allowed to send (policing)
– network provider can monitor the traffic of the flow (monitoring)
Requirements to shaping schemes:
– ability to describe a wide range of behaviors
– making it easy to describe traffic patterns from the shaping rules Traffic
shaping
– shaping rules should be easy to police
Traffic Shaping Schemes may be characterized by e.g.
– allowed peak rate,
– maximum burst size or
– average rate over a determined interval Network
These parameters may be combined
9.8 Resource Management / Traffic Shaping - Leaky Bucket

54 / 92
Data (possibly bursty)
Token data is transmitted uniformly with rate ρ Í

Bucket with
transfer is smoothed
β finite capacity
bursts bigger than β are discarded
Íbounded delay
easy to implement (FIFO + timer)
ρ
Í Leaky Bucket generates a more steady
steady flow stream instead of bursty traffic
Network
9.8 Resource Management / Traffic Shaping - Token Bucket

55 / 92
data may be sent if tokens are available in

the bucket
ρ
three possible scenarios: consider trying to
send a packet of size b tokens (b < β):
– token bucket full Í packet is sent and b
Token
tokens are removed
Bucket – token bucket empty Í wait for b tokens to
β
drop into the bucket
– token bucket partially full Í if there are
B ≥ b in the bucket, packet is sent
immediatly, if B < b packet has to wait for
Data the missing (b-B) tokens
ÍToken Bucket permits burstiness but
bounds it
9.8 Resource Management / Traffic Shaping - Token Bucket with Leaky Bucket

56 / 92
ρ Token Bucket permits burstiness which is

smoothed by a subsequent leaky bucket
(C > ρ) both buckets have a size β
Token
Token Í bursty traffic is permitted but the
β Bucket scheme regulate it
maximum transmission rate C

long term average rate bounded by ρ (<C)
Data β C
Leaky Bucket
9.8 Resource Management / Scheduling inside the Network

57 / 92
How can we guarantee that the system keeps its promises for the connections
even if traffic shaping rules are violated?
First startegy: Nagle´s algorithm
Router in a network keeps a record and queue for every connection and serves
the connections in a packet-wise round-robin startegy
Advantage: Connections which offer too many packets will be “punished“
Disadvantage:
– a very long packet will be “dangerous“ for others
– inconvenient for some traffic patterns (if a packet arrives
just after the server was there then the waiting time could
become substantial)
– costly and difficult to implement connection router connection
1 k
Thus some modifications were proposed

58 / 92
connections router
connection router connection

1 k
1. “Nagle“:
– a seperate input queue (of packets) per connection
– round robin service (if n connections are active then each one can send one
packet, if available)
Advantage:
– will behaving connections (and only these!) will see overload in their queues
(isolation phenomenon)
Limitation:
– the algorithm of packet length, i.e. connection with big packets get far better
service than connections with small packets
– algorithm is sensitive to arrival patterns:
If a packet arrives in an empty queue just after “server was here“ then it may
have to wait very long

59 / 92
2. “Bit by Bit Round Robin“ (fair queueing)

– one queue per connection (as before)
– but: bitwise round robin (instead as of packet wise Round Robin)
(this is only a theoretical scheme)
3. “Modified fair queueing“ (by Demas, Kerchav and Schenker)

– packetwise service
– order the packet transmissions according to the time by which their last bit
would be trasnmitted if strategy (2.) would have been applied
– a new packet will be scheduled after all the old packets

60 / 92
3. is similar to 2. but not identical.

Example:
time
arrival of packet arrival of packet p2 = b1 b2 b3

p1 = a1 a2 ... a20 (p1 and p2 from different connections)
“Bit by Bit“ :
a1.. a5 a6 a7 ..... a20 Start time of p2 is delayed by “modified“
b1 b2 b3 p1 leaves (when compared to “bit-by-bit“).
p2 starts p2 leaves
Maximum delay which is possible:
p2 starts Maximum packet size allowed by the
“Modified“ : p2 leaves
network
a1.. ....................... a20 b1 b2 b3
p1 leaves

61 / 92
4. “Weighted fair queueing“

Fair queueing gives equal fraction of bandwidth per connection (1/n of total
bandwidth if n connection are active).
This may not be reasonable if (for example) :
– connection1 is between supercomputers
– connection 2 is between workstations
In this case we would like to give connection 1 more bandwidth.
4.1 Divide the bandwidth into m-bit cycles (m > n = number of active connections)
Allocate the m-n “extra bits“ to the connections with higher need
4.2 Each connection i gets a weighted service rate gi from the router (gi must be
greater than ρi if the outside traffic shaping is by token bucket with leaky bucket
rate control; i.e. if ρi is the filling rate of the token bucket for connection i)
9.8 Resource Management / Scheduling - Weighted Fair Queueing

62 / 92
Queue per connection

(b1, ρ1)
Round Robin strategy Í fair
(b2, ρ2) queueing delay bound of connection i
i
β i (hi − 1) ⋅ li h la
(b3, ρ3) Di ≤ + + ∑ , where
gi gi m =1 rm
(b4, ρ4) – i denotes the flow
ri – Di denotes the delay flow i
(b5, ρ5)
– βi denotes the token bucket size
(b6, ρ6) – gi denotes the weighted flow rate (gi≥ρi)
– li denotes the maximum packet size of flow i
(b7, ρ7) ⋅ – la denotes the maximum packet size of the network
⋅
– hi denotes the total number of hops of flow i
(b8, ρ8)
– rm denotes the outbound bandwidth at hop m

63 / 92
i
Proof of delay bound: β i (hi − 1) ⋅ li h la
Di ≤ + +∑
gi gi m =1 rm
(*) (**) (***)
(*) delay if each other router in the network is fully loaded; in this case the
token bucket size βi is served with a rate gi (gi≥ρi). This lasts βi/ρi seconds.
(**) somewhat mysterious term “delay due to packetisation effects“
(***) A packet may be delayed (in each hop) by la bit times (la = maximum
packet length). Since hop m serves rate rm this needs la/rm seconds.

64 / 92
Example:
conn. 1 r1 conn. 1 r2 r3
conn. 1
conn. 2 conn. 2
Define:
– the link bandwidth r1 = r2 = r3 = 155 Mbit/s (ATM speed)
– the maximum packet size of each flow and of the network l1 = l2 = la = 424 Bit
(ATM cell)
– the weighted flow rate g1 = ρ1 = 100 Mbit/s and g2 = ρ2 = 50 Mbit/s
– the token bucket size β1 = β2 = 1 Mbit
– flow 1 is transmitted over 3 hops (h1 = 3), flow 2 over 2 hops (h2 = 2)
The delay bounds are
β1 (h1 − 1) ⋅ l1 la β 2 (h2 − 1) ⋅ l2 la
D1 ≤ + + 3 ⋅ = 10,0166 ms D2 ≤ + + 2 ⋅ = 20,01395 ms
g1 g1 r1 g2 g2 r1
dominating term (in this example!)

65 / 92
Implementation Issues:
Queueing:
– Per-Connection-Queueing: needs more complex buffer management
– Granularity of Queueing: depends on network, e.g. cell in ATM, byte in
packetswitched networks, bits in our example
Scheduling:
– Granularity or weights: unit of the weighted flow gi?
Í Depends on granularity of queueing!
– Non-workconserving: needs timer control if the bandwidth is not completely
allocated
Advantage: analytic delay bounds!
Disadvantage: more complex implementation
9.8 Resource Management / Scheduling - Delay Earliest Due Date (EDD)

66 / 92
Incoming packets are timestamped

deadline is computed according to
– average rate or
⋅ ⋅ – peak rate
⋅ ⋅
packet is inserted in calendar (time ordered)
queue
Scheduler serves packet with deadline same as
FIFO-ordered time ordered actual serving time Í non-workconserving
Í D-EDD provides deterministic delay
reordering
bound with granularity bounded by the timer
packet with shortest granularity!
deadline is first in
the queue
9.8 Resource Management / Scheduling - Rate Controlled Servers

67 / 92
Channel 1
To renew the traffic characteristics in every
node of the network rate controllers are added
Rate Controller may regulate
Channel 2 – delay jitter (variation of delay)
– rate jitter (variation of rate)
Packets are hold by a defined eligibility time
before scheduled by the bounded delay server
Ítimestamp ordering
bounded delay server Íadditional complexity
Ílocal delays can be computed according to
Channel n the traffic characteristics at the entrance of
rate the network
controllers Íbuffer space required is distributed to the
nodes along the network path
9.8 Resource Management / Scheduling - Stop and Go

68 / 92
Consider the traffics consisting of frames with T bits (the transmission of a
frame needs T bit times). A frame contains several packets (“Frame“ =
"Container“).
The router manages input frames and output frames.
1. A packet of a frame cannot be forwarded until ist entire frame has been
received.
2. “Stop and Go“: The packet will be forwarded in the next output frame which
starts transmission after the input frame has fully arrived.


69 / 92
Minimum delay of a router:

T bit times (necessary for reception of the frame)
Maximum delay of a router:
2T bit times (if the input frame arrives just after an output frame has started)
T
Input frames
Output frames
(min. delay)
maximum delay
h hops Í delay bounds h⋅T ≤ D ≤ 2h ⋅T


70 / 92
Jitter δ for “Stop and Go“:

The only possible jitter is due to different position of a packet in input frame
versus output frame
The “displacement“ will be in the interval
(-T : T)
If the frame enters the network at the end of a frame but leaves it at the
beginning of a frame
9.8 Resource Management / Scheduling - Rate Controlled Static Priority

71 / 92
m rate n FCFS
controllers servers
Channel 1
Each channel has ist own rate controller
delayed packet is inserted in FCFS queues
Channel 2
FCFS queues are served with priorities (non-
preemptive)
. . n delay bounds are supported - computation
. . depends on traffic specification - delay bounds
. . for TENET traffic specification exists (Zhang)
scheduler is non-workconserving first
Channel m
implementation in hardware exists
⋅
⋅
9.8 Resource Management / Scheduling - Jitter Earliest Due Date

72 / 92
m rate
controllers
each channel has its own rate controller
Channel 1
difference between deadline and actual finishing
time at current server is carried in the packet
Channel 2 above described difference is the time the packet
is hold back in the regulator of the following
. . node (i.e. next hop compensates fitter of
. . previous hop)
. . deadline in time-ordered queue is computed
⋅ similar to D-EDD
Channel m ⋅ ÍJ-EDD provide bounds for local delay
and local delay jitter
⋅ Íneeds additional timestamp field in
⋅ packet header
A hop has : a queueing budget b Transmission of a packet may be started at at time

a jitter bound j in the interval [b-j : b]
9.8 Resource Management / Scheduling - Jitter Earliest Due Date

73 / 92
If the packet is started at time b-τ (i.e. τ seconds early) then in the next hop
τ will be added to the budget of the next hop, i.e. the transmission in the next
hop will be scheduled in the interval
[b´-j : b´] where b´= τ + b.
Í Global jitter is limited to x ∈ [o:j].
Technical problem:
The actual value τ has to be filled in into the packet´s header.

9.8 Resource Management / End-to-End Error Control

74 / 92
Reliability of multimedia streams is necessary because

– Decompression: most audio and video compression schemes cannot tolerate loss
of data
– Human perception: Loss of e.g. digital audio is detected by a human ear very
quickly Í lower acceptance of multimedia systems
– Data integrity: E.g. in a recording application, one cannot recover from an error
in the first recording, fortunately, recording applications have often less
stringent real-time requirements for the receiver
End-to-End error control consists of

– error detection
– error correction
9.8 Resource Management / End-to-End Error Control - Error Detection

75 / 92
Problem: isolate the errors, e.g. some wrong color in a frame may not matter
(hardly visible to human user) but wrong frame boundaries cannot be recovered
Example: within an MPEG-2 video it is important not to loose the I-Frames
(contains structural informations), P- and B-Frames losses are tolerated
Í structural information needs to be protected, not always content!
Íexisting error detection mechanisms (checksumming, sequencing) must be
extended
Example: lateness concept. PDUs that arrive too late are useless for the
application (e.g. video frame)
ÍPDUs are periodically time-stamped
Íerror detection can start at the time-stamped PDUs
Írequires synchronized system clock at sender and receiver (e.g. Network Time
Protocol)
9.8 Resource Management / End-to-End Error Control - Error Correction

76 / 92
Traditional method for reliability provision:

– Retransmission
Not suitable for multimedia communication because:

– explicit acknowledgement increases the amount of data to be stored in the
sender, e.g. video data
– window-based flow control may force the sender to suspend the (continuous)
data stream like video
– retransmitted data might be received too late to be consumed in time
– traditional mechanisms do not scale to multiple-target communication like
multicast scenarios - they are typically designed for point-to-point
communication

77 / 92
Currently discussed schemes for multimedia communication: Go-Back-n Retransmission
S R S R
1 1
2 2
3 3
4 4
5 Receiver starts the Timer 5
6 6
7 7
8 Timer ends and the receiver 4 After receiving the
4 notice the missing of packet 4 5 packet 5, the receiver
5 6 notice the missing of
6 These packets are lost 7 packet 4.
7 8
8 9
9 All lost packets must 10
be retransmitted
t t
Timer controlled Usage of special
may lead to gap introduction and network properties like
violation of throughput parameters sequence ordering in ATM

78 / 92
Currently discussed schemes for multimedia communication: Selective Retransmission
S R S R
1 1
2 2
3 3
4 4
5 Receiver starts the Timer 5
6 6
7 7
8 Timer ends and the receiver
4 After receiving the
9 8 packet 5, the receiver
4 notice the missing of packet 4 9 notice the missing of
10 10 packet 4.
11 The packets are not lost 11
12 12
13 Only the packet 4 has to 13
be retransmit
t t
Timer controlled Usage of special network properties like
sequence ordering in ATM
implentation more complicated more buffer needs


79 / 92
Partially Reliable Streams:

– number of retransmitted packets are limited and calculated from the timing
constraints of the call setup
Forward Error Correction (FEC):

– additional information is added to the data Ílow end-to-end delay and no
exclusive buffering. FEC works only for error detection/correction within
packets but not for packet loss
Priority Channel Coding:

– multiple data streams are distinguished by different priorities, during congestion
periods the network is more likely to discard low-priority packets. For example,
I-Frames in MPEG-2 are transmitted with high, B- and P-Frames with low
priority

80 / 92
Error control/correction schemes are divided in
partial retransmission schemes preventive mechanisms

Go-Back-N Forward Error Correction (FEC)
Selective Retransmission Priority Channel Coding
Partially Reliable Streams
Partial retransmission schemes lack the possibility of introducing a

discontinuity or large end-to-end delays with large buffers Í preventive
schemes should be used
9.8 Resource Management / Forward Error Correction - CRC

81 / 92
Cyclic Redundancy Checks (CRC) are used to protect packets against bit errors.
Given m data bits (w1, ..., wm).
m
Define U ( x) = ∑ wi ⋅ x i −1
i =1
and the generator polynomial G(x) of degree k according to

k
G ( x ) = ∑ g i ⋅ x i g i ∈ {0,1}∀ i; g 0 = g k = 1
i=0
Using the modulo-2 arithmetic compute
 x k ⋅U ( x)
( ) → x k
R ( x) = Re m  ⋅ U ( x) = P ( x) ⋅ G ( x) + R ( x)
 G ( x) 

82 / 92
The rest polynomial R(x) is of degree < k and is appended at the m data bits at
transfer Í xk ⋅ U(x) + R(x) is trasnmitted (xk shifts the data bits to provide bits
for the remainder)
The receiver receives xk ⋅ U(x) + R(x) + e(x) (e(x) is the error polynomial) and
computes
 x k ⋅U ( x) − R( x) + e( x)   P( x) ⋅ G( x) e( x)   e( x) 
V ( x) = Re m  = Re m +  = Re m 
 G ( x)   G ( x) G ( x)   G ( x) 
If V(x) ≠0 Í 1. ei > 0 in the data part Í serious trasnmission error
2. ei > 0 in the remainder part Í can´t be distinguished from
serious errors
If V(x) = 0 an undetectable error may be occured if e(x)=a(x)G(x) (rather
unlikely event)

83 / 92
Example:
(w1, ..., w8) = (1, 1, 0, 1, 0, 1, 1, 1) Í U(x) = x7 + x6 + x4 + x2 + x1 + 1
Define G(x) = x5 + x3 + 1
Í R(x) = x4 + x3 + x
Í (11010111 11010) is transmitted
data CRC
Receiver gets (11000111 11010)
Thus e(x) = x9 error!
ÍV(x) ≠0 Íserious transmission error!

Error detection is often realized in hardware (e.g. ATM).
Error correction with CRC is more complicated (Maximum-Likelihood method).
Example: ATM headers are protected with G(x) = x8 + x2 + x + 1 (can be used to
correct a single error!)
9.8 Resource Management / Resource Monitoring

84 / 92
Resource Monitoring is an important part of resource management in networks
and et end-points!
– Monitoring in networks adds overhead Ímost of the monitoring variables
should be optional and monitoring should be able to turn on/off
– Monitoring in end-systems includes supervisor function to continuously monitor
the processed QoS parameters (e.g. controlling a compression component)
Ídesign and implementation is non-trivial

9.8 Resource Management / Resource Monitoring

85 / 92
Resource Administration Protocols provide communication about resources

between resource managers at intermediate nodes and end-systems and can be
implemented as
– part of network management protocols like CMIS/CMIP (Common
Management Information Service and Protocols) and SNMP (Simple Network
Management Protocol)
– separate resource management protocols like RCAP in the Tenet protocol stack
Administration Protocol may be part of the transmission protocol like ST-II or

like RCAP which is decoupled from RTIP (Real Time Internet Protocol)
9.8 Resource Management / Resource Adaption

86 / 92
Dynamically changing the network capacity of each session needs support of dynamic
change of QoS parameters
Resource adaption requires
– notification and renegotiation of QoS parameters
– adaptive resource schemes
Renegotiation request can come from either
– the user (e.g. change QoS like video rate) who invokes the resource administration
protocol to check the resource if network adaption is required,
– the host system (e.g.due to workstation overload) which invokes e.g. a notification of
QoS degradation to a misbehaved user/application. Network QoS renegotiation may also
be invoked by the resource administration protocol
– the network (due to overload or congestion) which invokes a notification to the host
reporting that the allocation of resources must change
· network can adapt to overload Í network notifies the host because some degradation may
occur during modification of resources Í this may interrupt the media flow Í host must react
· network cannot adapt to overload Í host must adapt to overload
9.8 Resource Management / Resource Adaption - Network Adaption

87 / 92
Proper balancing of network load is desirable and necessary to

– increase network availability
– reclaim resources by network administrators
– reduce the impact of unscheduled, run-time maintenance on clients with
guaranteed services
Implementing load balancing policy requires
– routing, performance monitoring (detect load changes)
– dynamic re-routing
– load balancing control to make a decision to re-route a channel
Dynamic re-routing mechanism is done by establishing a new channel (shadow
channel) via a new route, sending data on this new channel and tearing down
the old channel after the maximum end-to-end delay.
9.8 Resource Management / Resource Adaption - Source Adaption

88 / 92
Adaption of the source rate according to the current network resources by

– evolution of the system state over the time: state of the complete route is used to
compute the sending rate of the source
· state information may be appended periodically to data packets and is sent back to
the source. Intermediate nodes update the information if the switch service rate is
lower than the proposed rate
· feedback is sent with separate control messages to the receiver and back to the source
– Rate control using network feedback: changes in the traffic conditions are
detected by feedback from the network
· explicit: information about the traffic load or buffer space from the network
· implicit: information about packet losses and delay from acknowledgements
– Traffic shaping at source: smoothing traffic at the source Ítraffic is less bursty
– Hierarchical coding: algorithms producing two or more types of cells describing
same block of pixels with different degree of detail Ícodecs are more complex,
use greater amount of bandwidth
9.9 Architecture / Issues

89 / 92
Endpoint architectures need to incorporate components like

– resource managers which include
· translation services (translate QoS)
· admission control (checks for availability of resources)
· resource reservation
· resource management
– service agents
– Management Information Bases (MIBs) with QoS specification
Router/Switch architecture need to employ
– resource managers which include
· packet classifier
· packet scheduler
· admission control
– network management
– Management Information Bases
9.9 Architecture / Examples

90 / 92
Lancaster´s QoS-Architecture incorporates notions of flow, service contract and

flow management over high-performance ATM-based networks
Heidelberg Transport System (HeiTS) provides continuous media exchange

with QoS guarantees (delay, jitter, throughput, reliability) based on ST-II,
resource management and real-time mechanisms via multicast
Tenet Protocol Suite with RCAP (real-time Channel Administration Protocol),

RTIP (real-time IP), RMTP (Real-time Message Transport Protocol) and
CMTP (Continuous Media Transport Protocol) provides QoS negotiation,
resource administration and real-time media transport
9.9 Architecture / Examples

91 / 92
OSI architecture provides QoS in network layer and enhancements in transport

layer. OSI95 considers QoS specification and negotiation in transport protocols
RSVP, based on IP, provides resource reservation
UPenn´s end-point architecture (OMEGA Architecture) provides QoS handling

and management at applications and transport subsystems
Native Mode ATM Protocol provides ATM network QoS guarantees

9.9 Trends in Transport Systems

92 / 92
Two directions:
– special-purpose protocols like TCP (reliable data transfer), UDP (unreliable data
transfer), RTP (audio/video transfer) on top of IP (internet paradigm)
– general-purpose protocols like XTP to provide a general set of services
Í application-tailored protocols: customized for specific types of services
(transferring voice, video, text, image)
Í transport subsytems move toward a provision of service classes like
guaranteed services, best effort
Í within these classes, services are customized through QoS specification
Í services are selected and customized toward applications

Traffic Shaping PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Traffic Shaping PDF

Hochgeladen von

Copyright:

Verfügbare Formate

9.

Multimedia Communication Systems

Multimedia Kommunikation SS‘99

9.1 Overview 9.7 Resource Admission Control

Multimedia Kommunikation SS‘99

In this chapter we discuss issues related to multimedia communication systems

applictaion subsystem, which is responsible for management 4 Transp.

Multimedia Kommunikation SS‘99

Some multimedia applications:

Multimedia Kommunikation SS‘99

Cooperative Computing is generally known as Computer-Supported-

Tools for cooperative computing:

Multimedia Kommunikation SS‘99

Computer-Supported cooperation may be categorized according to the

Multimedia Kommunikation SS‘99

Multimedia Kommunikation SS‘99

Group Communication Agent

Multimedia Kommunikation SS‘99

Multimedia Kommunikation SS‘99

· Directory server (for group rendezvous services)

· Application sharing server

· Multimedia server (for intermedia synchronization)

Multimedia Kommunikation SS‘99

User Presentation Protocols:

Group Work Management Protocols:

Multimedia Kommunikation SS‘99

Setting up of group and delivering information about groups and meetings

Multimedia Kommunikation SS‘99

Used in tele-conferencing for cooperative document editing and software

Multimedia Kommunikation SS‘99

Multimedia Kommunikation SS‘99

Shared Application Ì bottleneck

Shared Application Shared Application

Multimedia Kommunikation SS‘99

Consistency Maintenance of Shared Documents, e.g.

Floor Passing Control:

Multimedia Kommunikation SS‘99

CSCW CSCW CSCW

Input Input Input

Merged Merged Merged

Display Display Display

Multimedia Kommunikation SS‘99

CSCW (computer supported cooperative work)

control component checks wether the active site is floor holder

Multimedia Kommunikation SS‘99

Management service which controls simultaneous face-to-face communictaion

Audio (true full-duplex high-quality communictaion with echo cancellation):

Multimedia Kommunikation SS‘99

Centralized or distributed control

Multimedia Kommunikation SS‘99

State Information of the Conference, e.g.:

Multimedia Kommunikation SS‘99

Multimedia Kommunikation SS‘99

Establishment of a Conference with Distributed Control:

Multimedia Kommunikation SS‘99

Centralized Conference Control:

Multimedia Kommunikation SS‘99

Multimedia Kommunikation SS‘99

– Membership control management (e.g.: participant authentication)

– Control management (for shared workspace, such as floor control)

– Media control management (e.g.: communication among media agents)

– Configuration management (such as exchange of interrelated QoS parameters or

selection of appropriate services according to QoS)