Scribd
Upload
54 views

Lecture17 NetworkResourceAllocation

The document discusses resource allocation in computer networks. It notes that resource allocation in networks is similar to resource allocation in operating systems, with resources being buffers and bandwidth instead of CPU. It categorizes different approaches to resource allocation and discusses common queuing disciplines like FIFO and fair queuing. It also covers packet drop policies like tail drop and random early detection. Finally, it discusses traffic management at the flow level, including open-loop control techniques like admission control, policing, and traffic shaping using leaky bucket and token bucket algorithms.

Uploaded by

raw.junk
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
54 views

Lecture17 NetworkResourceAllocation

The document discusses resource allocation in computer networks. It notes that resource allocation in networks is similar to resource allocation in operating systems, with resources being buffers and bandwidth instead of CPU. It categorizes different approaches to resource allocation and discusses common queuing disciplines like FIFO and fair queuing. It also covers packet drop policies like tail drop and random early detection. Finally, it discusses traffic management at the flow level, including open-loop control techniques like admission control, policing, and traffic shaping using leaky bucket and token bucket algorithms.

Uploaded by

raw.junk
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 12

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

You might also like