KHOA CÔNG NGHỆ THÔNG TIN-ĐHKHTN

CSC11004 - MẠNG MÁY TÍNH NÂNG CAO

QUEUE MANAGEMENT & QUALITY OF

SERVICES

Lê Ngọc Sơn
TPHCM, 9-2021

fit@hcmus
fit@hcmus

Agenda
£ Queue Management
£ Drop Policy
£ Scheduling Discipline
£ Quality of Service
£ IntServ and DiffServ

2
 Queue Management

fit@hcmus 3
fit@hcmus Router

control plane
data plane Routing Processor

Line card Line card

Line card
Switching
Line card
Fabric

Line card Line card

4
fit@hcmus
Line Cards (Interface Cards, Adaptors)

q Packet handling to/from link

ü Packet forwarding
ü Buffer management
ü Packet filtering

Transmit
Receive
ü Rate limiting lookup
ü Packet marking

to/from switch
5
fit@hcmus
Buffer Size
q Why not use infinite buffers?
ü no packet drops!
q Small buffers:
ü often drop packets due to bursts
ü but have small delays
q Large buffers:
ü reduce number of packet drops (due to
bursts)
ü but increase delays
q Can we have the best of both worlds?

#6
fit@hcmus Queue Management
q Each router must implement some queuing
discipline
q Queuing allocates both bandwidth and
buffer space:
ü Bandwidth: which packet to serve (transmit)
next
ü Buffer space: which packet to drop next (when
required)
q Queuing also affects latency
fit@hcmus
Queue Management Issues
q Drop policy
ü When should you discard a packet?
ü Which packet to discard?
q Scheduling discipline
ü Which packet to send?
ü Some notion of fairness? Priority?
q Goal: balance throughput and delay
ü Huge buffers minimize drops, but add to
queuing delay (thus higher RTT, longer slow
start, …)
8
 Drop Policies

fit@hcmus 9
fit@hcmus FIFO Scheduling and Drop-Tail
q Access to the bandwidth: first-in first-out queue
ü Packets only differentiated when they arrive

q Access to the buffer space: drop-tail queuing

ü If the queue is full, drop the incoming packet

✗ 10
fit@hcmus Bursty Loss From Drop-Tail Queuing
q TCP depends on packet loss
ü Packet loss is indication of congestion
ü TCP additive increase drives network into loss
q Drop-tail leads to bursty loss
ü Congested link: many packets encounter full queue
ü Synchronization: many connections lose packets at
once

11
fit@hcmus Slow Feedback from Drop Tail
q Feedback comes when buffer is completely full
ü … even though the buffer has been filling for a
while
q Plus, the filling buffer is increasing RTT
ü … making detection even slower
q Better to give early feedback
ü Get 1-2 connections to slow down before it’s too
late!

12
fit@hcmus
Random Early Detection (RED)
q Router notices that queue is getting full
ü … and randomly drops packets to signal
congestion
q Packet drop probability
ü Drop probability increases as queue length
increases
ü Else, set drop probability f(avg queue length)

13
fit@hcmus
Random Early Detection (RED)

14
fit@hcmus
RED Dropping Curve

Drop Probability
1

maxp

0
minth maxth

Average Queue Size

15
fit@hcmus
Properties of RED
q Drops packets before queue is full
ü In the hope of reducing the rates of some flows
q Drops packet in proportion to each flow’s rate
ü High-rate flows selected more often
q Drops are spaced out in time
ü Helps desynchronize the TCP senders

16
fit@hcmus
Problems With RED
q Hard to get tunable parameters just right
ü How early to start dropping packets?
ü What slope for increase in drop probability?
ü What time scale for averaging queue length?
q RED has mixed adoption in practice
ü If parameters aren’t set right, RED doesn’t help
q Many other variations in research community
ü Names like “Blue” (self-tuning), “FRED”…

17
fit@hcmus Feedback: From loss to notification
q Early dropping of packets
ü Good: gives early feedback
ü Bad: has to drop the packet to give the feedback

£ Explicit Congestion Notification

ü Router marks the packet with an ECN bit
ü Sending host interprets as a sign of congestion

