ece544: communication networks-ii, spring 2012 d. raychaudhuri lecture 8 (qos) includes teaching...
TRANSCRIPT
ECE544: Communication Networks-II, Spring 2012
D. RaychaudhuriLecture 8 (QoS)
Includes teaching materials from D. Raychaudhuri, L. Peterson
Today’s 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
region
Overloadregion
Normal operatingPoint (G0)
Capacity LimitSmax
Offered Traffic (G)
ThruTrafficmargin
Congestion control policies
Unstable network load
Stable network load lineswith 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: first-come-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 Round-
Robin fashion
FQ illustrationFlow 1
Flow 2
Flow n
I/P O/P
Variation: Weighted Fair Queuing (WFQ)
Some Complications
• Packets are of different length• We really need bit-by-bit round-
robin (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
Flow 1 Flow 2
Pkt 2-1=3 units
Pkt 1-1=2 units
Pkt 2-2=2 units
Pkt 1-2=1 unit
Pkt 1-3=1 unit
Channel clock - 1-1
P(1,1) = 2P(1,2) = 1P(1,3) = 1
P(2,1) = 3P(2,2) = 2
Start with A(*,*)=0 (all pkts arrive at T=0)
F(1,1) = 1F(1,2) = 1.5F(1,3) = 2
F(2,1) = 1.5F(2,2) = 2.5
Fi = max (Fi-1, Ai) + Pi
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 link’s bandwidth that a flow will get• The bandwidth that flow q gets (n active queues
sending data):
– FQ is a special case of WFQ with a weight of 1 for each queue
n
w
wB
1
Congestion Control and Congestion Avoidance
• TCP’s “blind” approach:– Detect congestion (loss) after it happens and back off on
offered rate– Increase load trying to maximize utilization until loss
occurs
SourceRate(bps)
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• Some protection against ill-behaved
users
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
Min threshold
Max threshold
Average queuelength
minthresh maxthresh
MaxP
1.0
Avg length
P(drop)
• If AvgLen <= MinThreshold– Queue the packet
• If MinThreshold < Avglen < MaxThreshold– Calculate probability P – Drop the arriving packets with probability P
• If Avglen >= MaxThreshold– Drop the arriving packet
• AveLen = (1-W) x AveLen + W x SampleLen
)1/(
)(
)(
TempPcountTemPP
ldMinThresholdMaxThresho
ldMinThreshoAvgLenMaxPTempP
• Count:# of newly arriving packets that have been queued (not dropped) while AvgLen has been between the two thresholds– Count increases, P increases– Make drop more evenly distributed (Avoid
bias against bursty traffic)
Explicit Congestion Control
• 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
Version HLen TOS Length
Ident Flags Offset
TTL Protocol Checksum
SourceAddr
DestinationAddr
Options (variable) Pad(variable)
0 4 8 16 19 31
Data
• ToS field => now used for DiffServ and ECN– Bits 0-5: Differentiated
Services Code Point (DSCP)– Bit 6: ECN-capable– Bit 7: ECN
Quality of Service
OutlineRealtime ApplicationsIntegrated ServicesDifferentiated Services
Realtime Applications
• 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
Microphone
Speaker
Sampler,A D
converter
Buffer,D A
Playback BufferS
eque
nce
num
ber
Packetgeneration
Networkdelay
Buffer
Playback
Time
Packetarrival
Example Distribution of Delays
1
2
3
Pa
cke
ts (
%)
90% 97% 98% 99%
150 20010050
Delay (milliseconds)
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
ElasticReal-Time
Loss, delay tolerant
IntolerantInteractive
Non-adaptiveadaptive Non-adaptive
Delayadaptive
Rateadaptive
Rateadaptive
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 flow’s traffic characteristics
• Rspec: describes the service requested from the network
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
Packet
overflow
tokens
tokens
Packet
Enough tokenspacket goes through,tokens removed
Not enoughtokens - wait fortokens toaccumulate
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
BW
Time
1
2
1 2 3
Flow A
Flow BFlow A: r = 1 Mbps, B=1 byte
Flow B: r = 1 Mbps, B=1MB
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
Link layer modules
ICMP IGMP RSVP
IP service interface
Link layer service interface
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 real-time, 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 sender’s packets will follow
• Both can be accomplished by sending PATH messages by the sender
PATH messages• PATH messages carry sender’s 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
R
Sender 1
Sender 2
receiver 1
receiver 2
R R
R
PATH
PATH RESV
RESV
RESV (merged)
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 CategoriesATM 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
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
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 assurances
Differentiated Services (cont)• Divide traffic into a small number of
classes and allocates resource on a per-class 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
• 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
Version HLen TOS Length
Ident Flags Offset
TTL Protocol Checksum
SourceAddr
DestinationAddr
Options (variable) Pad(variable)
0 4 8 16 19 31
Data
• ToS field => now used for DiffServ and ECN– Bits 0-5: Differentiated
Services Code Point (DSCP)– Bit 6: ECN-capable– Bit 7: ECN
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 levels each
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
first hoprouter
internalrouter
borderrouter
host
borderrouter
ISP
Company A
Unmarkedpacket flow
Packets in premiumflows have bit set
Premium packet flowrestricted to R bytes/sec
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
ClearA & P
bits
Packetclassifier
Marker 1
Marker N
Forwardingengine
Arrivingpacket Best effort
Flow
1Fl
ow N
• 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
Wait fortoken
Set P bitPacketinput
Packetoutput
Drop on overflow
P service
Test iftoken
Set A bittoken
No token
Packetinput
Packetoutput
A service
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?
If A-bit setincr A_cnt
High-priority Q
Low-priority Q
If A-bit setdecr A_cnt
RIO queuemanagement
Packets out
yes
no
Border router input interface Profile Meters
Arrivingpacket
Is packetmarked?
Tokenavailable?
Tokenavailable?
Clear A-bit
Drop packet
Forwardingengine
A set
P set
token
token
Not marked
no
no
• At border routers, profile meters test marked flows:– drop P packets out of profile– unmark A packets
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
MaxP
1.0
Minout Minin MaxinMaxout
P(drop)
AvgLen
65
Today’s Homework• Chapter 6
-6.13 4th ed-6.32 -6.43 -6.44
Due 3/30/12