1 / 24

EE 122: Quality of Service and Resource Allocation

EE 122: Quality of Service and Resource Allocation. Ion Stoica November 6, 2002. Limitations of IP Architecture in Supporting Resource Management. IP provides only best effort service IP does not participate in resource management Cannot provide service guarantees on a per flow basis

raymondkelly
Download Presentation

EE 122: Quality of Service and Resource Allocation

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. EE 122: Quality of Service and Resource Allocation Ion Stoica November 6, 2002

  2. Limitations of IP Architecture in Supporting Resource Management • IP provides only best effort service • IP does not participate in resource management • Cannot provide service guarantees on a per flow basis • Cannot provide service differentiation among traffic aggregates • Early efforts • Tenet group at Berkeley (Ferrari and Verma) • Asynchronous Transfer Mode (ATM) • IETF (Internet Engineering Task Force) efforts • Integrated services initiative • Differentiated services initiative istoica@cs.berkeley.edu

  3. Service Classes • Multiple service classes • Service can be viewed as a contract between network and communication client • End-to-end service (multicast and anycast) • Other service scopes possible, e.g., • Aggregates – all packets between to points (not necessary end-hosts) in the Internet • Three common services • Best-effort (“elastic” applications) • Hard real-time (“real-time” applications) • Soft real-time (“tolerant” applications) istoica@cs.berkeley.edu

  4. Example: Integrated Services • Enhance IP’s service model • Old model: single best-effort service class • New model: multiple service classes, including best-effort and QoS classes • Create protocols and algorithms to support new service models • Old model: no resource management at IP level • New model: explicit resource management at IP level • Key architecture difference • Old model: stateless • New model: per flow state maintained at routers • Used for admission control and scheduling • Set up by signaling protocol istoica@cs.berkeley.edu

  5. QoS Network • Flow or session as QoS abstractions • Each flow has a fixed or stable path • Routers along the path maintain the state of the flow istoica@cs.berkeley.edu

  6. QoS Network Operations • Control plane: admission control • Reserve resources (i.e., link capacity and buffer space) at every router along the path • Data plane: perform per flow • Classification: classify each packet to the flow it belongs to • Buffer management: decide when and which packet to drop • Packet scheduling: decide when and which packet to send istoica@cs.berkeley.edu

  7. Control Plane: Admission Control • Example: achieve per-flow bandwidth and delay guarantees • Example: guarantee 1MBps and < 100 ms delay to a flow Receiver Sender istoica@cs.berkeley.edu

  8. Control Plane: Admission Control • Allocate resources - perform per-flow admission control Receiver Sender istoica@cs.berkeley.edu

  9. Control Plane: Admission Control • Install per-flow state Receiver Sender istoica@cs.berkeley.edu

  10. Control Plane: Admission Control • Install per flow state Receiver Sender istoica@cs.berkeley.edu

  11. Data Plane • Per-flow classification Receiver Sender istoica@cs.berkeley.edu

  12. Data Plane • Per-flow buffer management Receiver Sender istoica@cs.berkeley.edu

  13. Data Plane • Per-flow scheduling Receiver Sender istoica@cs.berkeley.edu

  14. Service Classes • Multiple service classes • Service can be viewed as a contract between network and communication client • End-to-end service • Other service scopes possible • Three common services • Best-effort (“elastic” applications) • Hard real-time (“real-time” applications) • Soft real-time (“tolerant” applications) istoica@cs.berkeley.edu

  15. Service Specification • Loss: probability that a flow’s packet is lost • Delay: time it takes a packet’s flow to get from source to destination • Delay jitter: maximum difference between the delays experienced by two packets of the flow • Bandwidth: maximum rate at which the soource can send traffic istoica@cs.berkeley.edu

  16. Hard Real Time: Guaranteed Services • 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 istoica@cs.berkeley.edu

  17. Soft Real Time: Controlled Load Service • Service contract: • Network to client: similar performance as an unloaded best-effort network • 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 istoica@cs.berkeley.edu

  18. Traffic and Service Characterization • To quantify a service one has two know • Flow’s traffic arrival • Service provided by the router, i.e., resources reserved at each router • Examples: • Traffic characterization: token bucket • Service provided by router: fix rate and fix buffer space istoica@cs.berkeley.edu

  19. Token Bucket • Characterized by three parameters (b, r, R) • b – token depth • r – average arrival rate • R – maximum arrival rate (e.g., R link capacity) • A bit is transmitted only when there is an available token • When a bit is transmitted exactly one token is consumed r tokens per second bits slope r b*R/(R-r) b tokens slope R <= R bps time istoica@cs.berkeley.edu regulator

  20. Characterizing a Source by Token Bucket • Arrival curve – maximum amount of bits transmitted by time t • Use token bucket to bound the arrival curve bps bits Arrival curve time time istoica@cs.berkeley.edu

  21. (b=1,r=1,R=2) Example • Arrival curve – maximum amount of bits transmitted by time t • Use token bucket to bound the arrival curve Arrival curve bits 4 bps 3 2 2 1 1 0 1 2 3 4 5 1 2 3 4 5 time size of time interval istoica@cs.berkeley.edu

  22. d Per-hop Reservation • Given b,r,R and per-hop delay d • Allocate bandwidth ra and buffer space Ba such that to guarantee d slope ra slope r bits Arrival curve b Ba istoica@cs.berkeley.edu

  23. num hops (b,r,R,3) (b,r,R,3,D) worst-case delay End-to-End Reservation • Source S sends a message containing traffic characteristics • r,b,R • This message is used to computes the number of hops • Receiver R sends back this information + worst-case delay (D) • Each router along path provide a per-hop delay guarantee and forwards the message • In simplest case routers split the delay D S2 R (b,r,R) S (b,r,R,2,D-d1) S1 S3 (b,r,R,1,D-d1-d2) (b,r,R,0,0) istoica@cs.berkeley.edu

  24. Summary • Service: a contract between end-hosts and network • QoS goal: provide better than best-effort services to support new applications with more stringent delay and bandwidth requirements, e.g., IP telephony, videoconferencing • QoS requires to manage flows/aggregates both on data and control plane • Two major proposals: • Integrated Services • Differentiated Services istoica@cs.berkeley.edu

More Related