18
fit@hcmus Explicit Congestion Notification
q Must be supported by router, sender, AND receiver
ü End-hosts determine if ECN-capable during
TCP handshake
q ECN involves all three parties (and 4 header bits)
ü Sender marks “ECN-capable” when sending
ü If router sees “ECN-capable” and experiencing
congestion, router marks packet as “ECN congestion
experienced”
ü If receiver sees “congestion experienced”, marks “ECN
echo” flag in responses until congestion ACK’d
ü If sender sees “ECN echo”, reduces cwnd and marks
“congestion window reduced” flag in next TCP packet

19
 Scheduling Discipline

fit@hcmus 20
fit@hcmus
First-In First-Out (FIFO)

(a) FIFO queuing; (b) tail drop at a FIFO

queue.
21
fit@hcmus
FIFO Queuing – Priority Queuing
q A simple variation on basic FIFO queuing is
priority queuing
ü Each packet marked with a priority
q The routers then implement multiple FIFO
queues, one for each priority class
q Router always transmits packets out of the
highest-priority queue if that queue is nonempty
before moving on to the next priority queue.
q Within each priority, packets are still managed
in a FIFO manner.
22
fit@hcmus Priority Queuing
q Multiple levels of priority
ü Always transmit high-priority traffic, when
present
q But lower priority traffic may starve L
fit@hcmus
Fair Queuing and Round Robin
q The main problem with FIFO queuing is that it
does not discriminate between different traffic
sources, or it does not separate packets
according to the flow to which they belong.
q Fair queuing (FQ) maintains a separate queue
for each flow currently being handled by the
router.
ü The router then services these queues in round-robin
algorithm

24
fit@hcmus Fair Queuing - Round-Robin service
Fair Queuing

Round-robin service of four flows at a router

fit@hcmus
Weighted Fair Queuing (WFQ)

£ allows a weight to be assigned to each

flow (queue).
.

26
 Quality of Service

fit@hcmus 27
fit@hcmus Traditional Non-converged Network

Traditional data traffic characteristics:

ü Bursty data flow
ü FIFO access
ü Not overly time-sensitive; delays OK
ü Brief outages are survivable
28
 Converged Network Realities

Converged network realities:

ü Constant small-packet voice flow
competes with bursty data flow.
ü Critical traffic must have priority.
ü Voice and video are time-sensitive.
ü Brief outages are not acceptable.
29
fit@hcmus
Converged Network Quality Issues
q Lack of bandwidth: Multiple flows compete for a
limited amount of bandwidth.
q End-to-end delay (fixed and variable): Packets
have to traverse many network devices and
links; this travel adds up to the overall delay.
q Variation of delay (jitter): Sometimes there is a
lot of other traffic, which results in varied and
increased delay.
q Packet loss: Packets may have to be dropped
when a link is congested.
30
fit@hcmus
What is Quality of Service (Qos)?

“The measurable end-to-end performance properties of a

network service, which can be guaranteed in advance by a
Service Level Agreement between a user and a service
provider, so as to satisfy specific customer application
requirements. Note: These properties may include
throughput (bandwidth), transit delay (latency), error rates,
priority, security, packet loss, packet jitter, etc”
(NIST: National Institute of Standards and Technology)

31
fit@hcmus What Is Quality of Service?
q The user perspective
Users perceive that their applications
are performing properly
Voice, video, and data

q The network manager perspective

Need to manage bandwidth allocations
to deliver the desired application
performance
Control delay, jitter, and packet loss
32
 Different Types of Traffic Have Different Needs

q Real-time applications
especially sensitive to QoS Application
Sensitivity to
QoS Metrics

ü Interactive voice Examples

Delay Jitter
Packet
Loss
ü Videoconferencing
Interactive Voice
Y Y Y
q Causes of degraded and Video

performance Streaming Video N Y Y

ü Congestion losses
Transactional/
Y N N
ü Variable queuing delays Interactive

q The QoS challenge Bulk Data

Email N N N
ü Manage bandwidth allocations to File Transfer

deliver the desired application

performance Need to manage
ü Control delay, jitter, and packet loss bandwidth allocations

33
fit@hcmus
Building blocks
q Scheduling
ü Active Buffer Management
q Traffic Conditioner
ü Traffic Policing
ü Traffic Shaping
q Traffic Shaping
ü Leaky Bucket
ü Token Bucket

#34
fit@hcmus Scheduling: How Can Routers Help
q Scheduling: choosing the next packet for
transmission
ü FIFO/Priority Queue
ü Round Robin/ DRR
ü Weighted Fair Queuing
q Packet dropping:
ü not drop-tail
ü not only when buffer is full
ü Active Queue Management
q Congestion signaling
ü Explicit Congestion Notification (ECN)

