1. Better-than-best-effort: QoS, IntServ, DiffServ, RSVP, RTP: BRIEF VERSION
Shivkumar Kalyanaraman
Rensselaer Polytechnic Institute
Based in part on slides of Ion Stoica, Jim Kurose, Srini Seshan, Srini Keshav

2. Overview Why better-than-best-effort (QoS-enabled) Internet ?
Quality of Service (QoS) building blocks
End-to-end protocols: RTP, H.323
Network protocols:
Integrated Services(IntServ), RSVP.
Scalable differentiated services: DiffServ
Control plane: QoS routing, traffic engineering, policy management, pricing models

3. Why Better-than-Best-Effort (QoS)?
To support a wider range of applications
Real-time, Multimedia, etc
To develop sustainable economic models and new private networking services
Current flat priced models, and best-effort services do not cut it for businesses

4. Quality of Service: What is it?
Multimedia applications: network audio and video
network provides application with level of performance needed for application to function.
QoS

5. What is QoS?
“Better performance” as described by a set of parameters 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

6. What is QoS (contd) ?
These parameters can be measured at several granularities:
“micro” flow, aggregate flow, population.
QoS considered “better” if
a) more parameters can be specified
b) QoS can be specified at a fine-granularity.
QoS spectrum:
Best Effort
Leased Line

7. Fundamental Problems Scheduling Discipline B B
FIFO B
In a FIFO service discipline, the performance assigned to one flow is convoluted with the arrivals of 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 of background traffic

8. Fundamental Problems Conservation Law (Kleinrock): (i)Wq(i) = K
Irrespective of scheduling discipline chosen:
Average backlog (delay) is constant
Average bandwidth is constant
Zero-sum game => need to “set-aside” resources for premium services

9. QoS Big Picture: Control/Data Planes

10. QoS Components QoS => set aside resources for premium services
a) Specification of premium services: (service/service level agreement design)
b) How much resources to set aside? (admission control/provisioning)
c) How to ensure network resource utilization, do load balancing, flexibly manage traffic aggregates and paths ?
(QoS routing, traffic engineering)

11. QoS Components (Continued)
d) How to actually set aside these resources in a distributed manner ?
(signaling, provisioning, policy)
e) How to deliver the service when the traffic actually comes in (claim/police resources)?
(traffic shaping, classification, scheduling)
f) How to monitor quality, account and price these services?
(network mgmt, accounting, billing, pricing)

12. How to upgrade the Internet for QoS?
Approach: de-couple end-system evolution from network evolution
End-to-end protocols: RTP, H.323 etc to spur the growth 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

13. QOS SPECIFICATION, TRAFFIC, SERVICE CHARACTERIZATION, BASIC MECHANISMS

14. 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

15. 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 curve framework)

16. 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
bits
slope r
b*R/(R-r)
b tokens
slope R
<= R bps
time
regulator

17. Characterizing a Source by Token Bucket
Arrival curve – maximum amount of bits transmitted by time t
Use token bucket to bound the arrival curve
bps
bits
Arrival curve
time
time

18. Example Arrival curve – maximum amount of bits transmitted by time t
Use token bucket to bound the arrival curve
(b=1,r=1,R=2)
Arrival curve
bits 4
bps 3 2 2 1 1 1 2 3 4 5
time 1 2 3 4 5
size of time
interval

19. Per-hop Reservation Given b,r,R and per-hop delay d
Allocate bandwidth ra and buffer space Ba such that to guarantee d
slope ra
slope r
bits
Arrival curve b d Ba

20. What is a Service Model?
“external process”
Network element
delivered traffic
offered traffic
(connection oriented)
The QoS measures (delay,throughput, loss, cost) depend on offered traffic, and possibly other external processes.
A service model attempts to characterize the relationship between offered traffic, delivered traffic, and possibly other external processes.

21. Arrival and Departure Process
Network Element
Rin
Rout
bits
Rin(t) = arrival process
= amount of data arriving up to time t
delay
buffer
Rout(t) = departure process
= amount of data departing up to time t t

22. Traffic Envelope (Arrival Curve)
Maximum amount of service that a flow can send during an interval of time t
b(t) = Envelope
slope = max average rate
“Burstiness Constraint”
slope = peak rate t

23. Service Curve
Assume a flow that is idle at time s and it is backlogged during the interval (s, t)
Service curve: the minimum service received by the flow during the interval (s, t)

