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