#35
fit@hcmus Traffic Conditioners
q Policing
ü Limits bandwidth by discarding traffic.
ü Can re-mark excess traffic and attempt to send.
ü Should be used on higher-speed interfaces.
ü Can be applied inbound or outbound.
q Shaping
ü Limits excess traffic by buffering.
ü Buffering can lead to a delay.
ü Recommended for slower-speed interfaces.
ü Cannot re-mark traffic.
ü Can only be applied in the outbound direction.
36
 Traffic Policing and Shaping

q These mechanisms must classify packets before policing or shaping

the traffic rate.
q Traffic policing typically drops or marks excess traffic to stay within a
traffic rate limit.
q Traffic shaping queues excess packets to stay within the desired
traffic rate.
37
 Traffic Policing Example

q Do not rate-limit traffic from mission-critical server.

q Rate-limit file-sharing application traffic to 56 kbps.

38
fit@hcmus
Discussion

Traffic Shaping & Traffic Policing

Comparison?
fit@hcmus
Policing Versus Shaping

ü Incoming and outgoing ü Outgoing direction only.

directions. ü Out-of-profile packets are
ü Out-of-profile packets are queued until a buffer gets
dropped.
full.
ü Dropping causes TCP
retransmits. ü Buffering minimizes TCP
ü Policing supports packet retransmits.
marking or re-marking. ü Marking or re-marking not
supported.
41
 Traffic Shaping Algorithms

fit@hcmus 42
fit@hcmus
The Leaky Bucket
q The Leaky Bucket Algorithm
ü used to control rate in a network.
ü It is implemented as a single-server queue with
constant service time.
ü If the bucket (buffer) overflows then packets are
discarded.
q Leaky Bucket (parameters r and B):
ü Every r time units: send a packet.
ü For an arriving packet
¡ If queue not full then enqueue
q Note that the output is a “perfect” constant rate.

43
fit@hcmus
The Leaky Bucket Algorithm

(a) A leaky bucket with water. (b) a leaky bucket with packets.

44
fit@hcmus
Discussion

Drawbacks of Leaky
Bucket ?

45
fit@hcmus Token Bucket Algorithm
q Highlights: q Token Bucket
– The bucket holds tokens.
(r, MaxTokens):
– To transmit a packet, we
“use” one token. – Generate r tokens every time
unit
q Allows the output • If number of tokens more
rate to vary, than MaxToken, reset to
– depending on the size of MaxTokens.
the burst. – For an arriving packet:
– In contrast to the Leaky enqueue
Bucket – While buffer not empty and
q Granularity there are tokens:
– Bits or packets • send a packet and discard
a token
46
fit@hcmus The Token Bucket Algorithm

(a) Before. (b) After. 47

fit@hcmus Leaky Bucket vs Token Bucket
Leaky Bucket Token Bucket
• Discard: • Discard:
– Packets – Tokens
– Packet management separate
• Rate: • Rate:
– fixed rate (perfect) – Average rate
– Burst allowed
• Arriving Burst: • Arriving Burst:
– Waits in bucket – Can be sent immediately

48
 QoS Models

fit@hcmus 49
 Three QoS Models

Model Characteristics
Best effort No QoS is applied to packets. If it is not
important when or how packets arrive, the best-
effort model is appropriate.
Integrated Services Applications signal to the network that the
applications require certain QoS parameters.
(IntServ)
Differentiated Services The network recognizes classes that require QoS.
(DiffServ)
fit@hcmus
Best-Effort Model
q Internet was initially based on a best-effort packet
delivery service.
q Best-effort is the default mode for all traffic.
q There is no differentiation among types of traffic.
q Best-effort model is similar to using standard mail—
“The mail will arrive when the mail arrives.”
q Benefits:
ü Highly scalable
ü No special mechanisms required
q Drawbacks:
ü No service guarantees
ü No service differentiation
51
fit@hcmus IntServ and DiffServ
Integrated Services Differentiated Services
• Network wide control • Router based control
– Per hop behavior
• Admission Control • Resolves contentions
– Hot spots
• Absolute guarantees • Relative guarantees
• Traffic Shaping • Traffic policing
• Reservations – At entry to network
– RSVP

