Transcript Brian`s Slides

QoS Requirements of
Multimedia Applications
Brett Berliner
Brian Clark
Albert Hartono
Introduction

What does QoS mean?



Quality of Service
probability of the network/protocol meeting a given traffic
contract.
Who negotiates this contract?



SLA (Service Level Agreement)
Usually done by prioritizing traffic
Sender and receiver



Mutual agreement
Improves reliability of contract by having both ends agree
Like with any contract negotiation is the key
Introduction Con’t

Generally not used for most traffic in internet


Usually things are not dependant on time domain
Web browsing, e-mail, ftp, etc.


Mainly used for multimedia applications



Time is of the essence
Video, voice, games, etc.
Always a trade-off



TCP takes care of this for us
Higher QoS (higher quality) -> More resources
Users of SLA must be fair and honest
Five basic parameters
Dropped Packets



A router must drop an incoming packet because
buffer is full
No perfect solution to this problem
Some, none, or all might get dropped


Impossible to determine in advance
How to recover?

Receiver must request packets to be sent again
Causes severe delay
 Sometimes not worth it to request packet again

Delay

Queuing




Processing Delay (usually caused by software)



At different layers, data must be processed
Usually in microseconds
Propagation Delay



Time spent waiting in a queue at a router
Depends on congestion in the network
Usually in milliseconds
Time for data to travel from A->B
Depends on distance, usually in milliseconds
Transmission Delay

Depends on bandwidth and length of message, usually in microseconds
Jitter


A lack of synchronization
Caused by different delays in packets

Result of packets taking different routes


Directly related to congestion
Extreme jitter can lead to out-of-order delivery

Packets need to be re-ordered at receiver

Sometimes this is impossible due to time constraints
Error

Packets do not always arrive in the exact state
they were sent out in
Can be misdirected (sent to wrong destination)
 Can get combined together by accident
 Can have bit(s) flipped.



Receiver must request information to be sent
again
Many times this is not practical for multimedia
applications
Bandwidth


Amount of data that can be sent over a
connection in a given amount of time
Commonly measured in bits/second


kbps or mbps instead
Sometimes a given connection is simply
physically unable to fulfill a SLA

Imagine trying to stream HDTV quality video over a
14.4 kbps modem
What Happens When QoS Fails?

VoIP Example:

Delays followed by effect




< 100 – 150 ms: Delay is not detectable by humans
150 – 250 ms: Acceptable quality, but delay and hesitation is
noticeable
> 250 – 300 ms: Unacceptable. Normal conversation is impossible
Jitter followed by effect



< 40 ms: Jitter is not detectable
40-75 ms: Good quality, but occasional jumble is noticeable
> 75 ms: Unacceptable. Too much jumble to carry a conversation
What Happens When QoS Fails?

Video Example


Out of sync image is a
result of motion
prediction. Result of loss
of a P or B frame
Missing image parts result
of a missing I frame
Summary of QoS Requirements For Specific Applications
Application
Dropped Packets
Delay
Jitter
Bandwidth
VoIP
< 3% packet loss
ratio
150 – 200 ms
< 30 ms
21 – 320 kbps
High Quality
Audio & Video
< 1 % packet loss
ratio
150 ms
< 30 ms
768 kbps + 20%
overhead = 921
kbps
None
none
700 Mbps
Remote
Visualization
Internet Gaming
none
150 ms
none
56 kbps
Web Browsing
none
2 sec is
preferred,
4 sec is
acceptable
none
10 kbps
Streaming Video
< 5%
4-5 seconds
n/a
Varies with
encoding format
Uncompressed
HDTV
1.5 Gbps
Who’s Responsibility Is It?

Routers don’t know typically know what the data
is


Thus, it requires a lot of overhead to allow the
routers to interpret the data
The encoding and decoding of the data in the
sender and the receiver(s) makes them a prime
target

This is where most of the focus of ensuring that
QoS requirements are met lies
Basic Types of QoS Technologies

Congestion/Traffic Control


Resource Management


Examples: RED, FRED, Droptail
Examples: IntServ, DiffServ
Queuing/Buffering

Priority Queuing, FRTS
Congestion Control Methods




RED/FRED
Droptail
Bucketing
QoS/BGP
Congestion Control Methods (cont.)

RED, FRED and Droptail Methods
Already discussed extensively in class
 Methods to improve congestion, but like all
methods, have their own drawbacks and benefits
 Important to note that these methods only help
improve QoS on a very high level. They improve
congestion and traffic, which helps the entire
internet, not just QoS issues.

Congestion Control Methods (cont.)

QoS / BGP (QoS Policy Propagation via Border
Gateway Protocol)
BGP is the core routing protocol of the internet
 Instead of using BGP solely to determine where to
send the packets, build on top of BGP to classify the
type of packets being sent
 Allows other methods, like queuing or scheduling, to
be used in conjunction to ensure QoS requirements
are met

Resource Management Methods

IntServ (Integrated Services)
A fine grained QoS system
 Individual applications must make indvidual
reservations of resources
 By making reservations, the application is guaranteed
a certain level of service – from “best effort” to
“100% guarantee”, and everything in between
 Uses RSVP (Resource ReSerVation Protocol) to help
determine what resources to allocate where.

Resource Management Methods
(cont.)

DiffServ (Differentiated Services)
Much more coarse QoS system
 Reservations are done in bulk, usually from a single
source (such as a university or a single ISP)
 Policing of data is done completely at DiffServ
clouds (individual systems of routers)
 Data with highest priority is given highest priority,
within clouds only

Resource Management Methods
(cont.)


Weaknesses of these methods:
IntServ


Similar to FRED, lots of data must be stored. Thus, hard to
scale for the entire internet
DiffServ



Not a good system for most links.
Since the traffic comes in very large chunks (e.g., all traffic
from OSU as well as all from Otterbein), there is likely to be
relatively steady traffic.
If packets need to be dropped, more bandwidth is needed to
fix the problem in most cases.
Queuing/Buffering Methods

FRTS (Frame Relay Traffic Shaping)
Excess traffic is delayed using a buffer or a queue
 Idea is to shape the flow’s traffic, usually when the
data rate of the source is higher than expected.
 Works very well with a large queue or a small scale.
If the queue is too small, or FRTS is run on a large
scale (e.g., the whole internet), a queue management
algorithm would be necessary.

Queuing/Buffering Methods (cont.)

CSFQ (Core Stateless Fair
Queuing)



First step – edge nodes estimate
the incoming rate of packets being
sent, then uses that as a label for
each of that flow’s packet
Next – all nodes (including edge)
repeatedly estimate the fair rate
from the outgoing link. Upon
arrival, the probability the packet
will be forwarded is calculated,
based on the previously calculated
probability, as well as the previous
label.
When that packet is forwarded, it
is sent with that probability, and
the label is replaced with the
smaller value between its previous
value and the fair rate.
Queuing/Buffering Methods (cont.)

Advantages of CSFQ
Per flow management is performed, allowing each
flow to get a fair rate
 Stateless (less information stored, the better)


Disadvantages of CSFQ
Not a lot of room for allowing prioritization
 Fair amount of calculation is necessary, and may be
futile calculation

Queuing/Buffering Methods (cont.)

Priority Queuing
Multiple queues in implementation, each
representing a level of priority (high, low, and a
differing number in between)
 Each queue gets only packets matching its priority
level
 Can change calculation equation on the fly

Queuing/Buffering Methods (cont.)

Advantages of Priority Queuing
Simple implementation
 Very flexible


Disadvantages of Priority Queuing
Starvation is still possible
 If equation remains stagnant, traffic could be lost in
the queues

Queuing/Buffering Methods (cont.)

Weighted Fair Queuing
An implementation of Priority Queuing
 Classifies all traffic through a series of qualifications
to get the traffic in the best possible queues
 Examples – interactive traffic goes before noninteractive, low bandwidth sessions go before high
bandwidth sessions

Combing technologies




Right now, to ensure QoS, there are no ‘magic
bullets’
Each technology type has many methods for a
reason
The way to effectively ensure QoS requirements
best is to combine methods effectively
As a result, we see certain technologies that we
cannot implement fully because of the inability
to meet the necessary QoS requirements
Telesurgery



Robotic and computer-aided surgery across a
distant location
Time-critical (delay-oriented) application
Data to send:
surgical movements
 real-time medical images
 voice and video signal

Telesurgery (cont.)

QoS requirements:
reliability of the network line
 low end-to-end delay
 low data error rate
 data transfer from sources with various data rates


The acceptable limit of delay requirement: 330
ms
Telesurgery (cont.)

The use of the Internet for telesurgery is not
possible

ATM and SDH/SONET (optical network) meet
the network requirements of telesurgery.
Telesurgery (cont.)

On September 7th, 2002, the first human
transoceanic (New York - Strasbourg, France)
operation was successfully performed
Telesurgery (cont.)
High-speed optical-fiber network
 Dedicated connection-oriented ATM transport
 Reserved bandwidth of 10 Mbps
 Measured mean-time of delays: 155 ms

ATM round trip delay: 78-80 ms
 Video coding and decoding: 70 ms
 Rate adaptation and Ethernet-to-ATM packet conversion:
~ 5 ms
No packet loss was detected


Remote Visualization



Interactive viewing of 3-D
scientific data sets over networks
Gigabyte size range of data sets
Interactivity → tight delay
requirement
Remote Visualization (cont.)

QoS requirements:
very high network bandwidth
 low latency
 constant jitter


The use of Internet for remote visualization is
not feasible
Remote Visualization (cont.)

RealityGrid implements tools for computational
steering in the Open Grid Services Architecture
(OGSA)
Remote Visualization (cont.)



High bandwidth links → at least 700 Mbps
Compressed video sent to remote observers →
100 - 200 Mbps (with low latency and constant
jitter)
These QoS requirements
increase linearly with #remote observers
 doubled again if remote stereoscopic rendering is
employed

Tele-Immersion


Enable individuals in different locations to
interact with each other in a shared, computergenerated environment as if they were in the
same physical room → Virtual Reality
The same QoS requirements as those of remote
visualization
Conclusions
Some benefits of QoS:







Control over which resources are being used
Ensure time-critical and mission-critical applications have their
required resources
More efficient use of existing network resources, rather than the need
for expansion or upgrades
Foundation for a fully-integrated multimedia network needed in the
near future
QoS of scientific-computation creates technical challenges for
designing the next generation of network
The challenge of insuring QoS requirements is a large part of
what drives today’s internet