1. All Rights Reserved, copyright 1999-2002
Traffic Models and QoS
TELE4642: Week9
Acknowledgement: Some slides are adapted from “Computer Networking: A Top Down Approach Featuring the Internet”, 2nd edition, J.F Kurose and K.W. Ross
All Rights Reserved, copyright

2. Outline What is QoS? What does Internet traffic look like?
Is it Poisson?
What are the implications for network performance?
Approaches to providing QoS:
Laissez faire approach
No change to network; Application-level bag of tricks
Structured approach
Change network to provide some performance guarantees
QoS mechanisms:
Packet classification and marking
Packet policing/shaping
Packet scheduling
Resource allocation
IETF IntServ and DiffServ frameworks
Network Performance

3. What is QoS?
Applications:
Existing: , ftp, web; delay insensitive, loss sensitive
Emerging: VoIP, multimedia; delay sensitive, loss insensitive
Streaming stored/live audio and video
Real-time interactive audio and video
Integrated network to support existing and new apps
Best-effort model adequate?
network provides application with level of performance needed for application to function.
QoS
Network Performance

4. Internet Traffic: Need a model
All performance techniques must make some assumptions regarding traffic
Analytical models: arrival and service time distributions
Simulation: traffic generators
Experiments: traffic traces or real traffic
Analysis of trace data
A trace is captured from a “live” network
Normally want to statistically characterize the trace to build a model, but may be able to use the trace directly
How do we know our sample is typical or large enough?
Network Performance

5. Markovian Models Poisson Process Variations: 1
Appropriate if there is a large number of independent users and no source dominates?
We know and love it! (good handle on M/M/1 queues)
Variations:
Markov Modulated Poisson Process (MMPP)
A Poisson arrival process with time-varying arrival rate (t)
Process “modulating” the Poisson arrivals has a Markov chain
Markov Modulated Fluid Process (MMFP)
Embedded Markov models, Regression models, …
01 1
rate 1
rate 2
10
Network Performance

6. Traffic Burstiness Variability in traffic rate / volume
Why is burstiness important?
Peak traffic demands on buffer resources can lead to overflow and lost traffic
Peak demands may create quality of service (QoS) problems in a network
Need to characterize burstiness for traffic sources in a QoS environment
Can be characterized in many ways:
Ratio of peak rate to mean rate
Coefficient of variation of traffic load over different intervals
Index of dispersion of intervals (IDI)
Index of sipersion of counts (IDC)
Spectral (frequency) characteristics
Stochastic process entropy rate
Network Performance

7. Traffic Modeling
Pre-1990’s: Traffic modeling in the world of telephony was the basis for initial network models
Assumed Poisson arrival process
Assumed exponential call duration
Well established queuing literature based on these assumptions
Enabled very successful engineering of telephone networks
In 1989, Leland and Wilson begin taking high resolution traffic traces at Bellcore
Ethernet traffic from a large research lab
100 msec time stamps
Packet length, status, 60 bytes of data
Mostly IP traffic (a little NFS)
Four data sets over three year period
Over 100 million packets in traces
Traces considered representative of normal use
Network Performance

8. Measured Traffic
Network Performance

9. Poisson Traffic
Network Performance

10. Generated vs. Measured Traffic
Network Performance

11. Fractals: Scaling property
A Poisson process
When observed on a fine time scale will appear bursty
When aggregated on a coarse time scale will flatten (smooth) to white noise
A Self-Similar (fractal) process
A phenomenon that is self-similar looks or behaves the same when viewed at different degrees of “magnification” or different scales on a dimension (time or space)
When aggregated over wide range of time scales will maintain its bursty characteristic
Hurst parameter H (0.5  H  1) measures degree of self-similarity
Network Performance

12. Generated vs. Measured Traffic
If network traffic is self-similar, there is significant amount of clustering at all time scales
Requires more buffering
Leads to higher queueing delays
Mean waiting time Queue occupancy
Network Performance

13. IP QoS History Inception: ToS byte in IP header 1986: TCP developed
Early-1990s: QoS mechanisms for routers:
Packet scheduling
Packet dropping
Traffic conditioning
Resource allocation
Mid-1990s: IntServ framework
firm guarantees (“contract”)
Late-1990s: DiffServ framework
“Classes” that receive differential service
2000s: MPLS and Traffic Engineering
Network Performance

14. QoS in Today’s Internet
TCP/UDP/IP: “best-effort service”
no guarantees on delay, loss
But you said multimedia apps requires
QoS and level of performance to be
effective! ?
Today’s Internet multimedia applications
use application-level techniques to mitigate
(as best possible) effects of delay, loss
Network Performance

