ECE544: Communication Networks-II,

Spring 2015
D. Raychaudhuri
Lecture 8 (QoS)

Includes teaching materials from D. Raychaudhuri, L. Peterson

Todays Lecture
Congestion control in best effort
networks
Basic principles & mechanisms
FQ, WFQ, congestion feedback, TCP,
RED

Quality-of-service (QoS)
Mechanisms (traffic shaping,
admission control, reservation,
priority queuing)
RSVP Intserv and Diffserv, RIO
Comparison to ATM (CBR, VBR; ABR)

Congestion Control & QoS in

Packet Networks
Congestion control reactive methods
used in best effort networks
Packet scheduling at network nodes
Feedback congestion control
End-to-end
Hop-by-hop

QoS control proactive methods used

for premium or guaranteed services:
Source traffic shaping & policing at entry
points
Priority queuing and packet drop at routers
End-to-end reservation and admission
control

Network Congestion

All networks have saturating throughput

Reduction in performance beyond max
capacity
Need to keep input load below G0
Also must avoid unstable equilibrium point in overload
Unstable network load
region

Smax
Thru

Capacity Limit
Traffic
margin

Overload
region
Congestion control policies

Normal operating
Point (G0)

Offered Traffic (G)

Stable network load lines

with congestion control

Queue Scheduling
A queue scheduler employs 2
strategies:
Scheduling discipline: Which packet to
serve (transmit) next
Drop policy: Which packet to drop
next (when required)

FIFO Queuing
FIFO:first-in-first-out (or FCFS: firstcome-first-serve)
Arriving packets get dropped when
queue is full regardless of flow or
importance - implies drop-tail
Important distinction:
FIFO: scheduling discipline
Drop-tail: drop policy

Fair Queuing
Main idea:
maintain a separate queue for each
flow currently flowing through router
router services queues in RoundRobin fashion

FQ illustration
Flow 1
Flow 2
I/P

O/P

Flow n
Variation: Weighted Fair Queuing (WFQ)

Some Complications
Packets are of different length
We really need bit-by-bit roundrobin (RR)
FQ simulates bit-by-bit RR
Not feasible to interleave bits!

Bit-by-bit RR
Single flow: suppose clock ticks when a bit is
transmitted. For packet i:
Pi: length, Ai = arrival time, Si: begin transmit time, Fi:
finish transmit time. Fi = Si+Pi
Fi = max (Fi-1, Ai) + Pi

Multiple flows: clock ticks when a bit from all

active flows is transmitted, that is, the clock
advances by one tick when n bits are transmitted
(assuming n flows)
calculate Fi for each packet
transmit packet with earliest Fi

RR is only simulated, packet in transmission is not

interrupted.
If n flows have data to transmit, each gets 1/nth
bandwidth.

Bit-by-bit RR
Start with A(*,*)=0 (all pkts arrive at T=0)
Flow 1

Pkt 1-3=
1 unit
Pkt 1-2=
1 unit

Flow 2

P(1,1) = 2
P(1,2) = 1
P(1,3) = 1

F(1,1) = 1
F(1,2) = 1.5
F(1,3) = 2

Pkt 2-2=2 units

Pkt 1-1=2 units

1-1

F(2,1) = 1.5
F(2,2) = 2.5

Fi = max (Fi-1, Ai) + Pi

Pkt 2-1=3 units

Channel clock -

P(2,1) = 3
P(2,2) = 2

2-1

1-2 1-3 2-2

Weighted Fair Queuing (WFQ)

Weighted Fair Queuing (WFQ): assign a weight
to each flow
Assume transmitting wq bits each time the
router serves queue q (simulate in packet
scheduling)
Control the percentage of the links
bandwidth that a flow will get
The bandwidth that flow q gets (n active queues
wq
sending data):

Bq

w
q 1

Congestion Control and Congestion Avoidance

Source
Rate
(bps)

TCPs blind approach:

Detect congestion (loss) after it happens and back off on
offered rate
Increase load trying to maximize utilization until loss
occurs
Congestion detected
(via packet loss)

Time-out

Alternatively:
We can try to predict congestion and reduce rate before
packets start being discarded
This is called congestion avoidance

