Telematics 2 & Performance Evaluation Chapter 2 Quality of - PDF document

Telematics 2 & Performance Evaluation Chapter 2 Quality of Service in the Internet (Acknowledgement: These slides have been compiled from Kurose & Ross, and other sources) Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS 1 Improving QoS in IP Networks Thus far: “making the best of best effort” Alternative way: next generation Internet with QoS guarantees q RSVP: signaling for resource reservations q Differentiated Services: differential guarantees q Integrated Services: firm guarantees q Simple model for sharing and congestion studies: Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS 2

Principles for QoS Guarantees (1) q Example: 1Mbps IP phone, HTTP share 1.5 Mbps link. q Bursts of HTTP can congest router, cause audio loss q Want to give priority to audio over HTTP Principle 1 Packet marking needed for router to distinguish between different classes; and new router policy to treat packets accordingly Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS 3 Principles for QoS Guarantees (2) q What if applications misbehave (audio sends higher than declared rate) q Policing: force source adherence to bandwidth allocations q Marking and policing at network edge Principle 2 Provide protection ( isolation ) for one class from others Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS 4

Principles for QoS Guarantees (3) q 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 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS 5 Principles for QoS Guarantees (4) q Basic fact of life: cannot support traffic demands beyond link capacity Principle 4 Call Admission: flow declares its needs, network may block call (e.g., busy signal) if it cannot meet needs Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS 6

Summary of QoS Principles Let’s next look at mechanisms for achieving this …. Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS 7 Scheduling And Policing Mechanisms q Scheduling: choose next packet to send on link q FIFO (first in first out) scheduling: send in order of arrival to queue q Real-world example? q Discard policy: if packet arrives to full queue: which one to discard? ■ Tail drop: drop arriving packet ■ Priority: drop/remove on priority basis ■ Random: drop/remove randomly Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS 8

Scheduling Policies (1) Priority scheduling: transmit highest priority queued packet q Multiple classes , with different priorities q Class may depend on marking or other header info, e.g. IP source/dest, port numbers, etc.. q Real world example? 2 5 1 4 3 arrivals packet 1 2 4 in 3 5 service departures 1 3 2 4 5 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS 9 Scheduling Policies (2) Round robin scheduling: q Multiple classes q Cyclically scan class queues, serving one from each class (if available) q Real world example? 2 1 4 5 3 arrivals packet 2 4 in 1 3 5 service departures 2 1 3 4 5 Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS 10

Scheduling Policies (3) Weighted Fair Queuing: q Generalized Round Robin q Each class gets weighted amount of service in each cycle q Real-world example? Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS 11 Policing Mechanisms (1) Goal: limit traffic to not exceed declared parameters Three commonly used criteria: q (Long term) Average Rate: how many packets can be sent per unit time (in the long run) q Crucial question: what is the interval length: 100 packets per sec or 6000 packets per min have same average! q Peak Rate: e.g., q 6000 packets per min. (ppm) average q 1500 packets per second peak rate q (Max.) Burst Size: max. number of pkts sent consecutively (with no intervening idle) Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS 12

Policing Mechanisms (2) Token Bucket: limit input to specified Burst Size and Average Rate. q Bucket can hold b tokens q Tokens generated at rate r token/sec unless bucket full q Over interval of length t: number of packets admitted less than or equal to (r ⨉ t + b). Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS 13 Policing Mechanisms (3) q Token bucket, WFQ combine to provide guaranteed upper bound on delay, i.e., QoS guarantee arriving token rate, r traffic bucket size, b per-flow rate, R WFQ D = b/R arriving max traffic Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS 14

An Overview/Comparison of Proposed Approaches Usage guarantees Name What is it? Complexity QoS Int-Serv Reservation framework Y high RSVP Reservation protocol with Int-Serv high Diff-Serv Priority framework N low Label-Switching (circuit- N (not network- hidden from MPLS building) Framework wide) end-user Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS 15 Integrated Services (IntServ) q An architecture for providing QoS guarantees in IP networks for individual application sessions q Relies on resource reservation, and routers need to maintain state info (like for a virtual circuit), maintaining records of allocated resources and responding to new call setup requests on that basis Question: Can newly arriving flow be admitted with performance guarantees while not violating QoS guarantees made to already admitted flows? Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS 16

IntServ: QoS Guarantee Scenario q Resource reservation q Call setup, signaling (RSVP) q Traffic, QoS declaration q Per-element admission control request/ reply q QoS-sensitive scheduling (e.g., WFQ) Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS 17 Call Admission Arriving session must : q Declare its QoS requirement q R-spec: defines the QoS being requested q Characterize traffic it will send into network q T-spec: defines traffic characteristics q Signaling protocol: needed to carry R-spec and T-spec to routers (where reservation is required) q RSVP (Resource Reservation Protocol) Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS 18

IntServ QoS: Service Models (1) q Guaranteed service: Controlled load service: q Worst case traffic arrival: leaky- q “A quality of service closely bucket-policed source approximating the QoS that same flow would receive from q Simple (mathematically an unloaded network element.” provable) bound on delay [Parekh 1992, Cruz 1988] arriving token rate, r traffic bucket size, b per-flow rate, R WFQ D = b/R max [RFC 2211, RFC 2212] Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS 19 IntServ QoS: Service Models (2) q Guaranteed QoS q Provides with firm bounds on queuing delay at a router; q Envisioned for hard real-time applications that are highly sensitive to end- to-end delay expectation and variance q Controlled Load q Provides a QoS closely approximating that provided by an unloaded router q Envisioned for today’s IP network real-time applications which perform well in an unloaded network Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS 20

Call Admission q Call Admission: routers will admit calls based on their R-spec and T- spec and based on the current resource allocated at the routers to other calls. Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS 21 T-Spec q Defines traffic characteristics in terms of q Leaky bucket model (r = rate, b = bucket size) q Peak rate (p = how fast flow might fill bucket) q Maximum segment size (M) q Minimum segment size (m) q Traffic must remain below M + min(pT, rT+b-M) for all possible times T q M instantaneous bits permitted (pkt arrival) q M + pT: can’t receive more than 1 pkt at rate higher than peak rate q Should never go beyond leaky bucket capacity of rT+b Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS 22

R-Spec q Defines minimum q If the router allocates buffer size requirements desired by β to flow and processes flow flow(s) pkts at rate ρ then q R: rate at which packets may q R out = min(R in , ρ) be fed to a router q S out = S in – β/ρ q S: the slack time allowed q Flow accepted only if all of the (time from entry to following conditions hold destination) q ρ ³ r (rate bound) q Modified by router q β ³ b (bucket bound) ■ Let (R in , S in ) be values q S out > 0 (delay bound) that come in ■ Let (R out , S out ) be values that go out ■ S in – S out = max time spent at router Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS 23 Call Admission for Controlled Load q A more flexible paradigm q does not guarantee against losses, delays q only makes them less likely q Only T-Spec is used q routers do not admit more than they can handle over long timescales q short time-scale behavior unprotected (due to lack of R-Spec) q In comparison to QoS-Guaranteed Call Admission q more flexible admission policy q looser guarantees q depends on application’s ability to adapt ■ handle low loss rates ■ cope with variable delays / jitter Telematics 2 / Performance Evaluation (WS 17/18): 02 – Internet QoS 24