Resource allocation in networks
Very
Resource Allocation in
Networks
much like a resource allocation
problem in operating systems
How is it different?
Resources
and jobs are different
Resources are buffers and link bandwidth
Jobs are flows
CPU
scheduling in OS Packet
scheduling in networks
Resource allocation..
We
can categorize resource allocation
approaches in different ways:
Router
based Versus Host based
Feedback based Versus Reservation based
Window based Versus Rate based
Seems
like we might have 8 classes
In actual practice, only two: best effort and
QoS
Resource allocation
Several approaches presented in the literature:
Best effort: no commitment about QoS
Better than best effort: services make no deterministic
guarantees about delay, but make a best effort for
supporting QoS
Guaranteed throughput: provides strict QoS
compliance
Bounded delay jitter: service guarantees upper and
lower bounds on observed packet delays
Granularity of Resource Allocation
on the management granularity, we
can classify the approaches into three
classes:
Packet
level
Flow level
Flow aggregate level
This
is mainly concerned with packet
queueing, and packet scheduling at
switches, routers, etc.
Objective: provide different treatments at
the packet level so that some flows
(applications) will receive better service
QoS Concerns with Packet
Scheduling
End-to-end
delay is the sum of all the per
QoS concerns..
Jitter
is the variability of delay. It is a
major concern as well. Why?
End-to-end
delay can be bounded by
upper bounding the delay at each hop
Cumulative data
hop delays
constant bit
rate
transmission
variable
network
delay
(jitter)
client
reception
constant bit
rate playout
at client
buffered
data
Based
Packet Level Resource Allocation
client playout
delay
time
QoS concerns..
Packet
loss: happens when there is no
more room in the buffers
Causes for packet loss:
Overview of a Packet scheduler
Purpose of Packet scheduling is to control the amount
of resources provided for the different traffic flows
Packets
in packet input rate
Congestion downstream
Packet header
Surge
Data memory
Packet in
Packet out
Address
Write/read
Packet scheduler
CPU
Queuing Disciplines
Queuing
algorithms allocate three nearly
independent quantities:
bandwidth
(which packets get transmitted)
promptness (when packets get transmitted)
buffer space (which packets are discarded by
the gateway)
Packet search
Engine
Queuing Disciplines
Simplest queuing
algo.:
FCFS (first come first
serve)
order of arrival
determines the
bandwidth,
promptness, and
buffer space
allocations
congestion control
relegated to the
sources
Queuing Disciplines
FIFO
with tail drop
use
FIFO scheme
when the buffer space is full, drop the next
packet that arrives at the router
Problem
Fair Queuing
Maintain a separate queue for each flow
Service the queues in a round-robin fashion
when queue reaches a particular length, additional
packets for the flow are discarded -- flow cannot
increase it share of the bandwidth by increasing flow rate
with FCFS:
single
source sending traffic at an arbitrarily
high rate captures a good portion of the
output bandwidth
congestion control may not be fair with illbehaved sources
Queuing Disciplines
Pure
Bit-by-Bit Vs. Packet-by-Packet
allocation of round-robin service
provides
a fair allocation of packets-sent
due to varying packet sizes, does not
guarantee fair allocation of bandwidth
Bit-by-bit
round-robin (BR)
(Equal sized packets
in the buffers)
allocates
bandwidth fairly
not very practical -- only a hypothetical
scheme
Bit-by-Bit Vs. Packet-by-Packet
Packet-by Packet Fair Queuing
Let
(Unequal sized packets
in the buffers)
R(t) denote the number of rounds
made in the round-robin service discipline
up to time t
A packet of size P whose first bit is
serviced at t0 will have its last bit serviced
after P rounds
at
each round one bit of the packet is serviced
R( t ) = R( t 0 ) + P
when
there are more active flows the time per
round will be longer than with fewer flows
Packet-by Packet Fair Queuing
Let t i
be the time packet i belonging to
flow arrives at the router
Let Si be the starting time of the packet
Let Fi be the finishing time of the packet
Let Pi be the packet length
Following relations hold: Fi = Si + Pi
Si = max(Fi1 + R( ti ))
Packet-by Packet Fair Queuing
For
packet-by-packet approximation:
use Fi
in defining the sending order
whenever a packet is finished sending, the
next packet for transmission should be with
the smallest Fi
Preemptive
version:
arriving packets with less Fi can
preempt and ongoing packet transmission -difficult to analyze analytically
newly
Weighted Fair Queueing
Addresses
the reality that different users
have different QoS requirements.
Weight the queues differently. Some
queues have more weight and others less.
(weight 1)
(weight 3)
Buffer mgmt. and Packet Drop
Although
FQ provides separate buffers, it
is rarely implemented at core routers.
With FIFO/FCFS, we need buffer
management:
Tail
drop
Drop on full
Random early drop (RED)
RIO (RED with In-Out)
Packet Drop Policies
Tail
Drop
Sets
a maximum queue length
Drops all incoming packets after the queue
length has reached maximum
Is simple but has two major drawbacks: (a)
allows a single flow to monopolize and (b)
allows queues to build up to the maximum
size and create prolonged lower link utilization
Packet Drop Policies
Drop
on Full:
Can
be either random drop on full or drop
front on full.
Both solve the monopolization problem
Does not solve the queue becoming full
problem.
Random early detection (RED) was proposed
to address this problem.
Random Early Detection (RED)
When there is congestion, buffers fill up and
routers begin to drop packets
TCP traffic -- goes into slow start -- reduces the
network traffic -- relieves congestion
Problems:
lost packets should be retransmitted
additional load and significant delays
global synchronization: several TCP flows are
affected by congestion and go into slow start at the
same time
RED
dramatic
drop in network traffic -- network
may be underutilized
TCP flows will come out of the slow start at
about the same time -- another burst of traffic
-- this could cause another cycle
Solution(s):
bigger
buffers -- not desirable
predict congestion and inform one TCP flow
at a time to slow down
RED
Design
RED
avoidance
goals of RED:
congestion
congestion is likely to occur with the arrival of
bursty traffic from one or few sources
if only packets from bursty flows are selected for
dropping, discard algorithm is biased against
bursty sources
avoidance:
RED is designed to avoid congestion not to react
to it
must predict the onset of congestion and maintain
network in the efficient region of the power curve
global
bound
on average queue length: RED should
be able to control the average queue size
synchronization avoidance:
when onset of congestion is detected, router must
decide which flows to notify to backoff
notification are implicit (dropping packets)
RED
RED
performs two functions when packets
come in
of bias against bursty traffic:
RED
RED algorithms can be summarized by the
following steps:
compute
average queue length avg
this is compared with two thresholds
less than lower threshold congestion is assumed to
be non existent
greater than upper threshold congestion is serious
between the thresholds, might be onset of
congestion compute probability Pa. based on
avg
RED
In
RED, we would like to space the
discards such that a bursty source does
not get overly penalized
This is integrated into the computation of
Pa.
compute
a probability Pb that changes from 0
at min threshold to Pmax at max. threshold
RED
Above
equation gives the fraction of the
critical region scaling factor
Pb = F * Pmax
Instead
of using Pb directly, we compute
Pa which is the probability used to discard
Pa =
RED
0 F 1
F * Pmax
1 count * F * Pmax
Traffic Management at Flow Level
At
the flow level, we are concerned with
managing traffic flows to ensure QoS
Congestion control algorithms at flow level
can be grouped into:
Open-loop
control: (equivalent reservationbased approaches)
Closed-loop control: (equivalent to feedback
based approaches)
Traffic Management at Flow Level
Figure below shows throughput with and without
congestion control. Congestion cannot be
addressed by having large network buffers
Open-Loop Traffic Control
Open-Loop
Traffic Control uses the
following building blocks:
Admission
control
Policing
Traffic
Admission Control
Admission control is meant to determine whether
a request for new connection should be allowed
based on expected resource requirements.
Shaping
Policing
Policing
is often implemented by a leaky
bucket regulator
Leaky bucket with water
Leaky bucket with packets
10
Policing
Example
leaky bucket policing. Counter
increment 4 packet times, traffic burstiness
allowed 6 packet times
Shaping Vs. Policing
Policing
is done on incoming traffic.
Shaping is done on outgoing traffic.
Traffic Shaping
Traffic
shaping can be done in number of
ways
Using a leaky bucket shaper.
Token Bucket Algorithm
Let b the bucket size
in bytes
Let r be the token rate
in bytes/sec
In time T, b + rT bytes
can pass through
11
Leaky Vs.
Token
Bucket
Traffic Shaping
Using
a token bucket shaper
(a) Input to a leaky bucket.
(b) Output from a leaky
bucket. Output from a token
bucket with capacities of (c)
250 KB, (d) 500 KB, (e)
750 KB, (f) Output from a
500KB token bucket feeding
a 10-MB/sec leaky bucket.
12
