This document discusses quality of service (QoS) networking. It will cover topics like queue management, traffic shaping, admission control, routing protocols, Integrated Services, Differentiated Services, MPLS, and traffic engineering. The course will include proposals, paper presentations, quizzes, and participation. QoS aims to provide predictable network performance by prioritizing some types of traffic over others. It allows resources to be allocated to high priority services at the expense of lower priority traffic. The document discusses challenges in providing these guarantees and techniques like resource reservation, traffic contracts, scheduling algorithms, and statistical approaches.

1. CAS CS 835
QoS Networking Seminar

2. What to expect?
• Discuss latest developments and research issues,
current and possible future QoS/CoS technologies
• Queue management, traffic monitoring/shaping,
admission control, routing, …
• Focus on Internet extensions and QoS-sensitive
protocols/applications
• Integrated Services and RSVP
• Differentiated Services
• Multi Protocol Label Switching
• Traffic Engineering (or QoS Routing)

3. What to expect?
• Proposal:
pre-proposal, full proposal, presentation
• Paper presentation
• 2 quizzes
• Active participation

4. What is QoS?
• A broad definition: methods for differentiating traffic
and services
• To some, introducing an element of predictability and
consistency into a highly variable best-effort network
• To others, obtaining higher network throughput while
maintaining consistent behavior
• Or, offering resources to high-priority service classes at
the expense of lower-priority classes (conservation law)
• Or, matching network resources to application demands

5. What is Quality? Service? Why Integrated?
• Quality encompasses data loss, induced delay or latency,
consistency in delays (jitter), efficient use of network
resources, …
• Service means end-to-end communication between
applications (e.g., audio, video, Web browsing), a
protocol type (e.g., TCP, UDP), …
• A single network is better --- unused capacity is available
to others, one network to manage
• Better to give each user/traffic what it wants
• QoS mechanisms for unfairness: managing queuing
behavior, shaping traffic, control admission, routing, …
• Engineering the network is hard, and over-engineering it
is expensive (especially for long-distance links)

6. Why the recent interest in QoS?
• No longer enough for an ISP to keep traffic flowing, links
up, routing stable --- offer QoS to be more competitive
• QoS is becoming more cost-effective with improved
implementation of differentiation tools (classification,
queue-manipulation, …), more reliable tools for
measuring delivered QoS
• Hard to dimension the network as it is becoming
increasingly hard (if not impossible) to predict traffic
patterns (e.g., 80 local/20 remote rule no longer reliable,
now mostly reversed 25/75)
• If you throw more bandwidth, there will be more demand
(a “vicious cycle”)

7. Applications of a QoS Network
• Real-time: voice, video, emergency control, stock quotes ...
• Non-real-time (or best-effort): telnet, ftp, …
• Real-time:
- hard with deterministic or guaranteed QoS: no loss, packet
delay less than deadline, difference in delays of 2 packets
less than jitter bound, …
Note: reducing jitter reduces buffers needed to absorb delay
variation at receiving host
- soft with statistical or probabilistic QoS: no more than x%
of packets lost or experience delay greater than deadline, …
• Best-effort do not have such timing constraints

8. Why end-to-end control not enough?
• Problem: with common FCFS schedulers at routers, delay and delay
variance increase very rapidly with load
• For an M/M/1 model:
average delay = 1 / [ServiceRate - ArrivalRate]
= 1 / [ServiceRate (1 - Load)]
delay variance = 1 / [ (1 - Load)]
• As load increases, buffer overflows and router starts dropping packets
• Solution: TCP reduces load (slow start and congestion avoidance
algorithm)
• 2 TCP users on different hosts sharing the same bottleneck may get
different share of the bandwidth (uncontrolled unfairness) ==>
users should not trust network
• Some users may not “play by the rules” and reduce their sending rates
upon congestion, i.e. not TCP-friendly sources like a voice or video
UDP-based application ==> network should not trust users
2
e
ServiceRat

9. How to provide guarantees?
• Some form of resource reservation within the network;
hosts can’t “hide” delays
• Challenge: do it asynchronously (i.e., as needed), don’t
reserve peak rate for a voice connection/flow active 30% of
the time
• Want to support as many real-time flows as possible to
increase revenue
• Key question:
Can the network admit a new flow at its requested QoS,
without violating QoS of existing flows?
• A flow has to specify its QoS (Rspec) and also its traffic
pattern (Tspec)

