370 likes | 516 Views
Quality of Service & Traffic Engineering (QoS & TE) Khaled Mohamed Credit: some of the sides are from Cisco Systems. QOS and TE in IP Network The QoS and TE Architectures QOS and TE Service Types The Technical Scenarios Reasons The Applications and Their Needs Q&A. Agenda.
E N D
Quality of Service & Traffic Engineering (QoS & TE)Khaled MohamedCredit: some of the sides are from Cisco Systems
QOS and TE in IP Network The QoS and TE Architectures QOS and TE Service Types The Technical Scenarios Reasons The Applications and Their Needs Q&A Agenda
Thus far:“making the best of best effort” Future:next-generation Internet with QoS guarantees Differentiated Services:differential guarantees Integrated Services:firm guarantees Example:guarantees an audio application 1Mbps; the remaining to 0.5Mbps to Web transfer QoS in IP Networks
Principles for QoS Guarantees packet classification:router can distinguish between different classes
prevents applications from misbehaving (e.g., multimedia app. sends higher than declared rate) Principles for QoS Guarantees scheduling and policing: provide protection (isolation)
Allocating fixed (non-sharable) bandwidth to flow: inefficient use of bandwidth if flows doesn’t use its allocation Principles for QoS Guarantees high utilization: while providing isolation, it is desirable to use resources as efficiently as possible
Basic fact of life: cannot support traffic demands beyond link capacity Principles for QoS Guarantees call admission:flow declares its needs, network may block call (e.g., busy signal) if it cannot meet needs
Three common-used criteria: (Long term) Average Rate:how many pkts can be sent per unit time (in the long run) crucial question: what is the interval length: 100 packets per sec or 6000 packets per min have same average! Peak Rate:e.g., 6000 pkts per min. (ppm) avg.; 1500 ppm peak rate (Max.) Burst Size:max. number of pkts sent consecutively (with no intervening idle) Traffic Specification
Token Bucket:limit input to specified Burst Size and Average Rate. bucket can hold b tokens tokens generated at rate r token/sec unless bucket full over interval of length t: number of packets admitted less than or equal to (r t + b). Traffic Specification
scheduling:choose next packet to send on link FIFO (first in first out) scheduling:send in order of arrival to queue discard policy:if packet arrives to full queue: who to discard? tail drop: drop arriving packet priority: drop/remove on priority basis random: drop/remove randomly Scheduling Mechanisms
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.. Scheduling Policies: more
round robin scheduling: multiple classes cyclically scan class queues, serving one from each class (if available) Scheduling Policies: still more
Weighted Fair Queuing: generalized Round Robin each class gets weighted amount of service in each cycle Scheduling Policies: still more .
token bucket, WFQ combine to guarantee upper bound on delay, i.e.,QoS guarantee! token rate, r arriving traffic bucket size, b assigned flow rate, R WFQ D = b/R max Delay Guarantees
QOS Type of Services • Integrated services • Differentiated services
Architecture for providing QoS guarantees in IP networks for individual application sessions Assumptions use a common infrastructure for both real-time and non-real-time communications resource must be explicitly managed in order to meet the requirements of real-time applications resource reservation: routers maintain state info (a la VC) of allocated resources, QoS req’s IETF IntServ Services
Guaranteed service: worst case traffic arrival: leaky-bucket-policed source simple (mathematically provable)boundon delay [Parekh 1992, Cruz 1988] token rate, r arriving traffic bucket size, b per-flow rate, R WFQ D = b/R max Intserv QoS: Service Models [rfc2211, rfc 2212] Controlled load service: • "a quality of service closely approximating the QoS that same flow would receive from an unloaded network element." Controlled link sharing: • Sharing link among different classes
Reference Architecture Routing RSVP Routing Messages RSVP messages ControlPlane Admission Control Data Plane Forwarding Table Per Flow QoS Table Data In Route Lookup Classifier Scheduler Data Out
A Closer Look at the Data Path Per-flow State … flow 1 flow 2 Scheduler Classifier flow n Buffer management
Resource reservation call setup, signaling (RSVP) traffic, QoS declaration per-element admission control • QoS-sensitive scheduling (e.g., WFQ) Intserv: QoS Guarantee Scenario request/ reply
A flow needs performance guarantee must : declare its QoS requirement R-spec:defines the QoS being requested characterize traffic it will send into network T-spec:defines traffic characteristics signaling protocol: needed to carry R-spec and T-spec to routers (where reservation is required) RSVP RSVP Protocol
Senderperiodically sends PATH messages to receiver R, each router updates the PATH message by increasing hop count and adding its propagation delay When receiver R gets the PATH message, it knows Traffic characteristics (tspec): (r,b,R) Number of hops, propagation delay introduced by the routers Receiver R sends back this information + required worst-case delay in RESV Each router along path provides a per-hop delay guarantee and forwards RESV with updated info In the simplest case, the routers can just split the delay State timed out if not refreshed (b,r,R,1,d1) (b,r,R,3,d1+d2+d3) (b,r,R,2,d1+d2) (b,r,R,0,0) (b,r,R,2,D-D3) (b,r,R,3,D) (b,r,R,1,D-D3-D2) (b,r,R,0,0) delay budget RSVP: Soft-state Receiver-initiatedEnd-to-End Reservation R R2 S R1 R3 RESV PATH
Use WFQ to implement controlled link sharing among different organizations WFQ provides guaranteed service Controlled-load and best-effort flows are separated by priority Implementing IntServ WFQ CS department gets 50% WFQ 30% 10% priority guaranteed flow n guaranteed flow 1 best effort flows controlled flows
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) Don’t define service classes, provide functional components to build service classes IETF Differentiated Services
The DiffServ Traffic Conditioner Block (TCB) • Classifier:Identifies packets for assignment to Classes • Meter:Checks compliance to traffic parameters (Token Bucket) and passes result to Marker and Shaper/Dropper to trigger particular action for in/out-of-profile packets • Marker:Writes/rewrites the DSCP value • Shaper:Delays some packets for them to be compliant with the profile • Dropper:Drops packets that exceed the profile (Bc or Be)
marking r b scheduling . . . DiffServ Architecture Edge router: - per-flowtraffic management - marks packets asin-profile andout-profile Core router: - per classtraffic management - buffering and scheduling based onmarking at edge - preference given toin-profile packets - Assured Forwarding
Rate A B Edge-router Packet Marking • profile:pre-negotiated rate A, bucket size B • packet marking at edge based onper-flowprofile User packets Possible usage of marking: • class-based marking: packets of different classes marked differently • intra-class marking: conforming portion of flow marked differently than non-conforming one
Packet is marked in the Type of Service (TOS) in IPv4, and Traffic Class in IPv6 6 bits used for Differentiated Service Code Point (DSCP) and determine PHB that the packet will receive 2 bits are currently unused Classification and Conditioning
may be desirable to limit traffic injection rate of some class: user declares traffic profile (eg, rate, burst size) traffic metered, shaped if non-conforming Classification and Conditioning
PHB result in a different observable (measurable) forwarding performance behavior PHB does not specify what mechanisms to use to ensure required PHB 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 Forwarding (PHB)
PHBs being developed: Expedited Forwarding:pkt departure rate of a class equals or exceeds specified rate logical link with a minimum guaranteed rate Assured Forwarding:4 classes of traffic each guaranteed minimum amount of bandwidth each with three drop preference partitions Forwarding (PHB)
100Mbps 2Mbps WAN 1000Mbps 100Mbps Direction of Data-Flow Why QoS?Congestion Scenario #1—Speed Mismatch • The #1 Reason for Congestion! • Possibly Persistent when going from LAN to WAN • Usually Transient when going from LAN to LAN!
HQ Hubi 2Mbps 512Kbps FR/ATM N*56Kbps Choke Points Remote S1 S2 1000Mbps 1000Mbps Choke Point Direction of Data-Flow Why QoS?Congestion Scenario #2—Aggregation • Transient Congestion fairly typical!
Why QoS?? Congestion Scenario #3—Confluence Net-1 Core1 Core2 Net-2 STM-64/OC-192c STM-16/OC-48c • Always need mechanisms to provide guarantees! • Transient Congestion occurs! Net-n
Typical ApplicationQoS Requirements ERP andMission-Critical Voice FTP Low toModerate Moderateto High Bandwidth Low ModerateTo High Random Drop Sensitive Low High Low toModerate Delay Sensitive High Low Jitter Sensitive High Low Moderate
Q & A Thank You