24. Big Picture Service curve bits bits Rin(t) slope = C t t bits Rout(t)

25. Delay and Buffer Bounds
bits
E(t) = Envelope
Maximum delay
Maximum buffer
S (t) = service curve t

26. Mechanisms: Traffic Shaping/Policing
Token bucket: limits input to specified Burst Size (b) and Average Rate (r).
Traffic sent over any time T <= r*T + b
a.k.a Linear bounded arrival process (LBAP)
Excess traffic may be queued, marked BLUE, or simply dropped

27. Mechanisms: Queuing/Scheduling
Traffic
Sources
Traffic
Classes
$$$$$$
Class A
$$$
Class B $
Class C
Use a few bits in header to indicate which queue (class) a packet goes into (also branded as CoS)
High $$ users classified into high priority queues, which also may be less populated
=> lower delay and low likelihood of packet drop
Ideas: priority, round-robin, classification, aggregation, ...

28. Mechanisms: Buffer Mgmt/Priority Drop
Drop RED and BLUE packets
Drop only BLUE packets
Ideas: packet marking, queue thresholds, differential dropping, buffer assignments

29. SCHEDULING

30. Packet Scheduling Decide when and what packet to send on output link
Usually implemented at output interface
flow 1
Classifier
flow 2 1
Scheduler 2
flow n
Buffer management

31. Focus: Scheduling Policies
Priority Queuing: classes have different priorities; class may depend on explicit marking or other header info, eg IP source or destination, TCP Port numbers, etc.
Transmit a packet from the highest priority class with a non-empty queue
Preemptive and non-preemptive versions

32. Scheduling Policies (more)
Round Robin: scan class queues serving one from each class that has a non-empty queue

33. 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 – a flow receives service proportional to the number of packets

34. Generalized Processor Sharing(GPS)
Assume a fluid model of traffic
Visit each non-empty queue in turn (RR)
Serve infinitesimal from each
Leads to “max-min” fairness
GPS is un-implementable!
We cannot serve infinitesimals, only packets

35. Generalized Processor Sharing
A work conserving GPS is defined as
where
wi – weight of flow i
Wi(t1, t2) – total service received by flow i during [t1, t2)
W(t1, t2) – total service allocated to all flows during [t1, t2)
B(t) – number of flows backlogged

36. Fair Rate Computation in GPS
Associate a weight wi with each flow i
If link congested, compute f such that
f = 2:
min(8, 2*3) = 6
min(6, 2*1) = 2
min(2, 2*1) = 2
(w1 = 3) 8 10 4
(w2 = 1) 6 4 2
(w3 = 1) 2

37. Bit-by-bit Round Robin
Single flow: 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 = max (Fi-1, Ai) + Pi
Multiple flows: clock ticks when a bit from all active flows is transmitted  round number
Can calculate Fi for each packet if number of flows is known at all times
This can be complicated

38. Packet Approximation of Fluid System
Standard techniques of approximating fluid GPS
Select packet that finishes first in GPS assuming that there are no future arrivals
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

39. Fair Queuing (FQ)
Idea: serve packets in the order in which they would have finished transmission in the fluid flow system
Mapping bit-by-bit schedule onto packet transmission schedule
Transmit packet with the lowest Fi at any given time
Variation: Weighted Fair Queuing (WFQ)

40. Approximating GPS with WFQ
Fluid GPS system service order 2 4 6 8 10
Weighted Fair Queueing
select the first packet that finishes in GPS

41. 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

42. Modeling: System Virtual Time: V(t)
Measure service, instead of time
V(t) slope – rate at which every active flow receives service
C – link capacity
N(t) – number of active flows in fluid system at time t
V(t)
time
Service
in fluid flow
system 1 2 3 4 5 6 1 2 3 4 5
time

43. 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 to drop in case of congestion. Which packet’s would you drop in FQ?
one possibility: packet from the longest queue

44. QoS ARCHITECTURES

45. Parekh-Gallager theorem
Let a connection be allocated weights at each WFQ scheduler along its path, so that the least bandwidth it is allocated is g
Let it be leaky-bucket regulated such that # bits sent in time [t1, t2] <= g(t2 - t1) + 
Let the connection pass through K schedulers, where the kth scheduler has a rate r(k)
Let the largest packet size in the network be P