10. Contract or SLA
• Service Level Agreement between client (subscriber) and
network (provider): the network keeps its promise as long as
the flow conforms to the traffic specification
• The network must monitor/police/shape incoming traffic
• The shape is important: E.g. a gigabit network contracting
with a 100Mbps flow. A big difference between sending one
100Mb packet every second and sending 1Kb packet every
10 microsec.

11. Traffic Shaping
• Leaky bucket:
- Data packets leak from a bucket of depth “sigma” at a rate
“rho”.
- Network knows that the flow will never inject traffic at a
rate higher than “rho” --- incoming traffic is bounded
- Easy to implement
- Easy for the network to police
- Accommodates well fixed-rate flows (“rho” set to rate),
but does not accommodate variable-rate (bursty) flows
unless “rho” is set to peak rate, which is wasteful

12. Token Bucket
• Allows “bounded” burstiness
• Tokens generated at rate “rho” are placed in bucket with
depth “sigma”
• An arriving packet has to remove token(s) to be allowed
into the network
• A flow can never send more than [sigma + rho * t] over an
interval of time t
• Thus, the long-term average rate will not exceed rho
• More accurate characterization of bursty flows means better
management of network resources
• Easy to implement, but harder to police
• Can add a peak-rate leaky bucket after a token bucket

13. Token Bucket
• Example:
Flow A always send at 1 MBps
==> rho = 1 MBps, sigma = 1 byte
Flow B sends at 0.5 MBps for 2 sec, then at 2
MBps for 1sec, then repeats
==> rho = 1 MBps, sigma = 1 MB
We can also this Tspec for Flow A, but that would
be an inaccurate characterization

14. Link Scheduling
• Challenge: Tspec may change at exit of scheduler (e.g., FCFS)
because of interactions among flows
• FCFS increases worst-case delay and jitter, so we admit less flows
• Solution: non-FCFS scheduler that isolates different flows or
classes of flows (hard, soft, best-effort)
• Emulate TDM without wasting bandwidth
• Virtual Clock provides flows with throughput guarantees and
isolation
• Idea: use logical (rather than real) time
• AR: average data rate required by a flow
• When a packet of size P arrives, VC = VC + P/AR
• Stamp packet with VC
• Transmit packets in increasing order of time stamps
• If a flow has twice AR, it will get double a double rate

15. Virtual Clock
• If buffer is full, the packet with largest timestamp is
dropped
• Problem: A flow can save up credits and use them to
bump other flows in the future
• Fix: when a packet arrives, catch up with real time first
VC = MAX (real time, VC)
VC = VC + P/AR
• Also, if AI is averaging interval, upon receiving AR*AI
bytes on this flow, if VC > real time + Threshold, then
send advisory to source to reduce its rate

16. WFQ
• WFQ provides isolation and delay guarantees
• FQ simulates fair bit-by-bit RR by assigning packets
priority based on finishing times under bit-by-bit RR
- E.g. Flow 1 packets of size 5 and 8, Flow 2 packet of size
10: size 5 first, then size 10, then size 8
• Round number increases at a rate inversely proportional to
number of currently active flows
• On packet arrival: recompute round number, compute finish
number, insert in priority queue, if no space drop packet
with largest finish number (max-min fairness)
• Approximation error bounded by max_pkt_size / capacity
• WFQ can assign different weights to different flows

17. Computing Deterministic Delay Bounds
• If flow is shaped by a token bucket (sigma, rho), all routers
along the “h”-hop path employ WFQ schedulers, and the
flow is assigned a rate of rho at each hop, then end-to-end
delay of a packet is bounded by:
(sigma / rho) + (h * max_pkt_size / rho) +
total approximation error + total propagation delay
• A flow is totally isolated, even if other traffic is not shaped
at all
• Cons: bandwidth and delay are coupled
• WFQ does not bound jitter
• A non-work-conserving scheduler (e.g., Stop-and-Go, jitter-
EDD) may be used to bound jitter

18. Earliest Due Date (EDD)
• Unlike WFQ, delay bound is independent of bandwidth
requirement
• Packet with earliest deadline selected
• EDD prescribes how to assign deadlines to packets
• Deadline = expected arrival time + delay bound
• “Expected” arrival time is the time the packet should
arrive according to traffic specification (to deal with
bunching of packets downstream)
• Delay bound is the smallest feasible bound, computed
assuming worst-case arrival pattern from all flows
Xmin1 = 10
Xmin2 = 4
3
3 2

