© jörg liebeherr, 1998-2002 1 quality-of-service architectures for the internet
TRANSCRIPT
![Page 1: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/1.jpg)
© Jörg Liebeherr, 1998-2002 1
Quality-of-Service Architectures for the Internet
![Page 2: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/2.jpg)
© Jörg Liebeherr, 1998-2002 2
Quality of Service
What is Quality-of-Service?• QoS refers to traffic control mechanisms that seek to either
differentiate performance based on application or network-operator requirements, or provide predictable or guaranteed performance to applications, sessions, or traffic aggregates.
Why is this an issue?• The default service in many packet networks is to give all
applications the same service, and not consider any service requirements to the networkThis is called a best-effort service.
![Page 3: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/3.jpg)
© Jörg Liebeherr, 1998-2002 3
Quality of Service
Who needs Quality-of-Service?– Video and audio conferencing bounded delay and loss rate– Video and audio streaming bounded packet loss rate– Time-critical applications (real-time control) bounded delays– “valuable applications” better service than less valuable applications
How are Quality-of-Service requirements specified?• QoS requirements can be specified as
– Delay– Delay Variation (Jitter)– Throughput– Error Rate
![Page 4: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/4.jpg)
© Jörg Liebeherr, 1998-2002 4
Components of a QoS Network
1. At routers: Packet Classification, Packet Scheduling
2. At network entrance: Traffic conditioning
3. At routers or somewhere in the network: Admission Control
4. Between hosts and routers: Signaling
Sender
ReceiverRouters
Admissioncontrol
Traffic conditioning
![Page 5: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/5.jpg)
© Jörg Liebeherr, 1998-2002 5
Classification and Scheduling
Routers need to be able to
1. classify arriving packets according to QoS requirements Packet Classification
2. Transmit packets in order to meet QoS Packet Scheduling
![Page 6: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/6.jpg)
© Jörg Liebeherr, 1998-2002 6
Traffic Conditioning
• Traffic conditioning mechanisms at the network boundary need to enforce that traffic from a flow does not exceed specification
Policing
Drop traffic that violates specificationShaping
Buffer traffic that violates specificationMarking
Mark packets with a lower priority or as best effort, if the traffic specification is violated
![Page 7: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/7.jpg)
© Jörg Liebeherr, 1998-2002 7
Traffic Conditioning
• The most popular traffic conditioning algorithm is the leaky bucket
Token pool (Bucket) has depth b
r token/sec are added (no tokens are added if there are b tokens)
Network
A shaper buffers packets until a token becomes available A policer drops a packet if no token is available
Each packet removes a token from the pool.If pool is empty, packet cannot enter
![Page 8: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/8.jpg)
© Jörg Liebeherr, 1998-2002 8
Admission Control
• Admission Control is a function that decides if the network has enough resources– Admit new flow if enough resources are available– Reject the flow otherwise
Sender
ReceiverRoutersTraffic conditioning
I need100 ms delay for 1 Mbps traffic Admit
Reserve capacity
Admissioncontrol
![Page 9: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/9.jpg)
© Jörg Liebeherr, 1998-2002 9
• Example: End-to-end delay must be less than a delay bound D
• Calculate smallest possible delay bound at each node: d*1,d*2 ,d*3 and reserve resources• At receiver:
– If D < d*1+d*2+d*3 , reject flow, send reject message to sender and release resources – If D > d*1+d*2+d*3 , accept flow, commit resource reservation and notify sender
Distributed Admission Control
1 23
D < d1+d2+d3
RejectS
RD
D,d1 D,d1,d2
D,d1,d2,d3
Reject
D > d1+d2+d3
Accept
Accept
![Page 10: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/10.jpg)
© Jörg Liebeherr, 1998-2002 10
• Signaling Protocol is used to reserve and release resources and to do admission control
Signaling
1 23
S
RReserve 1 Mbps
Reserve 1 Mbps
Reserve 1 Mbps
Reserve 1 Mbps
![Page 11: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/11.jpg)
© Jörg Liebeherr, 1998-2002 11
Granularity of QoS
• Per-flow guarantees– Require per-flow reservations in the network– Require per-flow classification at routers
![Page 12: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/12.jpg)
© Jörg Liebeherr, 1998-2002 12
Granularity of QoS
1
1
2
2
1
1
2
2
1
1
2
2
21
2
1
2
11
2
1
22
1
• Per-class guarantees– Bundle traffic flows with similar service requirements into “classes”
– No per-flow reservations
– Per-class guarantees do not immediately translate into per-flow guarantees
![Page 13: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/13.jpg)
© Jörg Liebeherr, 1998-2002 13
QoS Service Architectures for the Internet
• Two QoS architectures have been defined for Internet. – Integrated Services (IntServ)
• Proposed in 1994• Per-flow Quality of Service• Resource reservation/admission control• Can support delay guarantees
– Differentiated Services (DiffServ)• Proposed in 1998• Class-based QoS• Resource reservation not always needed
![Page 14: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/14.jpg)
© Jörg Liebeherr, 1998-2002 14
Integrated Services
IntServ specifies two types of services:Guaranteed Service
– Guaranteed bandwidth– End-to-end delay bounds– No loss due to buffer overflows
Controlled Load Service– Provides a service that is equivalent to a best effort service
in a lightly loaded network• Low loss• Low delay• No absolute guarantees
![Page 15: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/15.jpg)
© Jörg Liebeherr, 1998-2002 15
Integrated Services
1. At network entrance: Policing and Shaping
2. Somewhere in the network: Admission Control
3. At switches: Classification, Scheduling
4. Between hosts and routers: Signaling
FlowSpec (TSpec,RSpec)
Distributed
Weighted Fair Queuing or
other rate-based algorithm
RSVP
in IntServ
![Page 16: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/16.jpg)
© Jörg Liebeherr, 1998-2002 16
Resource ReSerVation Protocol (RSVP)
• RSVP is a signaling protocol that enables senders, receivers, and routers of unicast or multicast sessions to communicate with each other for setting up state to support a service– Receiver-driven
• Resource reservation is initiated by receivers– Unicast and multicast sessions– Soft-state: state information of RSVP must be periodically
refreshed
• Separate mechanisms required for authorization, authentication, and charging
![Page 17: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/17.jpg)
© Jörg Liebeherr, 1998-2002 17
RSVP Functional Diagram
Application
RSVPD
AdmissionsControl
PacketClassifier
PacketScheduler
PolicyControl
DATA
DATA
RSVPD
PolicyControl
AdmissionsControl
PacketClassifier
DATA
RoutingProcess
Host Router
Source: Gordon Chaffee, UC Berkeley
PacketScheduler
![Page 18: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/18.jpg)
© Jörg Liebeherr, 1998-2002 18
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
Source: Gordon Chaffee, UC Berkeley
![Page 19: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/19.jpg)
© Jörg Liebeherr, 1998-2002 19
RSVP UDP Reservation (1)
R4
R5
R3R2
R1
Host A24.1.70.210
Host B128.32.32.69PATH
PATH
PATH
2
2. The Host A RSVP daemon generates a PATH message that is sent to the next hop RSVP router, R1, in the direction of the session address, 128.32.32.69.
PATH3
3. The PATH message follows the next hop path through R5 and R4 until it gets to Host B. Each router on the path creates soft session state with the reservation parameters.
1. An application on Host A creates a session, 128.32.32.69/4078, by communicating with the RSVP daemon on Host A.
1
Source: Gordon Chaffee, UC Berkeley
![Page 20: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/20.jpg)
© Jörg Liebeherr, 1998-2002 20
RSVP UDP Reservation (2)
R4
R5
R3R2
R1
Host A24.1.70.210
Host B128.32.32.69
PATHPATH
PATH
PATH
RESV
RESV
RESV
5
5. The Host B RSVP daemon generates a RESV message that is sent to the next hop RSVP router, R4, in the direction of the source address, 24.1.70.210.
RESV
6
6. The RESV message continues to follow the next hop path through R5 and R1 until it gets to Host A. Each router on the path makes a resource reservation.
4. An application on Host B communicates with the local RSVP daemon and asks for a reservation in session 128.32.32.69/4078. The daemon checks for and finds existing session state.
4
Source: Gordon Chaffee, UC Berkeley
![Page 21: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/21.jpg)
© Jörg Liebeherr, 1998-2002 21
RSVP Flowspecs
Peak Data Rate [p]
Minimum Policed Unit [m]
Maximum Policed Unit [M]
Token Bucket Rate [r]
. . .
Token Bucket Size [b]
Sender TSpec, Controlled Load Flowspec
Peak Data Rate [p]
Minimum Policed Unit [m]
Maximum Policed Unit [M]
Token Bucket Rate [r]
. . .
Token Bucket Size [b]
Guaranteed Flowspec
Rate [R]
Slack Term [S]
Source: Gordon Chaffee, UC Berkeley
![Page 22: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/22.jpg)
© Jörg Liebeherr, 1998-2002 22
Reservation Merging
Receiver#1
Receiver#2
Receiver#3
Reservations mergeas they travel up tree.
R6
R3
R1
R4 R7
(1) 50Kbs
(2) 50Kbs
(3) 50Kbs
(4) 100 Kbs
(5) 100 Kbs
(6) 100 Kbs
(7) 100 Kbs
(8) 60Kbs
(9) 60Kbs
Source: Gordon Chaffee, UC Berkeley
![Page 23: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/23.jpg)
© Jörg Liebeherr, 1998-2002 23
Summary of IntServ
– Advantages:• Strong guarantees (bounded delays)
– Disadvantages:• Requires that all routers implement IntServ• Scalability concerns since routers must maintain state information• Charging and authentication of reservations must be solved• Interdomain issues are difficult to resolve
![Page 24: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/24.jpg)
© Jörg Liebeherr, 1998-2002 24
DiffServ
• Motivation: – The Integrated Services (IntServ) model is not scalable
since it requires per-flow state in each node
Goal:Goal:• Push complexity to the network edge and keep network core
simple• Avoid per-flow state within the network as much as possible
![Page 25: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/25.jpg)
© Jörg Liebeherr, 1998-2002 25
Differentiated Service Mechanisms
• DefinitionsDefinitions::– Mechanisms that allow providers to allocate different levels
of service to different users of the Internet
– broad view:broad view: Any mechanism that treats different users differently, including signaling (RSVP), per-session scheduling, etc.
– Internet context:Internet context: Simple and lightweight mechanisms that do not depend entirely on per-flow reservation
![Page 26: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/26.jpg)
© Jörg Liebeherr, 1998-2002 26
Components of Differentiated Services
(1) Service profileService profile between user and network defines commitment of the network to the user
(2) Aggregate traffic from each user is policed at the policed at the network entrancenetwork entrance according to profile
(3) Node behavior:Node behavior: network nodes implement a variety of forwarding, scheduling, buffer management techniques
(4) Bits in packet headerBits in packet header trigger action at nodes
![Page 27: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/27.jpg)
© Jörg Liebeherr, 1998-2002 27
Common to Most Proposed Services
• Traffic marking (in-profile, out-profile) and enforcement is done only at network boundaries
• Inside the network: Only differentiate a few service classes, based on marking of the packets
![Page 28: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/28.jpg)
© Jörg Liebeherr, 1998-2002 28
Policing, shaping, or marking based on profile
Policing, shaping, or marking based on profile
Operational Model
Host Meters Meters
ISP 2
Host
ISP 1
Source negotiates
a traffic profile
Source negotiates
a traffic profile
networkboundary
Nodes perform scheduling and buffer management
based on marking of packets(“per-hop behavior”)
Nodes perform scheduling and buffer management
based on marking of packets(“per-hop behavior”)
networkboundary
Policing, shaping, or marking
based on profile
Policing, shaping, or marking
based on profile
![Page 29: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/29.jpg)
© Jörg Liebeherr, 1998-2002 29
Aspects of a Differentiated Service
(1) Semantics of the service:Semantics of the service:Which service is given to in-profile traffic of a user?
(2) Spatial Granularity:Spatial Granularity:
Is the profile applied to a single destination, a subset of destinations, or all destinations?
(3) Assurance Level:Assurance Level:
What is the level of certainty that an in-profile packet will be delivered?
![Page 30: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/30.jpg)
© Jörg Liebeherr, 1998-2002 30
DiffServ Services
• Two services defined:
• Assured Forwarding (AF)Assured Forwarding (AF)– customers sign service agreements with ISPs– Edge routers mark packets as being “in” or “out” of profile– core routers run RIO: RED with in/out– Distinguishes different classes:
• Expedited ForwardingExpedited Forwarding (EF)(EF)– Hard guarantee on the delay and delay variations
![Page 31: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/31.jpg)
© Jörg Liebeherr, 1998-2002 31
Assured Forwarding - 1
• User defines traffic profile (token bucket)• Profile meter at network entrance tag packets as in-profile or
out-profile• Service guaranteeService guarantee:: In-profile packets are In-profile packets are
unlikely to be droppedunlikely to be dropped• Out-profile packets have higher drop preference at routers
Profilemeter
“in”
“out”
![Page 32: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/32.jpg)
© Jörg Liebeherr, 1998-2002 32
Assured Forwarding - 2Mechanisms
• Mechanisms Needed :– Dropping Mechanisms at routers– Mechanism for tagging packets (“Meters”) – Method to classify packets
Host Meters MetersISP 2
Host
ISP 1
drop
![Page 33: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/33.jpg)
© Jörg Liebeherr, 1998-2002 33
Assured Forwarding - 3RIO
• Routers have different dropping mechanism:
RIO = RED with `in’ and `out’• Routers do not perform separate queueing• RED (Random Early Detection):
When the avgerage queue size exceeds a threshold drop each packet with a certain probability (Pdrop)
P(drop)
1
Min_in Max_in
Pmax_in
P(drop)
1
Min_out Max_out
Pmax_out
Avg. queue
Avg. queue
![Page 34: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/34.jpg)
© Jörg Liebeherr, 1998-2002 34
Expedited Forwarding - 1
• EF traffic must be served at a configured rate of R or faster, independent of the load
• Service is equivalent to a “virtual leased line”• Routers have two priority levels (premium and best effort)• Admission Control via Bandwidth Brokers
Spaced to peak rate R
P-bit marking
![Page 35: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/35.jpg)
© Jörg Liebeherr, 1998-2002 35
Expedited Forwarding - - 2 Admission Control
• “Bandwidth Brokers” perform admission control at ingress router
• Only the ingress router differentiates flows
Host
PacketMarking
ISP 1 PacketMarking
ISP 2destHost
Bandwidthbroker
Bandwidthbroker
![Page 36: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/36.jpg)
© Jörg Liebeherr, 1998-2002 36
Summary of DiffServ
– Advantages:• No per-flow processing in network core• Per-flow processing only at the network edge• Simpler to implement than IntServ• No signaling protocol
– Disadvantages:• AF has weaker service guarantees• EF service raises same issues with charging and
authentication as IntServ services
![Page 37: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/37.jpg)
© Jörg Liebeherr, 1998-2002 37
Leaf Router: Input (Leaf router = the router closest to the source)
Marker(Assured Service)
ClearA andP bits
PacketClassifier
Marker(Premium Service)
Wait forToken
Set PBit
Test ifToken
Set ABitToken
No Token
PacketForwarding
...Best Effort Traffic
Input Marker Output
![Page 38: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/38.jpg)
© Jörg Liebeherr, 1998-2002 38
Border Router: Input (Border router = ingress router of a network)
Arriving
Pakcet
Tokenavailable?
ClearA Bit
DropPacketNo
ForwardingEngine
Input Profile Meter Output
Packetmarked?
Tokenavailable?
No
Not Marked
![Page 39: © Jörg Liebeherr, 1998-2002 1 Quality-of-Service Architectures for the Internet](https://reader036.vdocuments.net/reader036/viewer/2022062804/5697bf7d1a28abf838c84c1d/html5/thumbnails/39.jpg)
© Jörg Liebeherr, 1998-2002 39
Router: Output
P-bitset ?
High priority
Yes
Low priority
No
RIO queuemanagement