52
fit@hcmus
IETF Integrated Services

q Architecture for providing QOS guarantees in

IP networks for individual application sessions
q Resource reservation: routers maintain state
info (a la VC) of allocated resources, QoS
req’s
q Admit/deny new call setup requests

#53
fit@hcmus Intserv: QoS guarantee scenario
q Resource reservation
ü call setup, signaling (RSVP)
ü traffic, QoS declaration
ü per-element admission control

request/
reply

m QoS-sensitive
scheduling (e.g.,
WFQ)

#54
fit@hcmus Call Admission
Arriving session must :
q declare its QoS requirement
ü R-spec: defines the QoS being requested
q characterize traffic it will send into network
ü T-spec: defines traffic characteristics
üsignaling protocol: needed to carry R-spec
and T-spec to routers (where reservation is
required)
ü RSVP

#55
fit@hcmus
Resource Reservation Protocol
(RSVP)
Sending
q Is carried in IP—protocol Host
ID 46
q Can use both TCP and RSVP
UDP port 3455 Tunnel

q Is a signaling protocol and

works with existing routing
protocols
q Requests QoS parameters RSVP Receivers
from all devices between
the source and destination
q Provides divergent performance requirements for multimedia
applications:
ü Rate-sensitive traffic
ü Delay-sensitive traffic
56
 RSVP in Action

q RSVP sets up a path through the network with the requested

QoS.
q RSVP is used for CAC in Cisco Unified CallManager 5.0. 57
fit@hcmus
Benefits and Drawbacks
q Benefits:
pExplicit resource admission control (end to
end)
pPer-request policy admission control
(authorization object, policy object)
q Drawbacks:
pContinuous signaling because of stateful
architecture
pFlow-based approach not scalable to large
implementations, such as the public Internet
58
fit@hcmus IETF Differentiated Services
Concerns with Intserv:
£ Scalability: signaling, maintaining per-flow router
state difficult with large number of flows
£ Flexible Service Models: Intserv has only two
classes. Also want “qualitative” service classes

Diffserv approach:
£ Simple functions in network core, relatively complex
functions at edge routers (or hosts)
£ Don’t define define service classes, provide
functional components to build service classes

#59
fit@hcmus
DiffServ Model
q Describes services associated with traffic
classes, rather than traffic flows.
q Complex traffic classification and conditioning is
performed at the network edge.
q No per-flow state in the core.
q The goal of the DiffServ model is scalability.
q Interoperability with non-DiffServ-compliant
nodes

60
 IntServ vs. DiffServ
fit@hcmus
IP
IP

IntServ
network
DiffServ
network

"Call blocking" approach "Prioritization" approach

61
fit@hcmus DiffServ Routers
DiffServ
Edge
Router
Classifier Marker Meter Policer

DiffServ PHB
Select PHB PHB Local
Core PHB
PHB conditions
Router
Extract Packet
DSCP treatment

#62
fit@hcmus
Classification
q Classification is the process of identifying and
categorizing traffic into classes, typically based
upon:
ü Incoming interface
ü IP precedence
ü DSCP
ü Source or destination address
ü Application
q Without classification, all packets are treated the
same.
q Classification should take place as close to the
source as possible.

63
fit@hcmus
Marking
£ Marking is the QoS feature component that “colors” a
packet (frame) so it can be identified and distinguished
from other packets (frames) in QoS treatment.
£ Commonly used markers:
ü Link layer:
- CoS (ISL, 802.1p)
- MPLS EXP bits
- Frame Relay
ü Network layer:
- DSCP
- IP precedence
64
 Classification Tools
fit@hcmus IP Precedence and DiffServ Code Points

Version ToS
Len ID Offset TTL Proto FCS IP SA IP DA Data
Length Byte
IPv4 Packet

7 6 5 4 3 2 1 0
Standard IPv4
IP Precedence Unused
DiffServ Code Point (DSCP) IP ECN DiffServ Extensions

£ IPv4: three most significant bits of ToS byte are called

IP Precedence (IPP)—other bits unused
£ DiffServ: six most significant bits of ToS byte are
called DiffServ Code Point (DSCP)—remaining two
bits used for flow control
£ DSCP is backward-compatible with IP precedence

65
 IP ToS Byte and DS Field Inside the IP Header
fit@hcmus

66
 IP Precedence and DSCP Compatibility

