Transcript Slide 1

INFO 331
Computer Networking
Technology II
Chapter 7
Multimedia Networking
Dr. Jennifer Booker
INFO 331 chapter 7
1
www.ischool.drexel.edu
Multimedia Networking
• Recent years have seen massive growth
in Internet audio and video apps
– Streaming video, IP telephony, Internet radio,
teleconferencing, interactive games, distance
learning, Netflix, Hulu, etc.
• Older Internet apps (email, WWW, FTP)
were very elastic in bandwidth needs, but
multimedia is much fussier – delay
sensitive
– But they’re also more loss-tolerant
INFO 331 chapter 7
2
www.ischool.drexel.edu
Multimedia Networking
• Multimedia apps are in three categories
– Streaming stored audio & video (AV)
– Streaming live AV
– Conversational voice/VOIP
• This excludes download-stuff-and-play,
such as MP3s, iTunes, etc.
– Download entire file before play starts
– FTP or HTTP are fine for them
INFO 331 chapter 7
3
www.ischool.drexel.edu
Video properties
• Compression helps speed information
transmission rate by reducing its volume
• Long done for static images (JPG, GIF)
– Each pixel is 24 bits of color data (RGB),
• A 1024x768 pixel image is 1024x768x24/8 =
2.36 MB
– Compression can reduce image size a factor
of 10 without severe quality loss
• Key tradeoff: more compression = more losses
•
Huge field (e.g. ISBN 1565921615)
INFO 331 chapter 7
4
www.ischool.drexel.edu
Video properties
• Video needs a high bit rate, typically 100
kbps for minimal video conferencing to 3
Mbps for streaming high def movies
– Streaming MP3s or viewing many pictures
might take under 100 MB per hour, but
streaming video might take over 1 GB per hr
• Might have several versions of the same
content at different quality levels, e.g. from
300 kbps to 3 Mbps
INFO 331 chapter 7
5
www.ischool.drexel.edu
Video Compression
• Video is a series of images presented at
24 or 30 images per second
– Hence the size of the images (X by 0.75*X
pixels), and the color resolution (number of
bits per pixel) also affect the raw data volume
– Widescreen image sizes have a 16x9 ratio
instead of 4x3 ratio
INFO 331 chapter 7
6
www.ischool.drexel.edu
Video Compression
• Video compression standards are mostly
the MPEG family
– MPEG 1 for CD quality video at 1.5 Mbps
– MPEG 2 for DVD quality video, 3-6 Mbps
– MPEG 4 for object oriented video
– H.261 from ITU
– Proprietary formats, such as QuickTime
(includes MPEG-4 and H.264), Real
networks, etc.
INFO 331 chapter 7
7
www.ischool.drexel.edu
Audio properties
• Digital audio signals have three major
characteristics
– The sampling rate (samples per second)
– The number of channels sampled (mono,
stereo, etc.)
– The number of bits per sample
• These all affect the raw amount of data
being sent, before compression is applied
INFO 331 chapter 7
8
www.ischool.drexel.edu
Audio properties
• Raw audio signals are recorded at some
sample rate per second, per channel
– 8k, 16k, or 32k samples/sec (Hz) are common
low grade rates
– 44.1k (CD quality), 48k, 96k, and even
192kHz sample rates are used for
professional audio
• The number of channels used is typically
one (mono), two (stereo), or 5 to 7
(surround)
INFO 331 chapter 7
9
www.ischool.drexel.edu
Audio properties
• Each sample is quantized into some number of
bits to describe its relative strength
– 8 bits gives 256 values from silent to REALLY LOUD,
which is typical for cheap built-in audio
– CD quality uses 16 bits per sample
– Pro audio typically uses 24 or 32 bits per sample
• So one minute of absurd quality 7 channel
surround would use 192k sample/sec x 7 channels x 32
bits/sample / 8 bit/byte * 60 sec/min = 322.56 MB/min!
INFO 331 chapter 7
10
www.ischool.drexel.edu
Audio Compression
• This approach for audio is formally called
Pulse Code Modulation (PCM)
– Mono speech recording at 8kHz sample rate
and 8 bits/sample equals 64 kbps of data
– CD quality (44.1 kHz, 16 bit, stereo) = 1.411
Mbps
• Modems can’t handle 64 kbps, and some
broadband users can’t consistently get 1.4
Mbps, so compression is needed even for
just audio
INFO 331 chapter 7
11
www.ischool.drexel.edu
Audio Compression
• Common audio compression standards
include
– GSM, G.729, and G.723.3 from ITU
– “MPEG 1 layer 3”, a.k.a. MP3, which
compresses to 96, 128, or 160 kbps
– AAC (Advanced Audio Coding) is widely used
by Apple
INFO 331 chapter 7
12
www.ischool.drexel.edu
Streaming stored AV
• Here, clients request on-demand compressed
AV files that are stored on servers
– Content may include lectures, music, TV, etc.
– CNN video, YouTube, etc.
• Main features of this app type are:
– Stored, prerecorded media; pause, ffwd, rew
– Streaming, hence can play part of the media while
downloading more of it
– Continuous play out – should keep original timing
INFO 331 chapter 7
13
www.ischool.drexel.edu
Conversational voice/VOIP
• This class of apps allows interaction
between people at both ends (or many
ends) of a connection, such as Internet
telephony or voice-over-IP (VOIP)
– E.g. Skype
– Very delay sensitive
• Transmission delays under 150 ms are good,
under 400 ms is okay, and over 400 ms is bad
– Is often loss-tolerant
INFO 331 chapter 7
14
www.ischool.drexel.edu
Streaming live AV
• This is live broadcast of radio or TV over
the Internet
– Can’t fast forward, since it hasn’t happened yet,
but local storage of what’s been received can
allow pausing and rewinding in some cases
– Often accomplished using IP multicasting or
IPTV, but more often done via separate unicast
streams
– Also has continuous play out, can tolerate some
startup delay
INFO 331 chapter 7
15
www.ischool.drexel.edu
Streaming Stored AV
• Streaming stored audio/video has become very
popular (YouTube, Netflix, Hulu) because
– Disk space is dirt cheap (< $50/TB)
– Internet infrastructure is improving, but over 50% of
downstream traffic can be this type
– There’s enormous demand to entertain me NOW
• In this multimedia mode, clients request
compressed AV files that live on servers
– Files are segmented, with special headers used for
encapsulating them
INFO 331 chapter 7
16
www.ischool.drexel.edu
Streaming Stored AV
• Three major types of this traffic
– UDP-streaming
– HTTP-streaming
– Adaptive HTTP-streaming
• All use client buffering to soak up
variations in server-client delay
INFO 331 chapter 7
17
www.ischool.drexel.edu
Streaming Stored AV
• UDP streaming sends packets over UDP
with a small client-side buffer
– RTP – Real Time Protocol is used to
encapsulate the segments
– RTSP – Real Time Streaming Protocol
is used for client/server interaction
• Not used much since hard to ensure continuous
playout, need for an RTSP server, and firewalls
may block UDP
INFO 331 chapter 7
18
www.ischool.drexel.edu
Streaming Stored AV
• HTTP streaming just uses ordinary GET
commands to send files over TCP
– The HTTP byte-range header helps specify
which parts of the video to get
• Client uses a buffer to prefetch video
frames
– If buffer gets full, will limit the server send rate
• Most stored video uses this
INFO 331 chapter 7
19
www.ischool.drexel.edu
Streaming Stored AV
• Adaptive HTTP-streaming such as DASH
(Dynamic Adaptive Streaming over HTTP)
changes the video quality obtained
depending on the connection bandwidth
• Comcast has 8-10 different quality formats within
MPEG-4
• Server has a manifest file with version data
• Based on actual download rate pick best version
• Likewise can adjust audio resolution
INFO 331 chapter 7
20
www.ischool.drexel.edu
Content Distribution Networks
• Content Distribution Networks (CDNs) are to
address the need for lots of people accessing
the same stored media often and/or at once
– After all, a single server source would have terrible
bandwidth and packet loss issues
– A CDN can be private or third party
• Often a content provider (CNN, Google, etc.) will
pay a CDN company (Akamai, Limelight) to
provide videos to users with as little delay as
possible
INFO 331 chapter 7
21
www.ischool.drexel.edu
Content Distribution Networks
• The CDN approach is simple – make lots
of copies of the media, and put them on
lots of servers everywhere
• CDN servers get put throughout the
Internet (e.g. 1700 locations for Akamai)
• Often the CDN company will lease data
center space to house the servers
– Data centers might be located at second or
third tier ISPs
INFO 331 chapter 7
22
www.ischool.drexel.edu
Content Distribution Networks
• Google’s CDN has one huge autonomous
system with:
– 8 mega data centers with ~100,000 servers in
each (6 in USA, 2 in Europe)
– 30 ‘bring-home’ clusters of 100-500 servers
worldwide near tier-1 ISPs
– Hundreds of ‘enter-deep’ clusters located
within ISPs
INFO 331 chapter 7
23
www.ischool.drexel.edu
Content Distribution Networks
• The CDN gets source media (videos) from the
customer, and copies them to the servers
• When a user requests content, the nearest (or
most available) CDN server delivers it
– DNS redirection is used to find the correct CDN
server
– This results in URLs with two addresses in them – the
first is the CDN, the second is the file name
• http://www.cdn.com/www.cnn.com/zoo/turtle.mpg
INFO 331 chapter 7
24
www.ischool.drexel.edu
Content Distribution Networks
• The ‘best’ server for each ISP is
determined using the same approaches
we saw for BGP routing tables
• CDNs may also be used within a large
corporation to stream, for example,
training videos locally
INFO 331 chapter 7
25
www.ischool.drexel.edu
Content Distribution Networks
• CDN deployment depends on a good
cluster selection strategy
– Could use geographically closest
– Perform periodic real-time measurements of
delay and losses
– Use IP anycast, and let BGP decide
INFO 331 chapter 7
26
www.ischool.drexel.edu
Voice-over-IP
• IP provides only “best-effort” service with
no guarantees on timing or even delivery
• Packet loss is quite possible with UDP
traffic, but TCP may get packets there too
late to be useful!
INFO 331 chapter 7
27
www.ischool.drexel.edu
Internet Phone
• Real-time apps, such as Internet phone and
video conferencing, are very sensitive to packet
delay, jitter, and packet loss
• See how these issues are handled for Internet
phone
– Data is generated at 8 kBps
– Every 20 ms, a chunk of 160 bytes of data gets a
header attached, and the packet is sent via UDP
• Ideally, these packets all get to the receiver
INFO 331 chapter 7
28
www.ischool.drexel.edu
Internet Phone
• The receiver must decide
– When to play back a given packet
– What to do if a packet is missing
• Recall packets can be lost if they arrive at
a router with a full input or output queue
• From 1-20% packet loss can be tolerated
– Forward error correction (FEC) can help make
up for lost packets
INFO 331 chapter 7
29
www.ischool.drexel.edu
Internet Phone
• End-to-end delay can be confusing for the
receiver, if it simply takes too long for the
data to get there
– Recall the under 150 ms, 150-400 ms, and
over 400 ms ranges for good, ok, and bad
delays
– Internet phone may discard packets over
400 ms old
• Jitter is typically caused by variation in
queuing delays
INFO 331 chapter 7
30
www.ischool.drexel.edu
Internet Phone
• Some jitter problems can be removed by
using sequence numbers, time stamps,
and playout delays to make sure packets
are in order as well as possible
• Playout delay can be fixed or adaptive
• For fixed playout delay, anything arriving
after its planned play time is discarded
– The amount of delay is typically 150-400 ms,
less under good network conditions
INFO 331 chapter 7
31
www.ischool.drexel.edu
Adaptive playout delay
• Adaptive playout delay is often used
because long delay is annoying to the
users
– Want to make the delay as small as possible
without losing a lot of packets
– Delay is reassessed for each talk spurt
(period of transmission)
• Similar to calculation of timeout interval for
TCP, use previous history, amended by
the most recent data
INFO 331 chapter 7
32
www.ischool.drexel.edu
Recovering from packet loss
• The method for compensating for lost
packets is the loss recovery scheme
– Here, ‘lost’ means it never got there, or it
got there after its planned play time
• Retransmitting lost packets doesn’t make
sense here (why?)
• Instead anticipate loss, using methods like
– Forward Error Correction
– Interleaving
INFO 331 chapter 7
33
www.ischool.drexel.edu
Forward Error Correction
• Forward Error Correction adds a little
redundant data to packets to help allow
recreating what missing packets had in
them
– RAT (Robust Audio Tool) is an open source
Internet phone app that uses FEC and RTP
• There are lots of FEC approaches; we’ll
look at two of them
INFO 331 chapter 7
34
www.ischool.drexel.edu
Forward Error Correction
• First is to send a redundant encoded
chunk of data after every n normal chunks
– The redundant chunk is obtained from
XOR-ing the normal chunks
• If any ONE of the n chunks is missing,
it can be reconstructed mathematically
– But if two or more packets are lost, tough luck
• This increases transmission rate 100/n%
INFO 331 chapter 7
35
www.ischool.drexel.edu
Forward Error Correction
• The second approach is sneakier
– Add a second, lower quality data stream in
parallel with the primary stream (e.g. tack on
a 13 kbps stream to a 65 kbps stream)
– When loss occurs, use the low quality stream
– This increases playout delay little
– Many variations on this approach are
possible, especially to allow for higher
loss rates
INFO 331 chapter 7
36
www.ischool.drexel.edu
Interleaving
• Interleaving breaks the stream of data into
smaller chunks, and rearranges how the chunks
are sent
– So if each chunk of data is broken into four pieces,
then the first unit of data sent has chunks number
1, 5, 9, and 13 instead of just 1-4
• The second chunk sent has 2, 6, 10, & 14; the third chunk
has 3, 7, 11, & 15, etc.
– That way if a chunk is lost, the loss is distributed
across a wider range of time
INFO 331 chapter 7
37
www.ischool.drexel.edu
Interleaving
• This increases latency (have to break up &
reassemble chunks)
• Doesn’t increase bandwidth of data – no
extra data is being sent
• So how can we fix the data if some is lost?
INFO 331 chapter 7
38
www.ischool.drexel.edu
Error concealment
• Voice is relatively easy to fix if a little data is
missing
– Loss rates under 15% for packets 4-40 ms long
• One technique is simply repetition – copy the
previous packet and play it again
– Easy to do and usually works ok
• Or can try to interpolate between before and
after packets
– More tricky computationally, but sounds better
INFO 331 chapter 7
39
www.ischool.drexel.edu
Real-time Interactive Protocols
• Demand for real time interactive
applications is huge, so there has been a
lot of work on protocols to help make such
apps easier to develop
• Here we’ll look at two common ones
– RTP, the Real-time Transport Protocol
– SIP
INFO 331 chapter 7
40
www.ischool.drexel.edu
RTP
• RTP defines a standard AV chunk-of-data
structure for data, sequence numbers,
timestamps, etc.
– The actual data format can be a proprietary
format, or other AV formats such as PCM,
GSM, MP3, MPEG, H.263, etc.
• RTP is defined by RFC 3550, and usually
runs over UDP (no fixed port number)
• Often used for Internet telephony apps
INFO 331 chapter 7
41
www.ischool.drexel.edu
RTP
Application
P
RT
Header info
Timestamp,
sequence
number
fin
de
es
AV data
Format can be PCM,
GSM, MP3, MPEG,
H.263, proprietary
AV formats, etc.
Pass to transport
layer (UDP)
Pass to network
layer (IP)
INFO 331 chapter 7
42
www.ischool.drexel.edu
RTP
• An RTP packet consists of the RTP header plus
the data
– The RTP header is at least 12 B (3 rows x 4B ea.)
• Apps that both use RTP have a better chance of
cooperating (e.g. if two users have different apps
at each end of a phone call)
• RTP doesn’t guarantee data delivery, or
sequence
– Routers can’t tell RTP data from anything else
INFO 331 chapter 7
43
www.ischool.drexel.edu
RTP
• Every data source (video camera, microphone)
can have an RTP data stream
– Video conference could have four RTP streams to
send video each direction, and audio each way
– Some compression formats (MPEG-1 and -2)
combine audio and video into one stream
• RTP can be used with unicast or multicast
– A group of streams from the same origin form an
RTP session
INFO 331 chapter 7
44
www.ischool.drexel.edu
RTP Header Fields
• The RTP header is very simple
– First line has:
• Nine bits of misc. identifiers (version, how long
the CSRC list will be, if custom extensions are
used, etc.)
• Payload type (7 b)
• Sequence number (16 b)
– Timestamp (32 b)
– SSRC (32 b)
– CSRC list (0 to 15 lines of 32 b each)
INFO 331 chapter 7
45
www.ischool.drexel.edu
RTP Header
• The Payload Type is a numeric code that
identifies what format the data has – PCM,
GSM, MPEG, etc.
• The Sequence Number starts at a random
value, and “increments by one for each
RTP data packet sent” [RFC 3550]
• The Timestamp is when the first data was
sampled; change from one to the next is
inversely proportional to the sampling rate
INFO 331 chapter 7
46
www.ischool.drexel.edu
RTP Header
• The SSRC is the synchronization source
identifier – just a random number to
identify the source
– Only goal is that no two SSRCs are the same
in a session
• The CSRC list is the contributing sources
for audio data
– Is often used for mixing, or to identify specific
data sources (Fred vs. Wilma)
INFO 331 chapter 7
47
www.ischool.drexel.edu
RTP App Development
• RTP can be implemented two ways
– Use RFC 3550 and manually implement RTP
headers within your application
– Use existing API libraries (e.g. in C or Java) to
implement RTP for you, and have your app
call them
– Hmm, I wonder which is easier?
• RTP can be coded as an app-layer
protocol, or used in conjunction with
UDP via the API
INFO 331 chapter 7
48
www.ischool.drexel.edu
SIP
• The Session Initiation Protocol (SIP) is
defined by RFC 5411
– SIP can be over UDP or TCP, and uses port
5060
• It is designed to handle Internet telephone
across LANs (not local phone exchanges)
– It allows calls to be placed over IP
– Allows caller to determine IP of callee (varies)
– Can add media streams during call
INFO 331 chapter 7
49
www.ischool.drexel.edu
SIP Session Example
• Caller sends an INVITE message
– Tells caller and callee IP addresses, media
format and encoding, type of encapsulation
(RTP) and receiving port number
• Callee sends response msg
– Confirms IP address, encoding,
encapsulation, and port number
• Caller sends ACK to callee, and the call
can take place
INFO 331 chapter 7
50
www.ischool.drexel.edu
SIP Session Example
Bob
Alice
167.180.112.24
INVITE bob
@193.64.2
10.89
c=IN IP4 16
7.180.112.2
4
m=audio 38
060 RTP/AV
P0
193.64.210.89
port 5060
port 5060
Bob's
terminal rings
200 OK
10.89
c=IN IP4 193.64.2
P/AVP 3
RT
3
m=audio 4875
ACK
port 5060
 Law audio