Congestion Control via

Router Feedback
Router has unified view of queuing
behavior
Routers can distinguish between
propagation and persistent
queuing delays
Routers can decide on transient
congestion, based on workload

Solving the Full Queues

Problem
Router monitors the load
Drop (or mark) packets before
queue becomes full (early drop)
Intuition: notify senders of incipient
congestion
Simple example:
If qlen > drop level, drop (or mark) each
new packet with a fixed probability p
Does not control misbehaving users

Random Early Detection

(RED)
Motivation:
High bw-delay flows have large
queues to accommodate transient
congestion
TCP detects congestion from loss after queues have built up and
increase delay

Aim:
Keep throughput high and delay low
Accommodate bursts

Random Early Detection

(RED)
Detect incipient congestion, allow
bursts
Keep power (throughput/delay) high
keep average queue size low
assume hosts respond to lost packets

Avoid window synchronization

randomly mark packets, instead of
dropping

Avoid bias against bursty traffic

RED Algorithm
Maintain running average of queue
length
If avg < minth do nothing
Low queuing, send packets through

If avg > maxth, drop all packets

Protection from misbehaving sources

Else randomly drop (or mark) some

packets in a manner proportional to
queue length
Notify sources of incipient congestion

RED Operation
If AvgLen <= MinThreshold
Max
threshold

Min
threshold

Queue the packet

If MinThreshold < Avglen <

MaxThreshold
Calculate probability P
Drop the arriving packets with probability P

If Avglen >= MaxThreshold

Drop the arriving packet
Average queue
length

AveLen = (1-W) x AveLen + W x

SampleLen

( AvgLen MinThresho ld )
( MaxThreshold MinThresho ld )
P TemP /(1 count TempP )

TempP MaxP

P(drop)

1.0

MaxP
minthresh

maxthresh

Count:# of newly arriving packets that

have been queued (not dropped) while
Avg length AvgLen has been between the two
thresholds
Count increases, P increases
Make drop more evenly distributed (Avoid
bias against bursty traffic)

Explicit Congestion Control

0

4
Version

8
HLen

16
TOS

31
Length

Ident
TTL

19

Flags
Protocol

Offset
Checksum

SourceAddr
DestinationAddr
Options (variable)

Pad
(variable)

Data

ToS field => now used for

DiffServ and ECN
Bits 0-5: Differentiated
Services Code Point (DSCP)
Bit 6: ECN-capable
Bit 7: ECN

Router can signal the

congestion by marking
packets instead of
dropping using RED
Set the ECN bit (bit 7 of
the IP TOS field) in IP
header

The destination copies

the ECN bit into the
ACK sent back to the
source
The source TCP
responds to the ECN
bit set in the same way
as a packet drop

Quality of Service
Outline
Realtime Applications
Integrated Services
Differentiated Services

Realtime Applications
Microphone

Sampler,
A D
converter

Buffer,
D A
Speaker

Require deliver on time assurances

must come from inside the network
Example application (audio)
sample voice once every 125us
each sample has a playback time
packets experience variable delay in network
add constant factor to playback time: playback point
Use initial buffering delay to compensate jitter, but
result in longer end-to-end delay

Playback Buffer

Sequence number

Packet
arrival
Packet
generation

Playback

Network
delay

Time

Buffer

Example Distribution of
Delays
90% 97% 98%

Packets (%)

99%

50

100
Delay (milliseconds)

150

200

Application requirements & Services Classes

Different application requirements

Elastic: no restrict delay requirements, traditional data

Real-time: delay bound, jitter, loss

Loss: intolerant or tolerant to some loss

Delay: adaptive (e.g. lengthening/shortening the silence between
words, playing back video a little slower, etc) or not adaptive
Data rate: adaptive (e.g. reduce video quality by compressing video
more) or not adaptive

Different application requirements=>different service

classes (not only best effort anymore)
A network that can provide these different levels of service is
said to support QoS
Integrated service: fine-grained approach, provide QoS to
individual applications or flows

Allow individual application flows to specify their needs to the