46. Significance
P-G Theorem shows that WFQ scheduling can provide end-to-end delay bounds in a network of multiplexed bottlenecks
WFQ provides both bandwidth and delay guarantees
Bound holds regardless of cross traffic behavior (isolation)
Needs shapers at the entrance of the network
Can be generalized for networks where schedulers are variants of WFQ, and the link service rate changes over time

47. Stateless vs. Stateful QoS Solutions
Stateless solutions – routers maintain no fine grained state about traffic
scalable, robust
weak services
Stateful solutions – routers maintain per-flow state
powerful services
guaranteed services + high resource utilization
fine grained differentiation
protection
much less scalable and robust
Now, the main difference between stateless and stateful solutions is while stateful solutions requires all routers to maintain and manage per flow state, stateless solutions do not require core routers to maintain any per flow state. As a result stateless solutions maintain the advantages of the current Internet in terms of scalability and robustness. The downside is that usually provide weak services.
In contrast while stateful solutions can provide very powerful services such as simultaneously provide guarantees and achieve high resource utilization, fine grained differentiation, and protection. Unfortunately, these solutions are muche less scalable and robust than the stateless solutions.

48. Existing Solutions Stateful Stateless QoS Tenet [Ferrari & Verma ’89]
IntServ [Clark et al ’91]
ATM [late ’80s]
DiffServ
- [Clark &
Wroclawski ‘97]
- [Nichols et al ’97]
Network support for congestion control
Round Robin [Nagle ’85]
Fair Queueing [Demers et al ’89]
Flow Random Early Drop (FRED) [Lin & Morris ’97]
DecBit [Ramkrishnan & Jain ’88]
Random Early Detection (RED) [Floyd & Jacobson ’93]
BLUE [Feng et al ’99]
REM [Low at al ’00]
Starting with late 80s a plethora of solutions have been proposed to provide better network services. These solutions can be classified in stateless and stateful.
Examples of stateless…

49. 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 respond to new Call setup requests

50. 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

51. RSVP: Internet Signaling
Creates and maintains distributed reservation state
De-coupled from routing:
Multicast trees setup by routing protocols, not RSVP (unlike ATM or telephony signaling)
Receiver-initiated: scales for multicast
Soft-state: reservation times out unless refreshed
Latest paths discovered through “PATH” messages (forward direction) and used by RESV mesgs (reverse direction).

52. Call Admission
Session must first declare its QOS requirement and characterize the traffic it will send through the network
R-spec: defines the QOS being requested
T-spec: defines the traffic characteristics
A signaling protocol is needed to carry the R-spec and T-spec to the routers where reservation is required; RSVP is a leading candidate for such signaling protocol

53. Call Admission
Call Admission: routers will admit calls based on their R-spec and T-spec and base on the current resource allocated at the routers to other calls.

54. Stateful Solution: Guaranteed Services
Achieve per-flow bandwidth and delay guarantees
Example: guarantee 1MBps and < 100 ms delay to a flow
Receiver
Sender

55. Stateful Solution: Guaranteed Services
Allocate resources - perform per-flow admission control
Receiver
Sender

56. Stateful Solution: Guaranteed Services
Install per-flow state
Receiver
Sender

57. Stateful Solution: Guaranteed Services
Challenge: maintain per-flow state consistent
Receiver
Sender

58. Stateful Solution: Guaranteed Services
Per-flow classification
Receiver
Sender

59. Stateful Solution: Guaranteed Services
Per-flow buffer management
Receiver
Sender

60. Stateful Solution: Guaranteed Services
Per-flow scheduling
Receiver
Sender

61. 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
Per-flow State …
flow 1
flow 2
Scheduler
Classifier
flow n
Buffer
management
output interface

62. Stateless vs. Stateful Stateless solutions are more scalable robust
Stateful solutions provide more powerful and flexible services
guaranteed services + high resource utilization
fine grained differentiation
protection

63. Question
Can we achieve the best of two worlds, i.e., provide services implemented by stateful networks while maintaining advantages of stateless architectures?
Yes, in some interesting cases. DPS, CSFQ.
Can we provide reduced state services, I.e., maintain state only for larger granular flows rather than end-to-end flows?
Yes: Diff-serv