15. Ad-hoc approach: Application-level solutions
Example: Internet Phone
UDP: avoid TCP congestion control (delays) for time-sensitive traffic
Delay compensation: adaptive play-out delay at client
Loss compensation:
FEC, interleaving, retransmissions
Bandwidth estimation: server side matches stream bandwidth to available client-to-server path bandwidth
chose among pre-encoded stream rates
dynamic server encoding rate
Network Performance

16. Structured approach: Principles
Example: 1Mbps IP phone, FTP share 1.5 Mbps link.
bursts of FTP can congest router, cause audio loss
want to give priority to audio over FTP
Principle 1
packet classification and marking needed for router to distinguish traffic
Network Performance

17. Principles for QOS (contd.)
what if applications misbehave (audio sends higher than declared rate)
Policing/shaping: force source to adherence to bandwidth allocations
Principle 2
provide protection (isolation) for one class from others
Network Performance

18. Principles for QOS (contd.)
Allocating fixed (non-sharable) bandwidth to flow: inefficient use of bandwidth if flows doesn’t use its allocation
Principle 3
While providing isolation, it is desirable to use resources as efficiently as possible
Network Performance

19. Principles for QOS (contd.)
Basic fact of life: can not support traffic demands beyond link capacity
Principle 4
Resource allocation and Call Admission: network may
block call (e.g., busy signal) if it cannot meet needs
Network Performance

20. Summary of QoS Principles
Let’s next look at mechanisms for achieving this ….
Network Performance

21. Packet Classification and Marking
Classification can be based on:
9-tuple: <src-IP, dst-IP, proto, src-port, dst-port>
Ethernet MAC addresses
Packet content: e.g. URL
Marking done in IP ToS byte, now renamed the Diff-Serv Code Point (DSCP) byte
Core routers can use marking, need not reclassify

22. Policing and Shaping
Goal: limit traffic to not exceed declared parameters
Three common-used criteria:
(Long term) Average Rate
Peak Rate
(Maximum) Burst Size
Policing/Shaping Mechanism:
Token Bucket: limit input to specified Burst Size and Average Rate.
bucket can hold b tokens
tokens generated at r token/sec unless bucket full
over interval of length t: number of packets/bytes admitted no more than (r t + b).
Network Performance

23. Packet Scheduling scheduling: choose next packet to send on link
FIFO (first in first out) scheduling:
send in order of arrival to queue
example: supermarket check-out
Network Performance

24. Scheduling Policies (contd.)
Priority scheduling: transmit highest priority queued packet
multiple classes, with different priorities
class may depend on marking or other header info, e.g. IP source/dest, port numbers, etc..
example: airline check-in?
Network Performance

25. Scheduling Policies (contd.)
Weighted Fair Queuing:
generalized Round Robin
each class gets weighted amount of service in each cycle
real-world example?
Network Performance

26. QoS-sensitive scheduling (e.g., WFQ)
Resource Reservation
RSVP (ReSerVation Protocol)
call setup, signaling
traffic, QoS declaration
per-element admission control
request/
reply
QoS-sensitive scheduling (e.g., WFQ)
Network Performance

27. IETF Integrated Services (IntServ)
Objective: QOS guarantees for individual application sessions
resource reservation: routers maintain state info of allocated resources, QoS req’s
admit/deny new call setup requests:
Question: can newly arriving flow be admitted
with performance guarantees while not violated
QoS guarantees made to already admitted flows?
Network Performance

28. IntServ Architecture Policing/shaping: token bucket
Per-flow classification and queueing
WFQ scheduling
Resource reservation / call admission
All the above combine to provide guaranteed upper bound on delay, i.e., QoS guarantee!
WFQ
token rate, r
bucket size, b
per-flow
rate, R
D = b/R
max
arriving
traffic
Network Performance

29. IETF Differentiated Services (DiffServ)
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
“behaves like a wire”
relative service distinction: Platinum, Gold, Silver
Diffserv approach:
simple functions in network core, relatively complex functions at edge routers (or hosts)
Do’t define define service classes, provide functional components to build service classes
Network Performance

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

31. How should the Internet evolve to better support multimedia?
Integrated services philosophy:
Fundamental changes in Internet so that apps can reserve end-to-end bandwidth
Requires new, complex software in hosts & routers
Differentiated services philosophy:
Fewer changes to Internet infrastructure, yet provide 1st and 2nd class service.
Laissez-faire
no major changes
more bandwidth when needed
content distribution, application-layer multicast
application layer
What’s your opinion?
Network Performance