quality of service on the internet -...
TRANSCRIPT
Quality of Service on the Internet
C. Pham
DEA DISIC lectureThese slides borrow material from various sources
which are indicated below each slide whennecessary
Slides mostly taken from Shivkumar Kalyanaraman which are mostly based on slides of Ion Stoica, Jim Kurose, Srini Seshan, Srini Keshav
Multimedia, real time on the Internet
Real-time applications Interactive applications are sensitive to packet delays
(telephone) Non-interactive applications can adapt to a wider range
of packet delays (audio, video broadcasts) Guarantee of maximum delay is useful
ArrivalOffsetGraph
PlayoutPoint
Sampled Audio
Playout Buffer must besmall for interactiveapplications
Time-constrained applications
Elastic applications Interactive data transfer (e.g. HTTP, FTP)
Sensitive to the average delay, not to the distribution tail
Bulk data transfer (e.g. mail and news delivery)Delay insensitive
Best effort works well
Document
Document is only usefulwhen it is completelyreceived. This meansaverage packet delay isimportant, notmaximum packet delay.Document
Discussion
What is the problem? Different applications have different delay, bandwidth,
and jitter needs Some applications are very sensitive to changing network
conditions: the packet arrival time distribution isimportant
Solutions Make applications adaptive Build more flexibility into network
Why Better-than-Best-Effort (QoS)?
To support a wider range of applications Real-time, Multimedia, etc
To develop sustainable economic models and newprivate networking services Current flat priced models, and best-effort services do
not cut it for businesses
What do we have now?
Multimedia applications:network audio and video
Impairments: excessive delay: gaps in
rendered audio, video excessive data loss
Quality of Service: What is it?
Multimedia applications:network audio and video
network provides applicationwith level of performanceneeded for application tofunction.
QoS
What is QoS?
“Better performance” as described by a set ofparameters or measured by a set of metrics.
Generic parameters: Bandwidth Delay, Delay-jitter Packet loss rate (or loss probability)
Transport/Application-specific parameters: Timeouts Percentage of “important” packets lost
What is QoS (contd) ?
These parameters can be measured at severalgranularities: “micro” flow, aggregate flow, population.
QoS considered “better” if more parameters can be specified QoS can be specified at a fine-granularity.
QoS spectrum:
Best Effort Leased Line
QoS: why don’t we have it?
QoS a concern since early 1980’s Look at what’s happened since 1980:
Internet now a million times larger! applications: WWW, Napster, EBay, Gopher
Why is the QoS problem so hard?
Why limited progress on QoS? lots of smart people working on it!
The Internet is a huge
transformative success !
Why was the WWW so “easy”?
Implemented in hosts, servers at“network edge” “on top of” existing network “complexity at network edge” no changes to network core
WWW server
WWW brower
Why is QoS more difficult?
New architecture needed for network core!
today’s Internet coreprovides “best effort”service network congestion causes
delays, loss no timing guarantees no loss guarantees
multimedia requires loss,timing constraints met
change thecore
architecture
therefore...
“The different timingand reliability constraints
of real-time communicationrequire new protocols and
architectures to bedeveloped”
wet-behind-the-earsresearcher, 1982.
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 toprovide some assurance for QOS
Work in Progress includes RSVP, Differentiated Services,and Integrated Services
Simple modelfor sharing andcongestionstudies:
Principles for QOS Guarantees
Consider a phone application at 1Mbps and an FTP applicationsharing 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 todistinguish between different classes; and new routerpolicy to treat packets accordingly
Principles for QOS Guarantees (more)
Applications misbehave (audio sends packets at a rate higherthan 1Mbps assumed above);
PRINCIPLE 2: provide protection (isolation) for one classfrom other classes
Require Policing Mechanisms to ensure sources adhere tobandwidth requirements; Marking and Policing need to bedone at the edges:
Principles for QOS Guarantees (more)
Alternative to Marking and Policing: allocate a set portion ofbandwidth to each application flow; can lead to inefficientuse of bandwidth if one of the flows does not use itsallocation
PRINCIPLE 3: While providing isolation, it is desirable touse resources as efficiently as possible
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 cannotsatisfy the needs
How to upgrade the Internet for QoS?
Approach: de-couple end-system evolution fromnetwork evolution
End-to-end protocols: RTP, H.323, etc to spur thegrowth of adaptive multimedia applications Assume best-effort or better-than-best-effort clouds
Network protocols: IntServ, DiffServ, RSVP,MPLS, COPS … To support better-than-best-effort capabilities at the
network (IP) level
10 Mbps
100 Mbps
1.5 Mbps
La congestion de plus près
Une congestion peut survenir lorsque trop de paquets sontinjectés dans le réseau et prennent des routes similaires. Ily a alors augmentation du temps d'attente et risque perdredes paquets.
Une congestion peut aussi survenir du fait de la différencede puissance de traitement d'un routeur à l'autre.L'agrégation du trafic est une source de congestionimportante et difficile à maîtriser dans les réseaux.
Congestion: A Close-up View knee – point after
which throughput increases
very slowly delay increases fast
cliff – point afterwhich throughput starts to
decrease very fast tozero (congestioncollapse)
delay approachesinfinity
Note (in an M/M/1queue) delay = 1/(1 –
utilization) Load
Load
Thro
ughp
utD
elay
knee cliff
congestioncollapse
packetloss
Congestion Control vs. CongestionAvoidance
Congestion control goal stay left of cliff
Congestion avoidance goal stay left of knee
Right of cliff: Congestion collapse
Load
Thro
ughp
utknee cliff
congestioncollapse
Le contrôle de congestion: principes
Réactif lorsque la congestion est détectée, informer les noeuds en amont et en
aval, puis, marquer des paquets, rejeter des paquets, traiter les paquets
prioritaires. Préventif
diffusion périodique d'informations d'états (taille des buffers) contrôle continue de la source (Leacky Bucket, Token Bucket...), contrôle de flux, contrôle d'admission.
De bout en bout pas de retour du réseau la congestion est estimée grâce à l'observation des pertes et des délais
de bout-en-bout Assisté par le réseau
bit d'annonce de congestion (SNA, DECbit, TCP/ECN, FR, ATM)
Le contrôle de flux, pour le récepteur
Fenêtrage l'émetteur utilise une fenêtre d'anticipation dans laquelle
il va pouvoir envoyer une certaine quantité de donnéessans acquittements
la taille de cette fenêtre peut être choisie par lerécepteur à la phase de connexion
si l'émetteur respecte les règles, le récepteur ne serapas surchargé.
Cela ne garantit pas que le contrôle de flux seraefficace pour le réseau (voir figure suivante).
Le contrôle de flux pour le réseau
Ex: principe du contrôle de congestion dans TCP chaque émetteur maintient une deuxième fenêtre de
congestion pour le réseau, la quantité d'information qu'il est autorisé à transmettre
par anticipation est le minimum des 2 fenêtres initialement, la fenêtre de congestion est mise à K
octets, l'émetteur envoie les données et arme untemporisateur,
si les données sont acquittées avant l'expiration dutemporisateur, on augmente K, et ainsi de suite jusqu'à (i)l'expiration d'un temporisateur ou, (ii) la taille de lafenêtre du récepteur a été atteinte.
C'est le principe du "slow start"
Slow Start
θ La fenêtre decongestionaugmente en faittrès rapidement!
ACK for segment 1
segment 1cwnd = 1
cwnd = 2 segment 2segment 3
ACK for segments 2 + 3
cwnd = 4 segment 4segment 5segment 6segment 7
ACK for segments 4+5+6+7
cwnd = 8
Le contrôle de congestion dans TCP
seuil initial a 64K, on augmente K exponentiellement avant etlinéairement après (congestion avoidance),
si perte, divise le seuil par 2, et on recommence avec K=1
Utilisation du Round Trip Time
1
One RTT
One pkt time
0R
21R
3
42R
567
83R
91011
1213
1415
1
2 3
4 5 6 7
Slow Start Sequence Plot
Time
Sequence No
.
.
.
La fenêtre de congestion doubleà chaque aller/retour
TCP Reno (Jacobson 1990)
SStime
window
CA
SS: Slow StartCA: Congestion Avoidance Fast retransmission/fast recovery
TCP Vegas (Brakmo & Peterson 1994)
SStime
window
CA
Converges, no retransmission … provided buffer is large enough
Queuing Disciplines
Each router must implement some queuingdiscipline
Queuing allocates bandwidth and buffer space: Bandwidth: which packet to serve next (scheduling) Buffer space: which packet to drop next (buff mgmt)
Queuing also affects latency
Class C
Class BClass A
Traffic Classes
Traffic Sources
DropScheduling Buffer Management
Typical Internet Queuing
FIFO + drop-tail Simplest choice Used widely in the Internet
FIFO (first-in-first-out) Implies single class of traffic
Drop-tail Arriving packets get dropped when queue is full
regardless of flow or importance
Important distinction: FIFO: scheduling discipline Drop-tail: drop (buffer management) policy
FIFO + Drop-tail Problems
FIFO Issues: In a FIFO discipline, the service seen by a flow isconvoluted with the arrivals of packets from all other flows! No isolation between flows: full burden on e2e control No policing: send more packets get more service
Drop-tail issues: Routers are forced to have have large queues to maintain high
utilizations Larger buffers => larger steady state queues/delays Synchronization: end hosts react to same events because packets
tend to be lost in bursts Lock-out: a side effect of burstiness and synchronization is that a
few flows can monopolize queue space
Design Objectives
Keep throughput high and delay low (i.e. knee) Accommodate bursts Queue size should reflect ability to accept bursts
rather than steady-state queuing Improve TCP performance with minimal hardware
changes
Queue Management Ideas
Synchronization, lock-out: Random drop: drop a randomly chosen packet Drop front: drop packet from head of queue
High steady-state queuing vs burstiness: Early drop: Drop packets before queue full Do not drop packets “too early” because queue may reflect only
burstiness and not true overload Misbehaving vs Fragile flows:
Drop packets proportional to queue occupancy of flow Try to protect fragile flows from packet loss (eg: color them or
classify them on the fly) Drop packets vs Mark packets:
Dropping packets interacts w/ reliability mechanisms Mark packets: need to trust end-systems to respond!
Packet Drop Dimensions
AggregationPer-connection state Single class
Drop positionHead Tail
Random location
Class-based queuing
Early drop Overflow drop
Random Early Detection (RED)
Min threshMax thresh
Average Queue Length
minth maxth
maxP
1.0
Avg queue length
P(drop)
Random Early Detection (RED)
Maintain running average of queue length Low pass filtering
If avg Q < minth do nothing Low queuing, send packets through
If avg Q > maxth, drop packet Protection from misbehaving sources
Else mark (or drop) packet in a manner proportional to queuelength & bias to protect against synchronization Pb = maxp(avg - minth) / (maxth - minth) Further, bias Pb by history of unmarked packets Pa = Pb/(1 - count*Pb)
RED Issues
Issues: Breaks synchronization well Extremely sensitive to parameter settings Wild queue oscillations upon load changes Fail to prevent buffer overflow as #sources increases Does not help fragile flows (eg: small window flows or
retransmitted packets) Does not adequately isolate cooperative flows from non-
cooperative flows
Isolation: Fair queuing achieves isolation using per-flow state RED penalty box: Monitor history for packet drops, identify
flows that use disproportionate bandwidth
RED with Multiple Thresholds
DiscardProbability
AverageQueue Length0
1
“Red”Threshold
0 “Yellow”Threshold
“Green”Threshold
“Red”Packets“Red”
Packets“Green”Packets
“Green”Packets
“Yellow”Packets
“Yellow”Packets
Full
source Juha Heinänen
0 2 4 6 8 10 12 14 16 18 200
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
Link congestion measure
Link marking probability
REM Athuraliya & Low 2000
Main ideas Decouple congestion & performance measure “Price” adjusted to match rate and clear buffer Marking probability exponential in `price’
REM RED
Avg queue
1
Comparison of AQM Performance
DropTailqueue = 94%
REDmin_th = 10 pktsmax_th = 40 pktsmax_p = 0.1
REM
queue = 1.5 pktsutilization = 92%γ = 0.05, α = 0.4, φ = 1.15
Service Specification
Loss: probability that a flow’s packet is lost Delay: time it takes a packet’s flow to get from
source to destination Delay jitter: maximum difference between the
delays experienced by two packets of the flow Bandwidth: maximum rate at which the soource
can send traffic QoS spectrum:
Best Effort Leased Line
Hard Real Time: Guaranteed Services
Service contract Network to client: guarantee a deterministic upper bound
on delay for each packet in a session Client to network: the session does not send more than it
specifies
Algorithm support Admission control based on worst-case analysis Per flow classification/scheduling at routers
Soft Real Time: Controlled LoadService
Service contract: Network to client: similar performance as an unloaded
best-effort network Client to network: the session does not send more than it
specifies
Algorithm Support Admission control based on measurement of aggregates Scheduling for aggregate possible
Traffic and Service Characterization
To quantify a service one has two know Flow’s traffic arrival Service provided by the router, i.e., resources reserved
at each router
Examples: Traffic characterization: token bucket Service provided by router: fix rate and fix buffer space
Characterized by a service model (service curveframework)
Ex: Token Bucket
Characterized by three parameters (b, r, R) b – token depth r – average arrival rate R – maximum arrival rate (e.g., R link capacity)
A bit is transmitted only when there is an available token When a bit is transmitted exactly one token is consumed
r tokens per second
b tokens
<= R bpsregulator
time
bits
b*R/(R-r)
slope R
slope r
Traffic Envelope (Arrival Curve)
Maximum amount of service that a flow can sendduring an interval of time t
slope = max average rateb(t) = Envelope
slope = peak rate
t
“Burstiness Constraint”
Characterizing a Source by TokenBucket
Arrival curve – maximum amount of bitstransmitted by time t
Use token bucket to bound the arrival curve
time
bits
Arrival curve
time
bps
Per-hop Reservation with Token Bucket
Given b,r,R and per-hop delay d Allocate bandwidth ra and buffer space Ba such
that to guarantee d
bits
b
slope rArrival curve
d
Ba
slope ra
What is a Service Model?
The QoS measures (delay,throughput, loss, cost)depend on offered traffic, and possibly otherexternal processes.
A service model attempts to characterize therelationship between offered traffic, deliveredtraffic, and possibly other external processes.
“external process”Network element
offered trafficdelivered traffic
(connection oriented)
Arrival and Departure Process
Network ElementRin Rout
Rin(t) = arrival process = amount of data arriving up to time t
Rout(t) = departure process = amount of data departing up to time t
bits
t
delay
buffer
Fundamental Problems
In a FIFO service discipline, the performanceassigned to one flow is convoluted with the arrivalsof packets from all other flows! Cant get QoS with a “free-for-all” Need to use new scheduling disciplines which provide
“isolation” of performance from arrival rates ofbackground traffic
B
Scheduling DisciplineFIFO
B
Packet Scheduling
Decide when and what packet to send on outputlink Usually implemented at output interface
1
2
Scheduler
flow 1
flow 2
flow n
Classifier
Buffermanagement
Mechanisms: Queuing/Scheduling
Use a few bits in header to indicate which queue (class) apacket goes into (also branded as CoS)
High $$ users classified into high priority queues, which alsomay be less populated => lower delay and low likelihood of packet drop
Ideas: priority, round-robin, classification, aggregation, ...
Class C
Class BClass A
Traffic Classes
Traffic Sources
$$$$$$
$$$
$
Scheduling And Policing Mechanisms
Scheduling: choosing the next packet fortransmission on a link can be done following anumber of policies;
FIFO: in order of arrival to the queue; packetsthat arrive to a full buffer are either discarded,or a discard policy is used to determine whichpacket to discard among the arrival and thosealready queued
Priority Queueing Priority Queuing: classes have different priorities; class may
depend on explicit marking or other header info, eg IPsource or destination, TCP Port numbers, etc.
Transmit a packet from the highest priority class with anon-empty queue
Preemptive and non-preemptive versions
Round Robin (RR)
Round Robin: scan class queues serving one from each classthat has a non-empty queue
one round
Weighted Round Robin (WRR)
Assign a weight to each connection and serve aconnection in proportion to its weight
Ex: Connection A, B and C with same packet size and weight
0.5, 0.75 and 1. How many packets from each connectionshould a round-robin server serve in each round?
Answer: Normalize each weight so that they are allintegers: we get 2, 3 and 4. Then in each round ofservice, the server serves 2 packets from A, 3 from Band 4 from C.
one round
w1
w2
wi
(Weighted) Round-Robin Discussion
Advantages: protection among flows Misbehaving flows will not affect the performance of well-
behaving flows Misbehaving flow – a flow that does not implement any congestion
control
FIFO does not have such a property
Disadvantages: More complex than FIFO: per flow queue/state Biased toward large packets (not ATM)– a flow receives service
proportional to the number of packets
If packet size are different, we normalize the weight by thepacket size ex: 50, 500 & 1500 bytes with weight 0.5, 0.75 & 1.0
Generalized Processor Sharing (GPS)
Assume a fluid model of traffic Visit each non-empty queue in turn (like RR) Serve infinitesimal from each Leads to “max-min” fairness
GPS is un-implementable! We cannot serve infinitesimals, only packets
max-min fairness
Soit un ensemble de sources 1,..,n demandant des ressources x1,..,xn avec x1<x2..<xn par exemple. Le serveur a une capacité C.
On donne alors C/n à la source 1. Si C/n>x1, on donne C/n+(C/n-x1)/(n-1) aux (n-1) sourcesrestantes. Si cela est supérieur à x2, on recommence.(Existe en version max-min weighted faire share)
Packet Approximation of Fluid System
GPS un-implementable Standard techniques of approximating fluid GPS
Select packet that finishes first in GPS assuming thatthere are no future arrivals (emulate GPS on the side)
Important properties of GPS Finishing order of packets currently in system
independent of future arrivals
Implementation based on virtual time Assign virtual finish time to each packet upon arrival Packets served in increasing order of virtual times
Fair Queuing (FQ)
Idea: serve packets in the order in which they would havefinished transmission in the fluid flow system
Mapping bit-by-bit schedule onto packet transmissionschedule
Transmit packet with the lowest finish time at any giventime
FQ Simple Example
F=10
Flow 1(arriving)
Flow 2transmitting Output
F=2
F=5
F=8
Flow 1 Flow 2 Output
F=10
Cannot preempt packetcurrently being transmitted
Round Number and Finish Number
Single flow: clock ticks when a bit is transmitted. For packetk: Pk = length, Ak = arrival time, Si = begin transmit time, Fk =
finish transmit time Fk = Sk+Pk = max (Fk-1, Ak) + Pk
Multiple flows: clock ticks when a bit from all active flows istransmitted round number Can calculate Fk for each packet if number of flows is known at
all times Fk = current round number + size of packet k, inactive case Fk = largest Fk in the queue + size of packet k, active case
Fi,k,t=max(Fi,k-1,t, Rt)+Pi,k,t
In packet approximation, finish number indicate a relative order(service tag) in which a packet is to be served. finishtime≠finish number
Example
The round number increases at a rate inversely proportionalto the number of active connections Thus is only used for computing finish numbers
Largest finish number in a connection's queue is theconnection's finish number
Example Suppose packets of size 1, 2 and 2 units arrive at a FQ
scheduler at time for connection A, B and C. Also, assume that apacket of size 2 arrive for connection A at time 4. The linkservice rate is 1 unit/s. Compute the finish number of allpackets.
Illustration
0 2 64 8
roun
d nu
mbe
r
0.5
1.5
2.5
3.5
1
2
3
slope = 1/3
slope = 1/2
slope = 1/3
1 3 5 7
FQ Advantages
FQ protect well-behaved flows from ill-behaved flows Example: 1 UDP (10 Mbps) and 31 TCP’s sharing a 10 Mbps
link
FQ
00.20.40.60.81
1.21.41.61.82
1 4 7 10 13 16 19 22 25 28 31Flow Number
Th
rou
gh
pu
t(M
bp
s)RED
012345
678910
1 4 7 10 13 16 19 22 25 28 31Flow Number
Th
rou
gh
pu
t(M
bp
s)
Weighted Fair Queueing
Variation of FQ: Weighted Fair Queuing (WFQ) Weighted Fair Queuing: is a generalized Round
Robin in which an attempt is made to provide aclass with a differentiated amount of service overa given period of time
Implementing WFQ
WFQ needs per-connection (or per-aggregate)scheduler state→implementation complexity. complex iterated deletion algorithm complex sorting at the output queue on the service tag
WFQ needs to know the weight assigned for eachqueue →manual configuration, signalling.
WFQ is not perfect… Router manufacturers have implemented as early
as 1996 WFQ in their products from CISCO 1600 series Fore System ATM switches
Approximating GPS with WFQ
Fluid GPS system service order
0 2 104 6 8 Weighted Fair Queueing
select the first packet that finishes in GPS
Big Picture FQ does not eliminate congestion it just manages
the congestion You need both end-host congestion control and router
support for congestion control end-host congestion control to adapt router congestion control to protect/isolate
Don’t forget buffer management: you still need todrop in case of congestion. Which packet’s would youdrop in FQ? one possibility: packet from the longest queue
Further readings
See http://www.cnaf.infn.it/~ferrari/ispn.htmlfor Quality of Service list of papers
See http://www.cnaf.infn.it/~ferrari/sched.htmlfor scheduling list of papers
Stateless vs. Stateful QoS Solutions
Stateless solutions – routers maintain no finegrained state about traffic scalable, robust weak services
Stateful solutions – routers maintain per-flowstate powerful services
guaranteed services + high resource utilizationfine grained differentiationprotection
much less scalable and robust
Existing Solutions
DecBit [Ramkrishnan & Jain ’88] Random Early Detection (RED)[Floyd & Jacobson ’93] BLUE [Feng et al ’99] REM [Low at al ’00]
Round Robin [Nagle ’85] Fair Queueing [Demers et al’89] Flow Random Early Drop(FRED) [Lin & Morris ’97]
Networksupport forcongestioncontrol
DiffServ - [Clark & Wroclawski ‘97] - [Nichols et al ’97]
Tenet [Ferrari & Verma ’89] IntServ [Clark et al ’91] ATM [late ’80s]
QoS
StatelessStateful
Integrated Services (IntServ) An architecture for providing QOS guarantees in IP networks
for individual application sessions Relies on resource reservation, and routers need to maintain
state information of allocated resources (eg: g) and respondto new Call setup requests
Integrated Services Model
Flow specification Leacky Bucket, Token Bucket
Routing Admission control Policy control Resource reservation
RSVP
Packet scheduling WFQ, CBQ, RED
Integrated Services: Classes
Guaranteed QOS: this class is provided with firmbounds on queuing delay at a router; envisioned forhard real-time applications that are highlysensitive to end-to-end delay expectation andvariance
Controlled Load: this class is provided a QOSclosely approximating that provided by an unloadedrouter; envisioned for today’s IP network real-time applications which perform well in anunloaded network
Signaling semantics Classic scheme: sender initiated SETUP, SETUP_ACK, SETUP_RESPONSE Admission control Tentative resource reservation and confirmation Simplex and duplex setup; no multicast support
RSVP for the IntServ approach
Resource reSerVation Protocol What is RSVP?
Method for application to specify desired QoS to net Switch state establishment protocol (signaling) Multicast friendly, receiver-oriented Simplex reservations (single direction)
Why run RSVP? Allows precise allocation of network resources Guarantees on quality of service Heterogeneous bandwidth support for multicast Scalable (?)
source Gordon Schaffee
Resource Reservation
Senders advertise using PATH message Receivers reserve using RESV message
Flowspec + filterspec + policy data Travels upstream in reverse direction of Path message
Merging of reservations Sender/receiver notified of changes
RSVP Functional Diagram
Application
RSVPD
AdmissionsControl
PacketClassifier
PacketScheduler
PolicyControlD
ATA
DATA
RSVPD
PolicyControl
AdmissionsControl
PacketClassifier
PacketScheduler
DATA
RoutingProcess
Host Router
SenderReceiver
Stateful Solution: Guaranteed Services
Achieve per-flow bandwidth and delay guarantees Example: guarantee 1MBps and < 100 ms delay to a flow
SenderReceiver
Stateful Solution: Guaranteed Services
Allocate resources - perform per-flow admissioncontrol
Stateful Solution Complexity
Data path Per-flow classification Per-flow buffer management Per-flow scheduling
Control path install and maintain per-flow state for data and control paths
Classifier
Buffermanagement
Scheduler
flow 1
flow 2
flow n
output interface
…Per-flow State
Stateless vs. Stateful
Stateless solutions are more scalable robust
Stateful solutions provide more powerful and flexibleservices guaranteed services + high resource utilization fine grained differentiation protection
Question
Can we achieve the best of two worlds, i.e., provide servicesimplemented by stateful networks while maintaining advantagesof stateless architectures? Yes, in some interesting cases. DPS, CSFQ.
Can we provide reduced state services, I.e., maintain state onlyfor larger granular flows rather than end-to-end flows? Yes: Diff-serv
DiffServ: Basic Ideas
Differentiated services provide a way to specifythe relative priority of packets
Some data is more important than other data People who pay for better service get it
Fujitsu Japan Fujitsu of America
Limited Bandwidth
The real question is to choose which packets shall be dropped. Thefirst definition of differential service is something like "not mine.” -- Christian Huitema
source Gordon Schaffee
Goals
Ability to charge differently for differentservices
Lightweight, scalable service discriminationsuitable for network backbones No per flow state or per flow signaling
Deploy incrementally, then evolve Build simple system at first, expand if needed in future
Make service separate from signaling
source Gordon Schaffee
Differentiated Services (DiffServ)
Intended to address the following difficulties with Intservand RSVP;
Scalability: maintaining states by routers in high speednetworks is difficult sue to the very large number of flows
Flexible Service Models: Intserv has only 2 classes, wantto provide more qualitative service classes; want to provide‘relative’ service distinction (Platinum, Gold, Silver, …)
Simpler signaling: (than RSVP) many applications and usersmay only w ant to specify a more qualitative notion ofservice
Architecture
All policy decisions made at network boundaries Boundary routers implement policy decisions by tagging
packets with appropriate priority tag Traffic policing at network boundaries
No policy decisions within network Routers within network forward packets according to
their priority tags
source Gordon Schaffee
Differentiated Services Model
Edge routers: traffic conditioning (policing, marking,dropping), SLA negotiation Set values in DS-byte in IP header based upon negotiated
service and observed traffic. Interior routers: traffic classification and forwarding
(near stateless core!) Use DS-byte as index into forwarding table
IngressEdge Router
EgressEdge Router
Interior Router
Diffserv ArchitectureEdge router:- per-flow trafficmanagement
- marks packets as in-profile and out-profileCore router:
- per class TM
- buffering and scheduling
based on marking at edge- preference given to in-profile packets- Assured Forwarding
scheduling
...
r
b
marking
Scope of Service Class
Packet priorities limited to an ISP Extend with bilateral ISP agreements
How can scope of priority be extended? Differentiated services is unidirectional
Traffic marked forpriority delivery
Traffic policed forprofile violations
No marking ofreturning trafficsource Gordon Schaffee
Packet format support
Packet is marked in the Type of Service (TOS) in IPv4, andTraffic Class in IPv6: renamed as “DS”
6 bits used for Differentiated Service Code Point (DSCP)and determine PHB that the packet will receive
2 bits are currently unused
Traffic Conditioning
It may be desirable to limit traffic injection rateof some class; user declares traffic profile (eg,rate and burst size); traffic is metered andshaped if non-conforming
Per-hop Behavior (PHB)
PHB: name for interior router data-plane functions Includes scheduling, buff. mgmt, shaping etc
Logical spec: PHB does not specify mechanisms to useto ensure 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
PHB (contd)
PHBs under consideration: Expedited Forwarding (EF, premium): departure rate of
packets from a class equals or exceeds a specified rate(logical link with a minimum guaranteed rate)Emulates leased-line behavior
Assured Forwarding (AF): 4 classes, each guaranteed aminimum amount of bandwidth and buffering; each withthree drop preference partitions Emulates frame-relay behavior
Premium ServiceVan Jacobson (LBL)
Conservative allocation of resources Provisioned according to peak capacity profiles
Shaped at boundaries to remove bursts Out of profile packets dropped
Defines a virtual leased line: fixed maximumbandwidth, but available when needed
source Gordon Schaffee
AF PHB Group (RFC 2597)
Provides forwarding of IP packets in four independentservice classes at each hop, each class has its own, configurable forwarding
resources within each class, an IP packet is assigned one of three
levels of drop precedence lower drop precedence means higher probability of forwarding
forwarding resources (buffer space and bandwidth) can beallocated using FBA, CBQ, WFQ, priorities, etc.
dropping of packets is based on the Random Early Drop(RED) algorithm each level of drop precedence (green, yellow, red) has its own
RED threshold
source Juha Heinänen
Assured Service Example
Assured Service
Drop if congested
Congested
Uncongested
source Gordon Schaffee
Example of Output Behavior
RR
RR
RR
RR
RR
RR
Each AF class hasits own queue and
forwarding resources
Each AF class hasits own queue and
forwarding resources
RED thresholdfor “Red” packetsRED threshold
for “Red” packets
RED thresholdfor “Yellow” packets
RED thresholdfor “Yellow” packets
source Juha Heinänen
Further readings
See http://www.ecse.rpi.edu/Homepages/shivkuma/research/cong-papers.html#qos for a list of papers on Scheduling, BufferManagement, Admission Control, Int-serv/Diff-serv and NetworkCalculus