port 38060
GSM
port 48753
INFO 331 chapter 7
time
51
time
www.ischool.drexel.edu
SIP
• So what?
– The two parties can be using completely
different encoding and encapsulation
methods, yet carry on the call
– Also note that the control messages stay over
port 5060, yet the media are over two other,
negotiated ports – so SIP uses out-of-band
control messages
– SIP requires ACK of all messages, so either
UDP or TCP can be used
INFO 331 chapter 7
52
www.ischool.drexel.edu
SIP Addressing
• SIP addresses can look like email
addresses, or cite IP addresses, or be a
phone number, or even a full personal
name
– [email protected]
– [email protected]
– [email protected]
INFO 331 chapter 7
53
www.ischool.drexel.edu
SIP Messages
• The SIP protocol is huge – 269 pages – so
only a brief overview is in order
• The INVITE message typically is
addressed to an email-like address, e.g.
[email protected]
• Each device the message passes through
adds a Via: header with that device’s IP
• A SIP proxy finds the IP of the device the
callee is currently using
INFO 331 chapter 7
54
www.ischool.drexel.edu
SIP Messages
• Every SIP user is associated with a
SIP registrar
– When a SIP device is launched, it registers
with the registrar to give its current IP address
• So the SIP proxy asks the callee’s
registrar for their IP address
– The proxy might be redirected to another
registrar if the callee is not nearby
INFO 331 chapter 7
55
www.ischool.drexel.edu
SIP applications
• SIP has been described for voice over IP,
but can also be used for any media –
video, even text messaging
• SIP software is widely available for many
common functions, on various platforms
(PC/Mac/Linux)
INFO 331 chapter 7
56
www.ischool.drexel.edu
Network support for multimedia
• Three main approaches for handling AV
– Make do with Internet’s best effort status quo
– Provide differentiated service through packet
marking, policing, and scheduling
– Provide pre-connection guarantees of quality
of service (QoS) through differentiated service
plus call admission and signaling
INFO 331 chapter 7
57
www.ischool.drexel.edu
Fix the Internet!
• Others insist the Internet doesn’t need
massive changes
– Let ISPs upgrade bandwidth as customers
demand it
– Increase ISP caching for common requested
stored AV
– Add content distribution networks (CDNs) for
paid stored media, conveniently near network
edges
INFO 331 chapter 7
58
www.ischool.drexel.edu
Fix the Internet!
• Second approach is to add pricing at the
network & transport layers, to pay for
better service (Diffserv approach)
– We’ve seen net neutrality battles over this
option
INFO 331 chapter 7
59
www.ischool.drexel.edu
Fix the Internet!
• Some argue the Internet should allow for
end-to-end bandwidth guarantees, like
virtual circuit networks can provide
– Would require massive changes to routers to
establish fixed paths for some service types
– Hard guarantees mean you’re certain to
receive the QoS you paid for
– Soft guarantees mean you’re likely to receive
the QoS you paid for
INFO 331 chapter 7
60
www.ischool.drexel.edu
Dimensioning best-effort networks
• Many techniques we’ve seen can be used
to improve the quality of service of
multimedia apps
– We want low RTT, little jitter, few packets lost
• Another solution is to throw enough money
at the network to avoid all these problems
– Given enough resources, none of these
problems occur!
INFO 331 chapter 7
61
www.ischool.drexel.edu
Dimensioning best-effort networks
• To do so requires adequate bandwidth
provisioning, and at a larger scale, good
network dimensioning; issues include
– Model traffic demand between network
end points
– Clear performance requirements
– Model performance for a given workload
– Model to predict minimum bandwidth to
meet all requirements
INFO 331 chapter 7
62
www.ischool.drexel.edu
Beyond Best Effort
• So lots of techniques have been used to
get the most out of the Internet’s ‘best
effort’ approach
– The current quality of service (QoS) has no
guarantees
– How can we improve on that?
• Change the architecture of the Internet!
• Look at a sample network to examine the
problems
INFO 331 chapter 7
63
www.ischool.drexel.edu
A Sample Network
INFO 331 chapter 7
64
www.ischool.drexel.edu
A Sample Network
• In this example, the local networks are
assumed much faster than the 1.5 Mbps
connection between them
– Two apps are competing for that 1.5 Mbps of
bandwidth, e.g. leaving the first router (R1)
• Scenario 1: If hosts H1 is sending FTP to
H3, and then H2 tries to send audio traffic
to H4, the router R1 will already be full,
making for lost audio packets
INFO 331 chapter 7
65
www.ischool.drexel.edu
A Sample Network
• But IF we could mark audio packets versus FTP
packets, we could give priority to audio packets,
since they are delay sensitive
– Principle 1: packet marking lets a router
distinguish between different classes of traffic
• Scenario 2 – what if the FTP traffic was on a
high priority (paid) connection, but the audio
traffic was normal free Internet
– Principle 1a: packet classification lets a router
distinguish between different classes of traffic
INFO 331 chapter 7
66
www.ischool.drexel.edu
A Sample Network
• The distinction is important
– Marking packets for type of payload is one
way to classify them, but hardly the only one
– The packets could be prioritized by the
originating IP address (which could imply
whether premium service was used)
• Scenario 3: Bad application
– What if the audio app should get priority, but
it abuses that and hogs the whole link?
INFO 331 chapter 7
67
www.ischool.drexel.edu
A Sample Network
– Instead of allowing 1.0 Mbps for audio, the app tries
to take the whole 1.5 Mbps, thereby shutting off the
FTP service
– Just like circuit switching, we want to isolate each
traffic flow, so a misbehaving app doesn’t ruin the link
for everyone
– Principle 2: Some degree of isolation is
desirable to protect traffic flows from each
other
– This might imply the need for traffic cops, to ensure
app compliance
INFO 331 chapter 7
68
www.ischool.drexel.edu
A Sample Network
• So two approaches could address these
concerns and improve the QoS
– Mark packets, and police app behavior to
share bandwidth fairly
– Or, logically isolate traffic flows, and
designate some specific bandwidth for each
• But if the flows are isolated, need to make
sure full bandwidth is used if a traffic flow
isn’t active
INFO 331 chapter 7
69
www.ischool.drexel.edu
A Sample Network
– Principle 3: When traffic flows are isolated, need
to use resources (bandwidth, router buffers) as
efficiently as possible
• Scenario 4: Two 1.0 Mbps audio apps over a 1.5
Mbps link
– Both audio apps can’t get the full bandwidth needed –
each would lose 25% of their packets
– To maintain any decent QoS level, the network
should allow or block the flow
• Telephones have done this for years!
INFO 331 chapter 7
70
www.ischool.drexel.edu
A Sample Network
– So to guarantee a minimum level of QoS we
need a call admission process
– Principle 4: a call admission process is
needed to admit or block calls from the
network, based on the call’s QoS
requirements
• Now that we have the principles of
guaranteeing QoS, look at how these are
implemented in the Internet
INFO 331 chapter 7
71
www.ischool.drexel.edu
Scheduling and Policing
• Recall at the link level, packets from
various flows are multiplexed and queued
on the output buffers to go onto a link
• The link-scheduling discipline is the
process for queuing packets, which is vital
for making QoS guarantees
• Look at FIFO, priority, round robin, and
WFQ approaches for link-scheduling
INFO 331 chapter 7
72
www.ischool.drexel.edu
FIFO Scheduling
• FIFO (first-in first-out), also called firstcome first-served (FCFS) is the
McDonald’s approach to scheduling
– Packets are queued in the order in which they
arrived at the device
– If the output buffer gets full, the packetdiscarding policy is used to decide which
packets are dropped
INFO 331 chapter 7
73
www.ischool.drexel.edu
Priority Queuing
• Here, packets are grouped by their priority – a
separate queue for each level of priority
– How they are grouped could be by type of service,
source IP, or other methods
• The highest priority queue is emptied before the
next priority queue is transmitted
– If the high priority queue is empty, a lower priority
packet will still be sent immediately
• Within each queue, FIFO applies
INFO 331 chapter 7
74
www.ischool.drexel.edu
Round Robin Queuing
• In round robin, packets are sorted into
classes which have no relative priority
– One packet from class 1 is sent, then one
from class 2, etc.
– Then go back to class 1 and keep repeating
the cycle
• A work-conserving round robin tries to
keep the link busy, so will check the next
class if one is empty
INFO 331 chapter 7
75
www.ischool.drexel.edu
Weighted Fair Queuing (WFQ)
• WFQ is a variation on round robin queuing
– Here each class is assigned a ‘weight,’ which
determines how much transmission time they
get
– In short, some classes are more equal than
others
– The weights for all classes total 100%
– Incoming packets are classified into the
correct class, which has its own queue
•
WFQ is very widely used
INFO 331 chapter 7
76
www.ischool.drexel.edu
Policing
• We may need to control the rate data are
allowed to enter the network – a traffic cop
• Could control three aspects
– Long term average data rate
– Peak or max rate
– Burst size – max number of packets in a short
time interval
INFO 331 chapter 7
77
www.ischool.drexel.edu
The Leaky Bucket Analogy
arriving
traffic
• Bucket holds ‘b’
tokens (packets)
• New tokens are
created at rate ‘r’
tokens per sec
• If bucket is full,
new tokens are
discarded
INFO 331 chapter 7
token rate, r
bucket size, b
WFQ
per-flow
rate, R
D = b/R
max
78
www.ischool.drexel.edu
The Leaky Bucket Analogy
• The token generation rate, r, limits the
long term average rate
• In any time ‘t’, the max number of tokens
which could be added to the network is
r*t + b, so that limits the peak rate
• The size of the bucket limits the max
burst size
– No more than b tokens can be removed
in a short time
INFO 331 chapter 7
79
www.ischool.drexel.edu
WFQ + Leaky buckets
• If we combine the WFQ scheduling with
the leaky bucket policing options, what
happens to the delay for any class of
packets?
– If the class’ bucket is full, and ‘b1’ packets
arrive, the rate the bucket is emptied is at
least R*wi/sum(w) where R is the link rate, wi
is the weight of this class, and sum(w) is the
sum of all active classes’ weights
INFO 331 chapter 7
80
www.ischool.drexel.edu
WFQ + Leaky buckets
• So the time for the bi packets to be
handled is time = quantity/rate
– di = bi/[R*wi/sum(w)]
– Hence there is a provable maximum delay
• As long as the rate this class can handle
packets is less than [R*wi/sum(w)], the
above di equation is the max delay in a
WFQ queue
INFO 331 chapter 7
81
www.ischool.drexel.edu
Integrated vs Differentiated
Services
• Now we’ve covered the types of
mechanisms needed to provide QoS
guarantees in the Internet
– Cool. So, how is this being implemented?
• Two major architectures are trying to
provide an answer – Intserv and Diffserv
– Integrated Services = Intserv
– Differentiated Services = Diffserv
INFO 331 chapter 7
82
www.ischool.drexel.edu
Intserv
• Intserv provides a way for QoS to be
specified for a given session
– Kind of like setting up a virtual circuit
• Intserv depends on two key features
– Must know what resources are already
occupied by routers along a desired path
– Must do call setup to prepare for a session
INFO 331 chapter 7
83
www.ischool.drexel.edu
Intserv
• Call setup includes
– A session must define the QoS needs
• An Rspec defines the type of QoS service desired
• A Tspec defines the traffic the session will be sending
– See RFC 2210 and 2215 for Rspec and Tspec
– Then a signaling protocol, RSVP, is used to set up
along the path’s routers
– Each router (element) decides whether to allow the
session
INFO 331 chapter 7
84
www.ischool.drexel.edu
Intserv
• Intserv provides two different types of QoS
– Guaranteed QoS – the bounds on queuing
delays for each router are assured
• See RFC 2212 for gory details how this is done
– Controlled-load Network Service – the
session will receive a “close approximation” to
the QoS an unloaded element would provide
• Oddly, this QoS is not quantified
• RFC 2211, since you were wondering
INFO 331 chapter 7
85
www.ischool.drexel.edu
Diffserv
• Diffserv (RFC 2475) was in response to
problems with Intserv:
– Scalability problems with per-flow (session)
reservations
• Gets very time consuming for large networks
– Flexibility in service classes – Intserv only
provides specific service classes
• Want ability to grade or rank service classes
(low/med/high, silver/gold/platinum, etc.)
INFO 331 chapter 7
86
www.ischool.drexel.edu
Diffserv
• Diffserv assumes the whole network will
be aware of Diffserv protocols, and that
most traffic flows are under Diffserv
– You will be assimilated!
• Two main functions under Diffserv
– At the edges of the network, hosts or first hop
routers mark the DS field in the packet header
– Within the core of the network, traffic is
handled based on its class’ per-hop behavior
INFO 331 chapter 7
87
www.ischool.drexel.edu
Diffserv
• Analogy
– The marking process is like getting your hand
stamped at a night club, or having a VIP or
backstage pass, or getting comped for
spending too much money at a casino
• Packets are classified based on source or
destination IP or port, or (transport)
protocol
– There could be different marking algorithms
for various classes of flows
INFO 331 chapter 7
88
www.ischool.drexel.edu
Diffserv
• Classes of flows could follow a traffic profile
– May limit their peak transmission rate, or burstiness
– A metering function could be used to control flow rate
into the network, or shape flow rates
• The differentiated services (DS) field (RFC
3260) replaces the type of service and traffic
class fields from IPv4 and IPv6
– The packets are marked using the DS field
INFO 331 chapter 7
89
www.ischool.drexel.edu
Diffserv
• Within the network, each class’ per-hop behavior
(PHB) is critical to controlling its handling
– PHB influences the forwarding behavior
(performance) at a Diffserv node
– No method for implementing behavior is given
– Only key is that they are externally measurable
• Two PHBs have been defined – expedited
forwarding (EF), and assured forwarding (AF)
INFO 331 chapter 7
90
www.ischool.drexel.edu
Diffserv
• Expedited forwarding (EF, RFC 3246) requires
the departure rate of a class must equal or
exceed a certain rate
– Implies isolation from other traffic classes, since the
absolute rate is guaranteed
• Assured forwarding (AF, RFC 2597) divides
traffic into four classes
– Each is guaranteed bandwidth and buffer space
– Per class there are three levels of drop preference
INFO 331 chapter 7
91
www.ischool.drexel.edu
Intserv, Diffserv, and Reality
• So while techniques exist to provide QoS
guarantees, they aren’t widely used
• Why? The Internet is highly distributed,
and not everyone will agree 1) to
implement QoS methods, 2) on the type of
QoS needed, and 3) on how to pay for it
• And if traffic levels are low, ‘best effort’ will
provide the same service as
Intserv/Diffserv!
INFO 331 chapter 7
92
www.ischool.drexel.edu
Summary
• Multimedia is huge in the Internet, and
getting bigger!
– May replace circuit switched telephones
• Here we reviewed the types of multimedia
apps, looked at methods for best-effort
networking, added methods for QoS
guarantees, and outlined architectures for
providing QoS
INFO 331 chapter 7
93
www.ischool.drexel.edu