1 / 37

Agenda

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.

ayla
Download Presentation

Agenda

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Quality of Service & Traffic Engineering (QoS & TE)Khaled MohamedCredit: some of the sides are from Cisco Systems

  2. 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

  3. 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

  4. Principles for QoS Guarantees packet classification:router can distinguish between different classes

  5. prevents applications from misbehaving (e.g., multimedia app. sends higher than declared rate) Principles for QoS Guarantees scheduling and policing: provide protection (isolation)

  6. 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

  7. 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

  8. Summary of QoS Principles

  9. 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

  10. 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

  11. 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

  12. 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

  13. round robin scheduling: multiple classes cyclically scan class queues, serving one from each class (if available) Scheduling Policies: still more

  14. Weighted Fair Queuing: generalized Round Robin each class gets weighted amount of service in each cycle Scheduling Policies: still more .

  15. 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

  16. QOS Type of Services • Integrated services • Differentiated services

  17. 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

  18. 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

  19. 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

  20. A Closer Look at the Data Path Per-flow State … flow 1 flow 2 Scheduler Classifier flow n Buffer management

  21. 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

  22. 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

  23. 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

  24. 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

  25. 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

  26. 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)

  27. 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

  28. 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

  29. 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

  30. 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

  31. 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)

  32. 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)

  33. 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!

  34. 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!

  35. 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

  36. 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

  37. Q & A Thank You

More Related