1 / 103

IP Quality of Service

IP Quality of Service. Motivation. Internet currently provides only single class of “best-effort” service. No admission control and no assurances about delivery Existing applications are elastic. Tolerate delays and losses Can adapt to congestion

cybele
Download Presentation

IP Quality of Service

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. IP Quality of Service

  2. Motivation • Internet currently provides only single class of “best-effort” service. • No admission control and no assurances about delivery • Existing applications are elastic. • Tolerate delays and losses • Can adapt to congestion • Future “real-time” applications may be inelastic. • Should we modify these applications to be more adaptive or should we modify the Internet to support inelastic behavior?

  3. Application Types • Elastic applications. • Wide range of acceptable rates, although faster is better • E.g., data transfers such as FTP • Continuous media applications. • Lower and upper limit on acceptable performance • Sometimes called “tolerant real-time” since they can adapt to the performance of the network • E.g., changing frame rate of video stream • “Network-aware” applications • Hard real-time applications. • Require hard limits on performance – “intolerant real-time” • E.g., control applications

  4. QoS Defined • The goal : Provide some level of predictability and control beyond the current IP “best-effort” service • Fundamental principle Leave complexity at the “edges” and keep network “core” simple

  5. QoS Metrics • Performance attributes • Service availability • Delay • Delay variation (jitter) • Throughput • Packet loss rate Vary according to Service Level Agreement (SLA)

  6. Service Level Agreements (SLA)

  7. What is the problem? • Different applications have different delay, bandwidth, and jitter needs • Some applications are very sensitive to changing network conditions: the packet arrival time distribution is important • Solutions • Make applications adaptive • Build more flexibility into network

  8. QoS’s Quest The Holy Grail of computer networking is to design a network that has the flexibility and low cost of the Internet, yet offers the end-to-end quality-of-service guarantees of the telephone network. --S. Keshav

  9. Improving QOS in IP Networks • IETF groups are working on proposals to provide better QOS control in IP networks, i.e., going beyond best effort to provide some assurance for QOS. • Work includes RSVP, Differentiated Services, and Integrated Services.

  10. Overview • Principles for QoS • Integrated Services (Intserv) • Differentiated Services (Diffserv)

  11. Principles for QOS Guarantees • Simple model for sharing and congestion studies (“dumbell topology”):

  12. Principles for QOS Guarantees (more) • Consider a phone application at 1Mbps and an FTP application sharing a 1.5 Mbps link. • Bursts of FTP can congest the router and cause audio packets to be dropped. • Want to give priority to audio over FTP. • PRINCIPLE 1: Marking of packets is needed for router to distinguish between different classes; and new router policy to treat packets accordingly.

  13. Principles for QOS Guarantees (more) • Applications misbehave (audio sends packets at a rate higher than 1Mbps assumed above). • PRINCIPLE 2: provide protection (isolation) for one class from other classes. • Require Policing Mechanisms to ensure sources adhere to bandwidth requirements; Marking and Policing need to be done at the edges:

  14. Principles for QOS Guarantees (more) • Alternative to Marking and Policing: allocate a set portion of bandwidth to each application flow; can lead to inefficient use of bandwidth if one of the flows does not use its allocation. • PRINCIPLE 3: While providing isolation, it is desirable to use resources as efficiently as possible.

  15. Principles for QOS Guarantees (more) • Cannot support traffic beyond link capacity. • PRINCIPLE 4: Need a Call Admission Process; application flow declares its needs, network may block call if it cannot satisfy the needs .

  16. Summary

  17. Overview • Motivation for QoS • Integrated Services (Intserv) • Differentiated Services (Diffserv)

  18. IETF Intserv • Focus on per-flow QoS. • Support specific applications such as video streaming. • What is a flow? • Equivalent packets by some classification • RSVP: Set of packets traversing a network element that are all covered by the same QoS request • Packet classifier determines which packets belong to which flows • IPv6 includes a flow label to ease classification • ISP usage (UUNET) • Microflow: TCP or similar bandwidth connection • Macroflow: Large aggregates of packets flowing between two superhubs

  19. Because the Intserv model provides per-flow reservations, each flow is assigned a flow descriptor. • The flow descriptor defines the traffic and QoS characteristics for a specific flow of data packets. • The flow descriptor consists of a filter specification (filterspec) and a flow specification (flowspec)

  20. The filterspec identifies the packets that belong to a specific flow with the sender IP address and source port. • The information from the filterspec is used in the packet classifier • Simplest filter: Source, Dest address/port pair • Data filter: classifies packets according to contents • The flowspec contains a set of parameters that are called the invocation information. • The invocation information divides into two groups: • Traffic Specification (Tspec) • Service Request Specification (Rspec)

  21. Components of Integrated Services • Type of service model • What does the network promise? • Service interface • How does the application describe what it wants? • Packet scheduling • How does the network meet promises? • Establishing the guarantee • How is the promise communicated to/from the network? • How is admission of new applications controlled?

  22. Service Models • Network can support traffic streams with different “quality of service”. • Best effort • Predictive or differentiated services • Strong guarantees on the level of service (real-time) • Service: contract between network and communication client • Three common services • Best-effort (“elastic” applications) • Hard real-time (“real-time” applications) • Soft real-time (“tolerant” applications)

  23. Worse-case : Guaranteed Services • Guaranteed service • Targets hard real-time applications. • User specifies traffic characteristics and a service requirement. • Requires admission control at each of the routers. • Can guarantee bandwidth, delay, and jitter. • Service contract • Network to client: guarantee a deterministic upper bound on delay for each packet in a session • Client to network: the session does not send more than it specifies • Algorithm support • Admission control based on worst-case analysis • Per flow classification/scheduling at routers

  24. Average-case: Controlled Load Service • Targets applications that can adapt to network conditions within a certain performance window. • User specifies traffic characteristics and bandwidth. • Requires admission control at each of the routers. • Guarantee not as strong as with the guaranteed service. • e.g., measurement-based admission control. • Service contract: • Network to client: Average delay, jitter, bandwidth, e.g., makes network appear as an unloaded, best effort network with bandwidth and delay • Client to network: the session does not send more than it specifies • Algorithm Support • Admission control based on measurement of aggregates • Scheduling for aggregate possible

  25. Service Interface • Session must first declare its QoS requirement and characterize the traffic it will send through the network • R-spec: defines the QoS being requested by receiver (e.g., rate r) • T-spec: defines the traffic characteristics of sender (e.g., leaky bucket with rate r and buffer size b). • A signaling protocol is needed to carry the R-spec and T-spec to the routers where reservation is required; RSVP is a leading candidate for such signaling protocol.

  26. Once a connection is accepted, the host must use only the amount of resources reserved. It may not use more than that. • What if the host is malicious and attempts to use more network resources than it reserved? • It where Leaky Bucket comes to play

  27. Leaky Bucket • Used in conjunction with resource reservation to police the host’s reservation • At the host-network interface, allow packets into the network at a constant rate • Packets may be generated in a bursty manner, but after they pass through the leaky bucket, they enter the network evenly spaced

  28. Leaky Bucket: Analogy

  29. The leaky bucket is a “traffic shaper”: It changes the characteristics of packet stream • Traffic shaping makes more manageable and more predictable • Usually the network tells the leaky bucket the rate at which it may send packets when the connection begins • Polices the average rate

  30. Leaky Bucket doesn’t allow burstytransmissions • In some cases, we may want to allow short bursts of packets to enter the network without smoothing them out • For this purpose we use a token bucket, which is a modified leaky bucket

  31. Token Bucket • The bucket holds tokens instead of packets • Tokens are generated and placed into the token bucket at a constant rate • When a packet arrives at the token bucket, it is transmitted if there is a token available. Otherwise it is buffered until a token becomes available. • The token bucket has a fixed size, so when it becomes full, subsequently generated tokens are discarded

  32. Token Bucket vs. Leaky Bucket Case 1: Short burst arrivals

  33. Case 2: Large burst arrivals

  34. Flow Specification: Token Bucket • Characterized by two parameters (r, b) • r – average rate • b – token depth • Assume flow arrival rate <= R bps (e.g., R link capacity) • A bit is transmitted only when there is an available token • Arrival curve – maximum amount of bits transmitted by time t

  35. Packet Scheduling • Implemented in hosts/routers to control link allocation • Queuing algorithms • Weighted Fair Queuing (WFQ) • Class Based Queuing (CBQ) • Queue management • Random Early Detection (RED)

  36. Weighted Fair Queuing (WFQ) • Traffic placed into queues according to flow specification, flow filter • Fair queuing • Implements fairness of bit by bit scheduling on a per packet basis • Gives queues a fair share of total bandwidth • Weighted • Queue are not weighted evenly for scheduling • Proven: adequate for Guaranteed Service

  37. Class Based Queuing (CBQ) • Combines scheduling and link sharing • Hierarchical link sharing • Hierarchical queues • Enables protocol, organization isolation • Scheduling • Does not define a particular scheduling algorithm • General scheduler for low latency when no congestion • Link-sharing policing scheduler when congested • Scheduling per hierarchy

  38. CBQ Example

  39. Random Early Detection (RED) • Queue management algorithm for congestion control • This is a proactive approach in which the router discards one or more packets before the buffer becomes completely full. • Each time a packet arrives, the RED algorithm computes the average queue length, avg. • If avg is lower than some lower threshold, congestion is assumed to be minimal or non-existent and the packet is queued

  40. If avg is greater than some upper threshold, congestion is assumed to be serious and the packet is discarded. • If avg is between the two thresholds, this might indicate the onset of congestion. The probability of congestion is then calculated.

  41. Call Admission • Call Admission: routers will admit calls based on their R-spec and T-spec and base on the current resource allocated at the routers to other calls.

  42. The Integrated Service model • Integrated Services use the Resource Reservation Protocol (RSVP) for the signallingof the reservation messages

  43. Resource Reservation Model • Senders advertise using flowspecs • RSVP daemons forward advertisements to receivers, update available bandwidth, minimum delay • Receivers reservations use flowspec, filterspec combination (flow descriptor) • Sender/receiver notified of changes • Reservations are merged in multicast case

  44. RSVP

  45. Role of RSVP • Signaling protocol for establishing per flow state • Carry resource requests from hosts to routers • Collect needed information from routers to hosts • At each hop • Consult admission control and policy module • Set up admission state or informs the requester of failure

  46. Integrated Services Example: Data Path • Per-flow classification Receiver Sender 47

  47. Integrated Services Example: Data Path • Per-flow buffer management Receiver Sender 48

  48. Integrated Services Example • Per-flow scheduling Receiver Sender 49

  49. How Things Fit Together

More Related