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:
Quality of Service
Slide 360
Slide 361
Principles for QOS Guarantees
Principles for QOS Guarantees
(more)
Consider a phone application at 1Mbps and an FTP application
Applications misbehave (audio sends packets at a rate higher
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
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:
distinguish between different classes; and new router
policy to treat packets accordingly
Slide 362
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
Slide 364
Slide 363
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
Slide 365
Scheduling And Policing
Mechanisms
Summary
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
Slide 366
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
Slide 367
Scheduling Policies (more)
Round Robin: scan class queues serving one
from each class that has a non-empty
queue
Slide 368
Scheduling Policies (more)
Slide 369
Policing Mechanisms
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
Slide 370
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
Slide 371
Integrated Services
Integrated Services: Classes
An architecture for providing QOS guarantees in IP
Guaranteed QOS: this class is provided
networks for individual application sessions
relies on resource reservation, and routers need to maintain
state info (Virtual Circuit??), maintaining records of
allocated resources and responding
to new Call
setup
requests
on that
basis
with firm bounds on queuing delay at a
router; envisioned for hard real-time
applications that are highly sensitive to
end-to-end delay expectation and variance
Controlled Load: this class is provided a
QOS closely approximating that provided
by an unloaded router; envisioned for
todays IP network real-time applications
which perform well in an unloaded network
Slide 372
Slide 373
Differentiated Services
Differentiated Services
Intended to address the following difficulties
with Intserv and RSVP;
Scalability: maintaining states by routers in high
speed networks is difficult sue to the very large
number of flows
Flexible Service Models: Intserv has only two
classes, want to provide more qualitative service
classes; want to provide relative service
distinction (Platinum, Gold, Silver, )
Simpler signaling: (than RSVP) many applications
and users may only w ant to specify a more
qualitative notion of service
Approach:
Only simple functions in the core, and relatively
complex functions at edge routers (or hosts)
Do not define service classes, instead provides
functional components with which service
classes can be built
Slide 374
Slide 375
Forwarding (PHB)
Forwarding (PHB)
PHB result in a different observable
PHBs under consideration:
Expedited Forwarding: departure rate of
packets from a class equals or exceeds a
specified rate (logical link with a minimum
guaranteed rate)
Assured Forwarding: 4 classes, each
guaranteed a minimum amount of bandwidth
and buffering; each with three drop preference
partitions
(measurable) forwarding performance
behavior
PHB does not specify what mechanisms to
use to ensure required PHB performance
behavior
Examples:
Class A gets x% of outgoing link bandwidth over
time intervals of a specified length
Class A packets leave first before packets from
class B
Slide 376
Slide 377
Differentiated Services Issues
AF and EF are not even in a standard track
yet research ongoing
Multimedia Networking
Virtual Leased lines and Olympic
services are being discussed
Impact of crossing multiple ASs and
routers that are not DS-capable
Slide 378
Slide 379
Multimedia in Networks
Multimedia in networks (2)
Fundamental characteristics:
Typically delay sensitive
delay.
But loss tolerant:
infrequent losses cause
minor glitches that can be
concealed.
Antithesis of data
(programs, banking info,
etc.), which are loss
intolerant but delay
tolerant.
Multimedia is also called
continuous media
Streaming stored MM
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
Classes of MM applications:
Streaming stored audio and
video
Streaming live audio and
video
Real-time interactive video
Slide 380
Unidirectional Real-Time:
similar to existing TV and
radio stations, but delivery
over the Internet
Non-interactive, just
listen/view
Interactive Real-Time :
Phone or video conference
More stringent delay
requirement than Streaming
& Unidirectional because of
real-time nature
Video: < 150 msec acceptable
Audio: < 150 msec good, <400
msec acceptable
Slide 381
Multimedia in networks (3):
challenges
Multimedia in networks (4):
making the best of best effort
TCP/UDP/IP suite provides
To mitigate impact of besteffort Internet, we can:
Use UDP to avoid TCP and
its slow-start phase
Buffer content at client
and control playback to
remedy jitter
We can timestamp packets,
so that receiver knows
when the packets should be
played back.
Adapt compression level to
available bandwidth
best-effort, no guarantees
on delay or delay variation.
Streaming apps with initial
delay of 5-10 seconds are
now commonplace, but
performance deteriorates
if links are congested
(transoceanic)
Real-Time Interactive
apps have rigid
requirements for packet
delay and jitter.
Jitter is the variability of
packet delays within the
same packet stream.
Design or multimedia apps
would be easier if there
were some 1st and 2nd
class services.
But in the public Internet,
all packets receive equal
service.
Packets containing realtime interactive audio and
video stand in line, like
everyone else.
There have been, and
continue to be, efforts to
provide differentiated
service.
Slide 382
We can send redundant
packets to mitigate the
effects of packet loss.
We will discuss all these
tricks.
Slide 383
How should the Internet evolve to
better support multimedia?
Integrated services philosophy:
Change Internet protocols
so that applications can
reserve end-to-end
bandwidth
Need to deploy protocol
that reserves bandwidth
Must modify scheduling
policies in routers to honor
reservations
Application must provide
the network with a
description of its traffic,
and must further abide to
this description.
Differentiated services
philosophy:
Fewer changes to Internet
infrastructure, yet provide
1st and 2nd class service.
Datagrams are marked.
User pays more to
send/receive 1st class
packets.
ISPs pay more to
backbones to send/receive
1st class packets.
How should the Internet evolve to
better support multimedia? (cont.)
Laissez-faire philosophy
No reservations, no
datagram marking
As demand increases,
provision more
bandwidth
Place stored content
at edge of network:
Requires new, complex
software in hosts & routers
Slide 384
Streaming Stored Audio & Video
Streaming stored media:
Audio/video file is
stored in a server
Users request
audio/video file on
demand.
Audio/video is
rendered within, say,
10 s after request.
Interactivity (pause,
re-positioning, etc.) is
allowed.
Media player:
ISPs & backbones add
caches
Content providers put
content in CDN nodes
P2P: choose nearby peer
with content
Virtual private networks
(VPNs)
Reserve permanent
blocks of bandwidth
for enterprises.
Routers distinguish
VPN traffic using IP
addresses
Routers use special
scheduling policies to
provide reserved
bandwidth.
Slide 385
Streaming from Web server (1)
Audio and video files
removes jitter
decompresses
error correction
graphical user interface
with controls for
interactivity
Plug-ins may be used
to imbed the media
player into the
browser window.
stored in Web servers
nave approach
browser requests file with
HTTP request message
Web server sends file in
HTTP response message
content-type header line
indicates an audio/video
encoding
browser launches media
player, and passes file to
media player
media player renders file
Major drawback: media player
interacts with server through
intermediary of a Web browser
Slide 386
Streaming from Web server (2)
Alternative: set up connection
between server and player
Web browser requests and
receives a meta file
(a file describing the
object) instead of
receiving the file itself;
Content-type header
indicates specific
audio/video application
Browser launches media
player and passes it the
meta file
Player sets up a TCP
connection with server and
sends HTTP request.
Slide 387
Streaming from a streaming
server
This architecture
allows for non-HTTP
protocol between
server and media
player
Can also use UDP
instead of TCP.
Some concerns:
Media player communicates
over HTTP, which is not
designed with pause, ff,
rwnd commands
May want to stream over
UDP
Slide 388
Slide 389
Real Time Streaming Protocol:
RTSP
HTTP
Designers of HTTP had fixed
media in mind: HTML, images,
applets, etc.
HTTP does not target stored
continuous media (i.e., audio,
video, SMIL presentations,
etc.)
RTSP: RFC 2326
Client-server application
layer protocol.
For user to control display:
rewind, fast forward,
pause, resume,
repositioning, etc
What it doesnt do:
does not define how
audio/video is encapsulated
for streaming over network
does not restrict how
streamed media is
transported; it can be
transported over UDP or
TCP
does not specify how the
media player buffers
audio/video
RealNetworks
Server and player use RTSP
to send control info to each
other
Slide 390
Internet phone over besteffort (1)
Best effort
packet delay, loss and
jitter
Internet phone example
now examine how packet
delay, loss and jitter are
often handled in the
context of an IP phone
example.
Internet phone applications
generate packets during
talk spurts
bit rate is 64 kbps during
talk spurt
during talk spurt, every 20
msec app generates a
chunk of 160 bytes =
8 kbytes/sec * 20 msec
header is added to chunk;
then chunk+header is
encapsulated into a UDP
packet and sent out
some packets can be lost
and packet delay will
fluctuate.
receiver must determine
when to playback a chunk,
and determine what do
with missing chunk
Real-Time Protocol
(RTP)
RTP specifies a packet
structure for packets
carrying audio and
video data: RFC 1889.
RTP packet provides
payload type
identification
packet sequence
numbering
timestamping
PC-2-PC phone
PC-2-phone
Dialpad
Net2phone
videoconference
Webcams
Going to now look at a
PC-2-PC Internet
phone example in
detail
Slide 391
Internet phone (2)
Slide 392
Real-time interactive
applications
packet loss
UDP segment is
encapsulated in IP
datagram
datagram may overflow a
router queue
TCP can eliminate loss, but
retransmissions add delay
TCP congestion control
limits transmission rate
Redundant packets can help
end-to-end delay
accumulation of
transmission, propagation,
and queuing delays
more than 400 msec of
end-to-end delay seriously
hinders interactivity; the
smaller the better
delay jitter
consider two consecutive
packets in talk spurt
initial spacing is 20 msec,
but spacing at receiver can
be more or less than 20
msec
removing jitter
sequence numbers
timestamps
delaying playout
Slide 393
RTP runs on top of UDP
RTP runs in the end
systems.
RTP packets are
encapsulated in UDP
segments
Interoperability: If
two Internet phone
applications run RTP,
then they may be able
to work together
Slide 394
RTP libraries provide a transport-layer interface
that extend UDP:
port numbers, IP addresses
error checking across segment
payload type identification
packet sequence numbering
time-stamping
Slide 395
RTP Example
Consider sending 64
kbps PCM-encoded
voice over RTP.
Application collects
the encoded data in
chunks, e.g., every 20
msec = 160 bytes in a
chunk.
The audio chunk along
with the RTP header
form the RTP packet,
which is encapsulated
into a UDP segment.
RTP Streams
RTP allows each source (for
example, a camera or a
microphone) to be assigned
its own independent RTP
stream of packets.
For example, for a
videoconference between
two participants, four RTP
streams could be opened:
two streams for
transmitting the audio
(one in each direction) and
two streams for the video
(again, one in each
direction).
RTP and QoS
RTP header indicates
type of audio encoding
in each packet;
senders can change
encoding during a
conference. RTP
header also contains
sequence numbers and
timestamps.
Slide 396
RTP does not provide any
mechanism to ensure timely
delivery of data or provide
other quality of service
guarantees.
RTP encapsulation is only
seen at the end systems -it is not seen by
intermediate routers.
In order to provide QoS to
an application, the Internet
most provide a mechanism,
such as RSVP, for the
application to reserve
network resources.
Routers providing the
Internet's traditional
best-effort service do not
make any special effort to
ensure that RTP packets
arrive at the destination in
a timely matter.
Slide 397
However, some popular encoding
techniques -- including MPEG1
and MPEG2 -- bundle the audio
and video into a single stream
during the encoding process.
When the audio and video are
bundled by the encoder, then
only one RTP stream is
generated in each direction.
For a many-to-many multicast
session, all of the senders and
sources typically send their RTP
streams into the same
multicast tree with the same
multicast address.
Slide 398