routers using an explicit signaling mechanism (RSVP)
Scalability is an issue

Differentiated Service: coarse-grained approach, provide QoS to

several classes of data or aggregated traffic
Assign packets into a small number of classes that receive
differentiated treatment in the routers

Taxonomy of applications
Applications
Real-Time
Loss, delay
tolerant
adaptive

Delay
adaptive

Non-adaptive

Rate
adaptive

Elastic
Intolerant

Interactive
Rate
adaptive

Non-adaptive

Asynchronous

Interactive-bulk

Components of Integrated Services

architecture
Flowspec: information of the flow traffic
characteristics and its service
Reservations (includes reservation signaling
protocol)
Admission control based on flow description and
current load
Scheduling to meet the reservation
Traffic shaping at edges to fit reservation
Traffic policing to mark or drop non-conforming
traffic
Some application adaptation

Types of guarantees
Absolute bound on delay and jitter
Absolute bound on delay only
Statistical bound on delay
No quantitative delay bound but
admission control and preferential
treatment
None

Internet service classes proposed by

IETF
Guaranteed service
firm bounds on e2e delays and bandwidth

Controlled load
a QoS closely approximating the QoS that
same flow would receive from an unloaded
network element, but uses capacity
(admission) control to assure that this
service is received even when the network
element is overloaded
Use a queuing mechanism such as WFQ to isolate
the controlled load traffic from other traffic
Admission control to limit the total amount of
controlled load traffic

Best effort

Overview of mechanisms
Flow specification (flowspec)
type of service we require

Admission control
can the network provide the
requested service?

Resource reservation protocol

RSVP

Packet scheduling

Flowspecs
Tspec: describes the flows traffic
characteristics
Rspec: describes the service
requested from the network

Traffic Shaping
Traffic shaping: control traffic in order to
conform to the traffic contract by delaying
packets to meet certain criteria.

To optimize or guarantee performance (lower

latency, higher usable bandwidth)
commonly applied at the network edges to control
traffic entering the network, but can also be applied
by the traffic source or in the network

Token bucket

tokens are placed in bucket at rate r

if bucket fills, tokens are discarded
sending a packet of size P uses P tokens
if bucket has P tokens, packet sent at max rate,
else must wait for tokens to accumulate

Traffic Policing
Traffic policing: router monitors the flow traffic
for conformity with a traffic contract
Drop or tag the packets not conforming to the TSpec
that used to make the reservation
to enforce compliance with that contract

Token bucket
tokens are placed in bucket at rate r
if bucket fills, tokens are discarded
When a packet of p bytes arrives, p tokens are
removed from the bucket, and the packet is sent to
the network.
If fewer than p tokens are available, no tokens are
removed from the bucket, and the packet is
considered to be non-conformant.
Drop or mark the non-conformant packets

Token bucket filter

Described by 2 parameters:
token rate r: rate of tokens placed in the
bucket
bucket depth B: capacity of the bucket

Operation:

tokens are placed in bucket at rate r

if bucket fills, tokens are discarded
sending a packet of size P uses P tokens
if bucket has P tokens, packet sent at max
rate, else must wait for tokens to
accumulate

Token bucket operation

tokens
overflow

tokens

tokens

Packet
Enough tokens
packet goes through,
tokens removed

Packet

Not enough
tokens - wait for
tokens to
accumulate

TB characteristics
On the long run, rate is limited to r
On the short run, a burst of size B
can be sent at peak data rate
Amount of traffic entering at
interval T is bounded by:
traffic = B + r*T

Information useful to admission

algorithm

Token bucket specs

Flow A: r = 1 Mbps, B=1 byte

BW
2

Flow B

Flow B: r = 1 Mbps, B=1MB

Flow A

Time

Admission control
When new flow request arrives,
look at Rspec and Tspec and
decide whether to admit or reject
Can it provide the desired service
requested by the flow, given the
currently available resources without
causing any previously admitted flow
to receive worse service that agreed?

Not policing

Reservation protocol: RSVP

Upper layer protocols and applications
IP service interface
IP

ICMP IGMP RSVP

Link layer service interface

Link layer modules