£ Compatibility with current IP precedence usage (RFC 1812)

£ Differentiates probability of timely forwarding:
(xyz000) >= (abc000) if xyz > abc
£ That is, if a packet has DSCP value of 011000, it has a greater
probability of timely forwarding than a packet with DSCP value of
001000.
67
 Behavior Aggregator, Per-Hop Behaviors

£ Behavior Aggregate (BA): the collection of packets that

have the same DSCP value (also called a codepoint)
and crossing in a particular direction.
£ Per Hop Behavior (PHB): the externally observable
forwarding behavior applied at a DS-compliant node to
a DS BA.
à PHB refers to the packet scheduling, queuing, policing,
or shaping behavior of a node on any given packet
belonging to a BA, and as configured by a Service Level
Agreement (SLA) or policy.
 Per-Hop Behaviors

£ Default Forwarding (DF) PHB — which is

typically best-effort traffic
£ Expedited Forwarding (EF) PHB — dedicated
to low-loss, low-latency traffic
£ Assured Forwarding (AF) PHB — gives
assurance of delivery under prescribed
conditions
£ Class Selector PHBs — which maintain
backward compatibility with the IP precedence
field.
 Per-Hop Behaviors

DSCP selects PHB throughout the network:

ü Default PHB (FIFO, tail drop)
ü Class-selector PHB (IP precedence)
ü EF PHB
ü AF PHB
70
fit@hcmus
Standard PHB Groups

71
 Expedited Forwarding (EF) PHB

£ EF PHB:
ü Ensures a minimum departure rate
ü Guarantees bandwidth—class guaranteed an amount of bandwidth
with prioritized forwarding
ü Polices bandwidth—class not allowed to exceed the guaranteed
amount (excess traffic is dropped)
£ DSCP value of 101110: Looks like IP precedence 5 to non-DiffServ-
compliant devices:
ü Bits 5 to 7: 101 = 5 (same 3 bits are used for IP precedence)
ü Bits 3 and 4: 11 = No drop probability
ü Bit 2: Just 0

72
 Assured Forwarding (AF) PHB

£ AF PHB:
ü Guarantees bandwidth
ü Allows access to extra bandwidth, if available
£ Four standard classes: AF1, AF2, AF3, and AF4
£ DSCP value range of aaadd0:
ü aaa is a binary value of the class
ü dd is drop probability

73
 AF PHB Values

£ Each AF class uses three DSCP values.

£ Each AF class is independently forwarded with its guaranteed
bandwidth.
£ Congestion avoidance is used within each class to prevent
congestion within the class.
74
fit@hcmus
Example
fit@hcmus Example
1. The user on ipqos1 runs the ftp command to access host ipqos2,
which is three hops away.
2. ipqos1 applies its QoS policy to the resulting packet flow. ipqos1 then
successfully classifies the ftp traffic.
3. The system administrator has created a class for all
outgoing ftp traffic that originates on the local network 10.10.0.0.
Traffic for the ftp class is assigned the AF22 per-hop behavior: class
two, medium-drop precedence. A traffic flow rate of 2Mb/sec is
configured for the ftp class.
4. ipqos-1 meters the ftp flow to determine if the flow exceeds the
committed rate of 2 Mbit/sec.
5. The marker on ipqos1 marks the DS fields in the outgoing ftp packets
with the 010100 DSCP, corresponding to the AF22 PHB.
fit@hcmus Example
6. The router diffrouter1 receives the ftp packets. diffrouter1 then checks
the DSCP. If diffrouter1 is congested, packets that are marked with AF22
are dropped.
7. ftp traffic is forwarded to the next hop in agreement with the per-hop
behavior that is configured for AF22 in diffrouter1's files.
8. The ftp traffic traverses network 10.12.0.0 to genrouter, which is not
Diffserv aware. As a result, the traffic receives “best-effort” forwarding
behavior.
9. genrouter passes the ftp traffic to network 10.13.0.0, where the traffic is
received by diffrouter2.
10. diffrouter2 is Diffserv aware. Therefore, the router forwards
the ftp packets to the network in agreement with the PHB that is defined in
the router policy for AF22 packets.
11. ipqos2 receives the ftp traffic. ipqos2 then prompts the user
on ipqos1 for a user name and password.
fit@hcmus
Questions ?

81
fit@hcmus
Additional Slides

82