Week 6: Traffic Models and QoS 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 1996-2002 Network Performance

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

What is QoS? QoS Applications: Existing: email, 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

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

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

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

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

Measured Traffic Network Performance

Poisson Traffic Network Performance

Generated vs. Measured Traffic Network Performance

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

Why Do We Care? 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 Q : 2 components C1={v1,v3,v5,…} and C2={v2,v4,v6,…} Network Performance

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

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

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

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

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

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

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

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

Packet Classification and Marking Classification can be based on: 5-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 Network Performance

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

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

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

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

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

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

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

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

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

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