RSVP
Used on connectionless networks
Relies on soft state: reservations
must be refreshed and do not have
to be explicitly deleted
Aims to support multicast as
effectively as unicast flows - mcast
apps good candidates for realtime, and are heterogeneous
Receiver-oriented approach

Basic message types

PATH message
RESV message
CONFIRMATION message
generated only upon request
unicast to receiver when RESV
reaches node with established state

TEARDOWN message
ERROR message (if path or RESV
fails)

Making a reservation
Receivers make reservation
Before making a reservation,
receiver must know:
type of traffic sender will send (Tspec)
path the senders packets will follow

Both can be accomplished by

sending PATH messages by the
sender

PATH messages
PATH messages carry senders Tspec
and sent from the sender to the receiver
Record the path from the sender to the
receiver in the PATH message
Receivers send RESV messages that
follow reverse path and setup
reservations
If reservation cannot be made, user gets
an error

PATH and RESV messages

Sender 1

Sender 2

PATH

R
PATH

RESV (merged)

RESV

receiver 1

RESV
receiver 2

Soft State
Allow increasing or decreasing the level of
resource reservation
Adapt to link or router failure and topology
changes
Routing protocol makes routing changes, RSVP
adjusts reservation state
In absence of route or membership changes,
periodic PATH and RESV msgs refresh
established reservation state
When change, new PATH msgs follow new path,
new RESV msgs set reservation
Non-refreshed state times out automatically

Router handling of RESV

messages
If new request rejected, send error
message
If admitted:
install packet filter into forwarding
dbase
pass flow parameters to scheduler
activate packet policing if needed
forward RESV msg upstream

Packet classifying and

scheduling
Each arriving packet must be:
classified: associated with the
application reservation
Examining up to five fields in the packet:
source + destination address, protocol
number, source + destination port

scheduled: managed in the queue so

that it receives the requested service
implementation not specified in the
service model

RSVP and multicast

Reservations from multiple receivers for
a single sender are merged together at
branching points
Reservations for multiple senders may
not be added up:
audio conference, not many talk at same
time
Different reservation styles:
Reserve resources for all speakers
Reserve resources for any n speakers
Reserve resources for speakers A and B only

RSVP versus ATM (Q.2931)

RSVP

receiver generates reservation

soft state (refresh/timeout)
separate from route establishment
QoS can change dynamically
receiver heterogeneity

ATM

sender generates connection request

hard state (explicit delete)
concurrent with route establishment
QoS is static for life of connection
uniform QoS to all receivers

ATM Service Categories

CBR
Constant Bit Rate
Continuous flow of data with tight bounds on delay and delay
variation

rt-VBR
Real-Time Variable Bit Rate
Variable bandwidth with tight bounds on delay and delay
variation

nrt-VBR
Non-Real-Time Variable Bit Rate
Variable bandwidth with tight bound on cell loss

UBR
Unspecified Bit Rate
No guarantees (i.e., best effort delivery)

ABR
Available Bit Rate
Flow control on source with tight bound on cell loss

Differentiated Services
(DiffServ)

Analogy:
airline service, first class, coach,
various restrictions on coach as a
function of payment
Best-effort expected to make up bulk of
traffic, but revenue from premium
service important to economic base (will
pay for more plentiful bandwidth
overall)
Not motivated by real-time,
motivated by economics and

Differentiated Services (cont)

Divide traffic into a small number of
classes and allocates resource on a perclass basis, instead of individual flows
Scalable

No need for reservations: just mark

packets
E.g. packet marking can be done at
administrative boundaries before
injecting packets into network

Significant savings in signaling, much

simpler overall

IP DiffServ
0

4
Version

8
HLen

16
TOS

31
Length

Ident
TTL

19

Flags
Protocol

Offset
Checksum

SourceAddr
DestinationAddr
Options (variable)

Pad
(variable)

Data

ToS field => now used for

DiffServ and ECN
Bits 0-5: Differentiated
Services Code Point (DSCP)
Bit 6: ECN-capable
Bit 7: ECN

IP packets carry 6-bit

service code points
(DSCP)
Potentially support
64-different classes of
services
In implementation,
the number of DSCPs
used in a network is
much smaller, e.g.
simple two-class
network