64. Differentiated Services (DiffServ)
Intended to address the following difficulties with Intserv and RSVP;
Scalability: maintaining states by routers in high speed networks is difficult sue to the very large number of flows
Flexible Service Models: Intserv has only two classes, want to provide more qualitative service classes; want to provide ‘relative’ service distinction (Platinum, Gold, Silver, …)
Simpler signaling: (than RSVP) many applications and users may only w ant to specify a more qualitative notion of service

65. Differentiated Services Model
Interior Router
Egress
Edge Router
Ingress
Edge Router
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

66. Diffserv Architecture
Edge router:
- per-flow traffic management
- marks packets as in-profile and out-profile
scheduling . r b
marking
Core router:
- per class TM
- buffering and scheduling
based on marking at edge
- preference given to in-profile packets
- Assured Forwarding

67. Packet format support
Packet is marked in the Type of Service (TOS) in IPv4, and Traffic 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

68. Traffic Conditioning
It may be desirable to limit traffic injection rate of some class; user declares traffic profile (eg, rate and burst size); traffic is metered and shaped if non-conforming

69. 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 use to 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

70. PHB (contd) PHBs under consideration:
Expedited Forwarding: 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: 4 classes, each guaranteed a minimum amount of bandwidth and buffering; each with three drop preference partitions
Emulates frame-relay behavior

71. Question
Can we achieve the best of two worlds, i.e., provide services implemented by stateful networks while maintaining advantages of stateless architectures?
Yes, in some interesting cases. DPS, CSFQ.
Can we provide reduced state services, I.e., maintain state only for larger granular flows rather than end-to-end flows?
Yes: Diff-serv

72. Scalable Core (SCORE)
A trusted and contiguous region of network in which
edge nodes – perform per flow management
core nodes – do not perform per flow management
core nodes
edge nodes

73. The DPS Approach
Define a reference stateful network that implements the desired service
SCORE Network
. Emulate the functionality of the reference
network in a SCORE network
Reference Stateful Network

74. The DPS Idea
Instead of having core routers maintaining per-flow state have packets carry per-flow state
Reference Stateful Network
SCORE Network

75. Dynamic Packet State (DPS)
Ingress node: compute and insert flow state in packet’s header

76. Dynamic Packet State (DPS)
Ingress node: compute and insert flow state in packet’s header

77. Dynamic Packet State (DPS)
Core node:
process packet based on state it carries and node’s state
update both packet and node’s state

78. Dynamic Packet State (DPS)
Egress node: remove state from packet’s header

79. Example: DPS-Guaranteed Services
Goal: provide per-flow delay and bandwidth guarantees
How: emulate ideal model in which each flow traverses dedicated links of capacity r
Per-hop packet service time = (packet length) / r r r r
flow
(reservation = r )
Our goal here is to provide per-flow delay and bandwidth guarantees.
To achieve this goal our approach is to approximate an ideal model in which each flow traverses only dedicated links of capacity r, where r is the flow reservation. Thus, in the ideal model flows are completely isolated. Again, a flow behaves as it owns links of capacity r along its path, and it is the only one to use them. In such model the per-hop service time or transmission time is simply the packet length over the flow’s reservation.
Such a simple and powerful abstraction makes it easy to compute the end-to-end delay given the flow’s arrival rate. Reversing the problem, given the flow’s arrival rate and the number of hops along its path, then we can can meet any end-to-end delay requirements as long as these are larger than the propagation delay, by choosing an appropriate reservation. This is what allows us to guarantee delay bounds in this model.

80. Reality: End-to-end Adaptive Applications
Video Coding, Error Concealment, Unequal Error Protection (UEP)
Video Coding, Error Concealment, Unequal Error Protection (UEP)
Packetization, Marking, playout
Buffer Management
Packetization, Marking, Source
Buffer Management
Congestion control
Congestion control
Internet
End-to-end
Closed-loop control

81. End-to-end: Real-Time Protocol (RTP)
Provides standard packet format for real-time application
Typically runs over UDP
Specifies header fields below
Payload Type: 7 bits, providing 128 possible different types of encoding; eg PCM, MPEG2 video, etc.
Sequence Number: 16 bits; used to detect packet loss

82. Real-Time Protocol (RTP)
Timestamp: 32 bytes; gives the sampling instant of the first audio/video byte in the packet; used to remove jitter introduced by the network
Synchronization Source identifier (SSRC): 32 bits; an id for the source of a stream; assigned randomly by the source

