1. EE 122: Lecture 15 (Quality of Service) Ion Stoica October 25, 2001

2. istoica@cs.berkeley.edu2 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

3. istoica@cs.berkeley.edu3 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)

4. istoica@cs.berkeley.edu4 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

5. istoica@cs.berkeley.edu5 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

6. istoica@cs.berkeley.edu6 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

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

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

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

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

11. istoica@cs.berkeley.edu11 Data Plane Sender Receiver  Per-flow classification

12. istoica@cs.berkeley.edu12 Data Plane Sender Receiver  Per-flow buffer management

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

14. istoica@cs.berkeley.edu14 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)

15. istoica@cs.berkeley.edu15 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

16. istoica@cs.berkeley.edu16 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

17. istoica@cs.berkeley.edu17 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

18. istoica@cs.berkeley.edu18 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

19. istoica@cs.berkeley.edu19 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 b tokens <= R bps regulator time bits b*R/(R-r) slope R slope r

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

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

22. istoica@cs.berkeley.edu22 Per-hop Reservation  Given b,r,R and per-hop delay d  Allocate bandwidth r a and buffer space B a such that to guarantee d bits b slope r Arrival curve d BaBa slope r a

23. istoica@cs.berkeley.edu23 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 S1 S2 S3 S S R R (b,r,R) (b,r,R,3) num hops (b,r,R,2,D- d 1 ) (b,r,R,1,D- d 1 - d 2 ) (b,r,R,0,0) (b,r,R,3,D) worst-case delay

24. istoica@cs.berkeley.edu24 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 (this is mostly what we did this lecture; we’ll do more next lecture) -Differentiated Services (see next lectures)

25. istoica@cs.berkeley.edu25 Administrative Stuff  2 nd midterm exam: next Tuesday, November 6  Similar to the 1 st midterm exam -Conceptual questions -Problems similar to the ones in homeworks -Close books -All material up to and including IP Multicast (i.e., lecture on October 16)  4 th homework: also handed out next Tuesday  We are trying to have a review session for the 2 nd project one week or so before the deadline; details to be announced