19. Bounding jitter
• Assume we want to eliminate all jitter
• We can achieve this by making the network look like a
constant delay line
• Idea: At the entry of each switch/router, have a regulator
that absorbs delay variations by delaying a packet that
arrived ahead of its local deadline at previous switch
• Traffic characteristics are preserved as traffic passes through
the network
• Schedulers with regulators are called “rate-controlled”
schedulers
• Reduce burstiness within network, thus less buffers needed
• Average packet delay is higher than with work-conserving
schedulers, but that’s fine for hard real-time traffic

20. Statistical/soft/predictive QoS
• Goal: bound the tail of the measure distribution
• Not a good idea to use worst-case delay bounds since
very few packets (or none!) will actually experience
this worst-case delay
• Computing statistical bounds (e.g., using effective
bandwidths) is usually approximate and often
conservative
• FIFO+ attempts to reduce worst-case delay and jitter
using minimal isolation (and maximal statistical gain)
• At each router, a packet is assigned lower priority if it
left previous routers ahead of measured average delay,
and higher priority if behind average delay

21. Admission Control with Statistical Guarantees
• Key idea (law of large numbers): as capacity increases,
number of flows that can be supported increases, the
probability that a significant number of flows burst
simultaneously decreases, so the sum of peak rates can
be higher than the available capacity
• As the number of flows increases, the capacity allocated
to each flow is “effectively” its average rate
• Put in enough buffers to make probability of loss low

22. Measurement-based Admission
• Key assumption: past behavior is a good indicator of
the future
• User tells peak rate
• If peak rate + measured average rate < capacity, admit
• Over time, new call becomes part of average
• Can afford to make some errors for predictive (or
controlled load) service
• Obviously, can admit more calls than admission at
peak rate

23. Summary
• Performance guarantees can be achieved by combining
traffic shaping and scheduling schemes
• How good the bounds are? Loose or tight?
• How easy to implement these schemes?
• What kind of guarantees they provide?
• How good is the utilization of the network?
• How do clients signal their QoS requirements?
• What is the best path to route a flow?
• How to achieve QoS for multicast flows and with
mobility?

24. RSVP ReSerVation Protocol
• Designed to handled multicast flows, where multiple receivers may
have different capabilities
• RSVP is receiver-initiated, i.e. receiver generates reservation
• PATH message tentatively reserves resources, RESV makes
reservation (travels as far back up as necessary)
• RSVP supports merging of reservations
• RSVP is decoupled from routing
• PATH and RESV messages periodically sent to refresh state before
timeout (i.e. soft state)
• Multiple senders can share the same reservation
• In contrast, ATM signaling (Q.2931) is sender-initiated, coupled with
routing, uses hard state (i.e. explicit delete), and handles only uniform
QoS

25. Where to Implement Policies in a Network Topology?
Or, QoS Architectures
• Key to scaling is to maintain levels of hierarchy: core, distribution,
and access
• Link speeds should be faster toward the core of the network
• Access routers generally do not have to handle high packet switching
rates and thus can do complex traffic identification, classification,
policing and marking
• The overhead of implementing QoS policies in the core would affect a
large amount of traffic
• Access routers can mark the IP precedence field in the packet header
• Core routers simply map precedence to queuing or drop actions
• This is similar to the IETF DiffServ architecture (as opposed to the
“less scalable” per-flow IETF IntServ architecture)

26. Tension: Scalability versus QoS
• Scalability calls for aggregating flows into precedence
classes
• Also, aggregating destinations results in fewer routing
entries, but less granularity of routing decisions
• Performing disaggregation gives finer granularity at a
higher cost
• E.g. more detailed routing advertisments can allow more
granular choice of paths that better satisfy QoS
requirements
• OSPF can advertise multiple costs per link, and compute
multiple shortest paths
• Or, loose source route through a particular service
provider, or multiple addresses/names per host

27. Other QoS Requirements/Issues
• Pricing/Billing
- can shift demand to off-peak times
- charge more during peak hours
- rational users help the network by helping themselves
• Privacy
• Reliability and availability
• Operating systems support
- reduce costs of data copying, interrupts, …
- real-time CPU scheduling, ...