Transcript ppt

15-441 Computer Networking
Multimedia
Outline
•
•
•
•
•
•
•
Multimedia requirements
Streaming
Phone over IP
Recovering from Jitter and Loss
RTP
QoS Requirements
Introduction to Scheduling Policies
11/15/2005
2
Application Classes
• Typically sensitive to delay, but can tolerate
packet loss (would cause minor glitches that can
be concealed)
• Data contains audio and video content
(“continuous media”), three classes of
applications:
• Streaming
• Unidirectional Real-Time
• Interactive Real-Time
11/15/2005
3
Application Classes (more)
• Streaming
• Clients request audio/video files from servers
and pipeline reception over the network and
display
• Interactive: user can control operation (similar
to VCR: pause, resume, fast forward, rewind,
etc.)
• Delay: from client request until display start can
be 1 to 10 seconds
11/15/2005
4
Application Classes (more)
• Unidirectional Real-Time:
• similar to existing TV and radio stations, but delivery on
the network
• Non-interactive, just listen/view
• Interactive Real-Time :
• Phone conversation or video conference
• More stringent delay requirement than Streaming and
Unidirectional because of real-time nature
• Video: < 150 msec acceptable
• Audio: < 150 msec good, <400 msec acceptable
11/15/2005
5
Challenges
• TCP/UDP/IP suite provides best-effort, no
guarantees on expectation or variance of packet
delay
• Streaming applications delay of 5 to 10 seconds is
typical and has been acceptable, but performance
deteriorate if links are congested (transoceanic)
• Real-Time Interactive requirements on delay and
its jitter have been satisfied by over-provisioning
(providing plenty of bandwidth), what will happen
when the load increases?...
11/15/2005
6
Challenges (more)
• Most router implementations use only FirstCome-First-Serve (FCFS) packet
processing and transmission scheduling
• To mitigate impact of “best-effort” protocols,
we can:
• Use UDP to avoid TCP and its slow-start
phase…
• Buffer content at client and control playback to
remedy jitter
• Adapt compression level to available bandwidth
11/15/2005
7
Solution Approaches in IP
Networks
• Just add more bandwidth and enhance caching
capabilities (over-provisioning)!
• Need major change of the protocols :
• Incorporate resource reservation (bandwidth, processing,
buffering), and new scheduling policies
• Set up service level agreements with applications, monitor and
enforce the agreements, charge accordingly
• Need moderate changes (“Differentiated Services”):
• Use two traffic classes for all packets and differentiate service
accordingly
• Charge based on class of packets
• Network capacity is provided to ensure first class packets incur no
significant delay at routers
11/15/2005
8
Outline
•
•
•
•
•
•
•
Multimedia requirements
Streaming
Phone over IP
Recovering from Jitter and Loss
RTP
QoS Requirements
Introduction to Scheduling Policies
11/15/2005
9
Streaming
• Important and growing application due to
reduction of storage costs, increase in high
speed net access from homes,
enhancements to caching and introduction
of QoS in IP networks
• Audio/Video file is segmented and sent over
either TCP or UDP, public segmentation
protocol: Real-Time Protocol (RTP)
11/15/2005
10
Streaming
• User interactive control is provided, e.g. the public
protocol Real Time Streaming Protocol (RTSP)
• Helper Application: displays content, which is
typically requested via a Web browser; e.g.
RealPlayer; typical functions:
• Decompression
• Jitter removal
• Error correction: use redundant packets to be used for
reconstruction of original stream
• GUI for user control
11/15/2005
11
Streaming From Web Servers
• Audio: in files sent as HTTP objects
• Video (interleaved audio and images in one file, or two
separate files and client synchronizes the display) sent as
HTTP object(s)
• A simple architecture is to have the Browser request the
object(s)
and after their
reception pass
them to the player
for display
- No pipelining
11/15/2005
12
Streaming From Web Server
(more)
• Alternative: set up connection between server and
player, then download
• Web browser requests and receives a Meta File
(a file describing the object) instead of receiving
the file itself;
• Browser launches the appropriate Player and
passes it the Meta File;
• Player sets up a TCP connection with Web Server
and downloads the file
11/15/2005
13
Meta file requests
11/15/2005
14
Using a Streaming Server
• This gets us around HTTP, allows a choice of UDP vs.
TCP and the application layer protocol can be better
tailored to Streaming; many enhancements options are
possible (see next slide)
11/15/2005
15
Options When Using a Streaming
Server
• Use UDP, and Server sends at a rate (Compression and
Transmission) appropriate for client; to reduce jitter, Player
buffers initially for 2-5 seconds, then starts display
• Use TCP, and sender sends at maximum possible rate
under TCP; retransmit when error is encountered; Player
uses a much large buffer to smooth delivery rate of TCP
11/15/2005
16
Real Time Streaming Protocol
(RTSP)
• For user to control display: rewind, fast forward,
pause, resume, etc…
• Out-of-band protocol (uses two connections, one
for control messages (Port 554) and one for
media stream)
• RFC 2326 permits use of either TCP or UDP for
the control messages connection, sometimes
called the RTSP Channel
• As before, meta file is communicated to web
browser which then launches the Player; Player
sets up an RTSP connection for control messages
in addition to the connection for the streaming
media
11/15/2005
17
Meta File Example
<title>Xena: Warrior Princess</title>
<session>
<group language=en lipsync>
<switch>
<track type=audio
e="PCMU/8000/1"
src =
"rtsp://audio.example.com/xena/audio.en/lofi">
<track type=audio
e="DVI4/16000/2" pt="90 DVI4/8000/1"
src="rtsp://audio.example.com/xena/audio.en/hifi">
</switch>
<track type="video/jpeg"
11/15/2005
18
RTSP Operation
11/15/2005
19
RTSP Exchange Example
C: SETUP rtsp://audio.example.com/xena/audio RTSP/1.0
Transport: rtp/udp; compression; port=3056; mode=PLAY
S: RTSP/1.0 200 1 OK
Session 4231
C: PLAY rtsp://audio.example.com/xena/audio.en/lofi RTSP/1.0
Session: 4231
Range: npt=0(npt = normal play time)
C: PAUSE rtsp://audio.example.com/xena/audio.en/lofi RTSP/1.0
Session: 4231
Range: npt=37
C: TEARDOWN rtsp://audio.example.com/xena/audio.en/lofi RTSP/1.0
Session: 4231
S: 200 3 OK
11/15/2005
20
Outline
•
•
•
•
•
•
•
Multimedia requirements
Streaming
Phone over IP
Recovering from Jitter and Loss
RTP
QoS Requirements
Introduction to Scheduling Policies
11/15/2005
21
Real-Time (Phone) Over IP’s
Best-Effort
• Internet phone applications generate packets
during talk spurts
• Bit rate is 8 KBytes, and every 20 msec, the
sender forms a packet of 160 Bytes + a header to
be discussed below
• The coded voice information is encapsulated into
a UDP packet and sent out; some packets may be
lost; up to 20 % loss is tolerable; using TCP
eliminates loss but at a considerable cost:
variance in delay; FEC (forward error correction)
is sometimes used to fix errors and make up
losses
11/15/2005
22
Real-Time (Phone) Over IP’s
Best-Effort
• End-to-end delays above 400 msec cannot
be tolerated; packets that are that delayed
are ignored at the receiver
• Delay jitter is handled by using timestamps,
sequence numbers, and delaying playout at
receivers either a fixed or a variable amount
• With fixed playout delay, the delay should
be as small as possible without missing too
many packets; delay cannot exceed 400
msec
11/15/2005
23
Internet Phone with Fixed Playout
Delay
11/15/2005
24
Adaptive Playout Delay
• Objective is to use a value for p-r that tracks the
network delay performance as it varies during a
phone call
• The playout delay is computed for each talk spurt
based on observed average delay and observed
deviation from this average delay
• Estimated average delay and deviation of average
delay are computed in a manner similar to
estimates of RTT and deviation in TCP
• The beginning of a talk spurt is identified from
examining the timestamps in successive and/or
sequence numbers of chunks
11/15/2005
25
Outline
•
•
•
•
•
•
•
Multimedia requirements
Streaming
Phone over IP
Recovering from Jitter and Loss
RTP
QoS Requirements
Introduction to Scheduling Policies
11/15/2005
26
Recovery From Packet Loss
• Loss is in a broader sense: packet never arrives
or arrives later than its scheduled playout time
• Since retransmission is inappropriate for Real
Time applications, FEC or Interleaving are used to
reduce loss impact.
• FEC is Forward Error Correction
• Simplest FEC scheme adds a redundant chunk
made up of exclusive OR of a group of n chunks;
redundancy is 1/n; can reconstruct if at most one
lost chunk; playout time schedule assumes a loss
per group
11/15/2005
27
Recovery From Packet Loss
• Mixed quality streams are used to include
redundant duplicates of chunks; upon loss
playout available redundant chunk, albeit a
lower quality one
• With one redundant low quality chunk per
chunk, scheme can recover from single
packet losses
11/15/2005
28
Piggybacking Lower Quality
Stream
11/15/2005
29
Interleaving
• Has no redundancy, but can cause delay in
playout beyond Real Time requirements
• Divide 20 msec of audio data into smaller units of
5 msec each and interleave
• Upon loss, have a set of partially filled chunks
11/15/2005
30
Outline
•
•
•
•
•
•
•
Multimedia requirements
Streaming
Phone over IP
Recovering from Jitter and Loss
RTP
QoS Requirements
Introduction to Scheduling Policies
11/15/2005
31
Real-Time Protocol (RTP)
• Provides standard packet format for real-time
application
• Typically runs over UDP
• Specifies header fields below
• Payload Type: 7 bits, providing 128 possible
different types of encoding; eg PCM, MPEG2
video, etc.
• Sequence Number: 16 bits; used to detect
packet loss
11/15/2005
32
Real-Time Protocol (RTP)
• Timestamp: 32 bytes; gives the sampling
instant of the first audio/video byte in the
packet; used to remove jitter introduced by
the network
• Synchronization Source identifier
(SSRC): 32 bits; an id for the source of a
stream; assigned randomly by the source
11/15/2005
33
RTP Control Protocol (RTCP)
• Protocol specifies report packets exchanged
between sources and destinations of multimedia
information
• Three reports are defined: Receiver reception,
Sender, and Source description
• Reports contain statistics such as the number of
packets sent, number of packets
lost, inter-arrival jitter
• Used to modify sender
transmission rates and
for diagnostics purposes
11/15/2005
34
RTCP Bandwidth Scaling
• If each receiver sends RTCP packets to all
other receivers, the traffic load resulting can
be large
• RTCP adjusts the interval between reports
based on the number of participating
receivers
• Typically, limit the RTCP bandwidth to 5% of
the session bandwidth, divided between the
sender reports (25%) and the receivers
reports (75%)
11/15/2005
35
Outline
•
•
•
•
•
•
•
Multimedia requirements
Streaming
Phone over IP
Recovering from Jitter and Loss
RTP
QoS Requirements
Introduction to Scheduling Policies
11/15/2005
36
Improving QoS in IP Networks
• IETF groups are working on proposals to
provide better QoS control in IP networks,
i.e., going beyond best effort to provide some
assurance for QoS
• Work in Progress includes RSVP,
Differentiated Services, and Integrated
Services
• Simple model
for sharing and
congestion
studies:
11/15/2005
37
Principles for QoS Guarantees
• Consider a phone application at 1Mbps and an
FTP application sharing a 1.5 Mbps link.
• bursts of FTP can congest the router and cause audio
packets to be dropped.
• want to give priority to audio over FTP
• PRINCIPLE 1: Marking of packets is needed
for router to distinguish between different
classes; and new router policy to treat packets
accordingly
e.g. MPLS, Diffserv,RSVP
11/15/2005
38
Principles for QoS Guarantees
(more)
• Applications misbehave (audio sends packets at a
rate higher than 1Mbps assumed above);
• PRINCIPLE 2: provide protection (isolation) for
one class from other classes
• Require Policing Mechanisms to ensure sources
adhere to bandwidth requirements; Marking and
Policing need to be done at the edges:
e.g. WFQ
11/15/2005
39
Principles for QoS Guarantees
(more)
• Alternative to Marking and Policing: allocate a set
portion of bandwidth to each application flow; can
lead to inefficient use of bandwidth if one of the
flows does not use its allocation
• PRINCIPLE 3: While providing isolation, it is
desirable to use resources as efficiently as
possible
11/15/2005
40
Principles for QoS Guarantees
(more)
• Cannot support traffic beyond link capacity
• PRINCIPLE 4: Need a Call Admission Process;
application flow declares its needs, network
may block call if it cannot satisfy the needs
11/15/2005
41
Summary
11/15/2005
42
Outline
•
•
•
•
•
•
•
Multimedia requirements
Streaming
Phone over IP
Recovering from Jitter and Loss
RTP
QoS Requirements
Introduction to Scheduling Policies
11/15/2005
43
Scheduling And Policing
Mechanisms
• Scheduling: choosing the next packet for
transmission on a link can be done following a
number of policies;
• FIFO: in order of arrival to the queue; packets that
arrive to a full buffer are either discarded, or a
discard policy is used to determine which packet
to discard among the arrival and those already
queued
11/15/2005
44
Scheduling Policies
• Priority Queuing: classes have different priorities; class
may depend on explicit marking or other header info,
eg IP source or destination, TCP Port numbers, etc.
• Transmit a packet from the highest priority class with a
non-empty queue
• Preemptive and non-preemptive versions
11/15/2005
45
Scheduling Policies (more)
• Round Robin: scan class queues serving one
from each class that has a non-empty queue
11/15/2005
46
Scheduling Policies (more)
• Weighted Fair Queuing: is a generalized
Round Robin in which an attempt is made
to provide a class with a differentiated
amount of service over a given period of
time
11/15/2005
47
Policing Mechanisms
• Three criteria:
• (Long term) Average Rate (100 packets per sec or
6000 packets per min??), crucial aspect is the interval
length
• Peak Rate: e.g., 6000 p p minute Avg and 1500 p p sec
Peak
• (Max.) Burst Size: Max. number of packets sent
consecutively, ie over a short period of time
11/15/2005
48
Policing Mechanisms
• Token Bucket mechanism, provides a
means for limiting input to specified Burst
Size and Average Rate.
11/15/2005
49
Policing Mechanisms (more)
• Bucket can hold b tokens; token are
generated at a rate of r token/sec unless
bucket is full of tokens.
• Over an interval of length t, the number of
packets that are admitted is less than or
equal to (r t + b).
• Token bucket and
WFQ can be
combined to
provide upper
bound on delay.
11/15/2005
50