DiffServ
Where and how to set the DSCP value

Host set DSCP based on knowledge of application

requirements
Router at an administrative boundary set DSCP
according to a certain policy

What does a router do when it receives a

packet marked with a certain DSCP
Routers map DSCP to per-hop-behavior (PHB)
PHBs can be standard or local
Standard PHBs include

Default: No special treatment or best effort

Expedited forwarding (EF): should be forwarded with
low delay and loss
Assured forwarding (AF): Multiple classes, each class
with multiple drop preference

Expedited Forwarding (EF)

A router should forward the EF packets
with minimal delay and low loss
To implement, put all EF packets in a
dedicated EF queue and ensure that the
arrival rate of packets to the queue is
less than the service rate
Configure the router at the edge of an
administrative domain to allow a certain
max rate of EF packets arrivals into the
domain

Limit the EF packet rate < the bandwidth of the

slowest link in the domain

Give EF packet queue high priority, e.g.

WFQ with a high weight to EF queue

Assured Forwarding (AF)

A set of AF PHBs is defined
AFxy:
x: class, typically determine a queue for the
packet
y:drop preference
For example: AF11, AF12 and AF13 packets
are put into the same queue, but AF13
would have a greater chance to be dropped
due to congestion. AF11 and AF2y would go
to different queues

12 AF PHBs are recommended by IETF, 4

AF classes with three drop preference

An Example DiffServ Network

Implementation
Support Two-type DiffServ
Premium (expedited) service: (type P)
User sends within profile, network commits to
delivery with the agreed profile
Classify packet in one of two queues, use priority
Shaping at trust boundaries only, using token bucket

Allocate resource based on the agreed peak rate

conservative, virtual wire services
unused premium goes to best effort (subsidy!)

Assured service: (type A)

based on expected capacity usage profiles
traffic unlikely to be dropped if user maintains
profile. Out-of-profile traffic marked

Premium traffic flow

Company A
Packets in premium
flows have bit set
internal
router

host
first hop
router
Unmarked
packet flow

Premium packet flow

restricted to R bytes/sec

ISP
border
router
border
router

2-bit differentiated service

Use precedence field to encode P & A
type packets
P packets are queued at higher priority
than ordinary best effort
A packets treated preferentially wrt
dropping probability in the normal
queue
Leaf and border routers have input and
output tasks - other routers just output

Leaf router input functionality

Marker 1

Marker N
Arriving
packet

Clear
A&P
bits

Packet
classifier

Best effort

Forwarding
engine

Marker: Leaf routers have traffic profiles - they classify packets

based on packet header (destination addr & port, source addr
& port, protocol ID, etc)
If no profile present, pass as best effort
If profile is for A:
mark in-profile packets with A, forward others unmarked
If profile is for P:
delay out-of -profile packets to shape into profile

Markers to implement two different

services
P service
Drop on overflow
Packet
input

Wait for
token

Set P bit

Packet
output

A service
No token
Packet
input

Test if
token

token
Set A bit

Packet
output

Router output interface for two-bit

architecture
2 queues: P packets on higher priority queue
Lower priority queue implements RED In or
Out scheme (RIO)

P-bit set?

yes

High-priority Q
Packets out

no
If A-bit set
incr A_cnt

Low-priority Q
RIO queue
management

If A-bit set
decr A_cnt

Border router input interface Profile Meters

At border routers, profile meters test marked flows:
drop P packets out of profile
unmark A packets

A set
Arriving
packet

Is packet
marked?

Token
available?

no

Clear A-bit
token
Forwarding
engine

Not marked

token

P set
Token
available?

no

Drop packet

Red with In or Out (RIO)

Similar to RED, but with two separate probability curves

Has two classes, In and Out (of profile)
Out class has lower Minthresh, so packets are dropped from
this class first
As avg queue length increases, in packets are dropped

P(drop)

1.0

MaxP
Minout

AvgLen
Minin

Maxout

Maxin

Todays Homework
Chapter 6
-6.13
4th ed
-6.32
-6.43
-6.44
Due 4/3/15
65