83. RTP Control Protocol (RTCP)
Protocol specifies report packets exchanged between sources and destinations of multimedia information
Three reports are defined: Receiver reception, Sender, and Source description
Reports contain statistics such as the number of packets sent, number of packets lost, inter-arrival jitter
Used to modify sender transmission rates and for diagnostics purposes

84. Eg: Streaming & RTSP
User interactive control is provided, e.g. the public protocol Real Time Streaming Protocol (RTSP)
Helper Application: displays content, which is typically requested via a Web browser; e.g. RealPlayer; typical functions:
Decompression
Jitter removal
Error correction: use redundant packets to be used for reconstruction of original stream
GUI for user control

85. Using a Streaming Server
Web browser requests and receives a Meta File (a file describing the object)
Browser launches the appropriate Player and passes it the Meta File;
Player contacts a streaming server, may use a choice of UDP vs. TCP to get the stream

86. Receiver Adaptation Options
If UDP: Server sends at a rate appropriate for client; to reduce jitter, Player buffers initially for 2-5 seconds, then starts display
If TCP: sender sends at maximum possible rate; retransmit when error is encountered; Player uses a much large buffer to smooth delivery rate of TCP

87. H.323
H.323 is an ITU standard for multimedia communications over best-effort LANs.
Part of larger set of standards (H.32X) for videoconferencing over data networks.
H.323 includes both stand-alone devices and embedded personal computer technology as well as point-to-point and multipoint conferences.
H.323 addresses call control, multimedia management, and bandwidth management as well as interfaces between LANs and other networks.

88. H.323 Architecture

89. Inter-domain QoS: Challenge
Provide high quality service across ISPs
Problem: intermediate ISPs don’t have incentive to provide “good” service
e.g., “hot-potato” policy
ISP 2 ?
ISP 3
ISP 1

90. Approach: Virtual ISP (V-ISP)
Avoid crossing ISP boundaries
Each ISP will provide good service; V-ISP can easily verify it
Allocate/buy service across each ISP and compose them
GPoP
(core)
GPoP
(core)
ISP 2
Proxy
(edge)
Proxy
(edge)
ISP 3
ISP 1

91. Composition Tools for QoS
Dynamic Packet State (DPS):
Proxy (edge): maintain per flow state; label packets
Giga PoPs (core): maintain no per flow state; process packets based on their labels I E
Logical FIFO B
Closed-loop building blocks:
No core upgrades, smaller QoS service spectrum

92. Closed-Loop Building Blocks for QoS
International Link or
International Link or
Traffic passes through multiple peering points.
FIFOs at each bottleneck

93. Closed-loop QoS Building Blocks
Priority/WFQ
FIFO B  B
Scheduler: differentiates service on a packet-by-packet basis
Loops: differentiate service on an RTT-by-RTT basis using purely edge-based policy configuration.

94. Recall: Accln-based Control Policy1 j
j+1 J
μij
Λi,j+1 dj fi Λi μi
control objective : keep
if , no way to probe increase of available bandwidth;
control algorithm : 94

95. Closed-Loop Service Differentiation: Loss-based or Accumulation-based ?95

96. Closed-Loop QoS: Bandwidth Assurances
Flow 1 with 4 Mbps assured
+ 3 Mbps best effort
Flow 2 with 3 Mbps best effort

97. QoS: an application-level approach
sophisticated services in application
architecturally “above” network core
simple, fast, diffserv network

98. QoS: an application-level approach
Application-level infrastructure
accommodate network-level service
additional tailoring of user services

99. Content Delivery Motivation: congestion
Networks
Browsers
Routers
Web Servers

100. Content Delivery: idea Avoids network congestion
Reduces load on server
Avoids network congestion
Browsers
Replicated content
Content Sink
Router
Content Source
Web Server

101. CDN: Architectural Layout
Request
Routing(RR) 4 1
Client 5
Distribution
System
Origin 2 6 3
Surrogate
Publisher informs RR of Content Availability.
Content Pushed to Distribution System.
Client Requests Content, Requested redirected to RR.
RR finds the most suitable Surrogate
Surrogate services client request.

102. Summary QoS big picture, building blocks
Integrated services: RSVP, 2 services, scheduling, admission control etc
Diff-serv: edge-routers, core routers; DS byte marking and PHBs
Real-time transport/middleware: RTP, H.323
New problems: inter-domain QoS, Application-level QoS, Content delivery/web caching