15-441 Computer Networking

1. 15-441 Computer Networking Intserv, Diffserv, RSVP

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. 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 in Progress includes RSVP, Differentiated Services, and Integrated Services.

5. Overview • Principles for QoS • Integrated Services (Intserv) • Differentiated Services (Diffserv) • Resource ReSerVation Protocol (RSVP)

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

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

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

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

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

11. Summary

12. Overview • Motivation for QoS • Integrated Services (Intserv) • Differentiated Services (Diffserv) • Resource ReSerVation Protocol (RSVP)

13. IETF Intserv • Focus on per-flow QoS. • Support specific applications such as video streaming. • Based on mathematical guarantees. • Many concerns: • Complexity • Scalability • Business model • Charging

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

15. 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) • The set of services that is supported on a specific network can be viewed as a service model. • Model that can be used to select a service • E.g., cost versus performance tradeoffs • Network architecture that supports the set of services • Considers interactions between services

16. Service Models • Guaranteed service • Targets hard real-time applications. • User specifies traffic characteristics and a service requirement. • Requires admission control at each of the routers. • Can mathematically guarantee bandwidth, delay, and jitter. • Controlled load. • 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. • Best effort

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

18. Packet scheduling • Guaranteed service • Use token bucket filter to characterize traffic • Described by rate r and bucket depth b • Use WFQ at the routers • Parekh’s bound for worst case queuing delay = b/r

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

20. Overview • Motivation for QoS • Integrated Services (Intserv) • Differentiated Services (Diffserv) • Resource ReSerVation Protocol (RSVP)

21. Differentiated Services • Intended to address the following difficulties with Intserv and RSVP; • Scalability: maintaining states by routers in high speed networks is difficult due to the very large number of flows • Flexible Service Models: Intserv has only two classes, want to provide more qualitative service classes; want to provide ‘relative’ service distinction (Platinum, Gold, Silver, …) • Simpler signaling: (than RSVP) many applications and users may only want to specify a more qualitative notion of service

22. Diffserv - Motivation • Do fine-grained enforcement only at the edge of the network. • Typically slower links at edges • E.g., mail sorting in post office • Label packets with a field. • E.g., a priority stamp • The core of the network uses only the type field for QoS management. • Small number of types with well defined forwarding behavior • Can be handled fast • Example: expedited service versus best effort • Evolution rather than revolution

23. Diffserv - Discussion • Diffserv defines an architecture and a set of forwarding behaviors. • It is up to the service providers to define and implement end-to-end services on top of this architecture. • Offers a more flexible service model; different providers can offer different service. • One of the main motivations for Diffserv is scalability. • Keep the core of the network simple. • Focus of Diffserv is on supporting QoS for flow aggregates. • Although architecture does not preclude more fine-grained guarantees.

24. Edge Router/Host Functions • Classification: marks packets according to classification rules to be specified. • Metering: checks whether the traffic falls within the negotiated profile. • Marking: marks traffic that falls within profile. • Conditioning: delays and then forwards, discards, or remarks other traffic.

25. Classification and Conditioning • 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.

26. Core Functions • Forwarding: according to “Per-Hop-Behavior” or PHB specified for the particular packet class; such PHB is strictly based on class marking (no other header fields can be used to influence PHB). • BIG ADVANTAGE: No state info to be maintained by routers!

27. Forwarding (PHB) • 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.

28. Forwarding (PHB) • Expedited Forwarding (EF): • Guarantees a certain minimum rate for the EF traffic. • Implies isolation: guarantee for the EF traffic should not be influenced by the other traffic classes. • Admitted based on peak rate. • Non-conformant traffic is dropped or shaped. • Possible service: providing a virtual wire.

29. Forwarding (PHB) • Assured Forwarding (AF): • AF defines 4 classes with some bandwidth and buffers allocated to them. • The intent is that it will be used to implement services that differ relative to each other (e.g., gold, silver,…). • Within each class, there are three drop priorities, which affect which packets will get dropped first if there is congestion. • Lots of studies on how these classes and drop priorities interact with TCP flow control. • Non-conformant traffic is remarked.

30. Role of RSVP • Rides on top of unicast/multicast routing protocols. • Must be present at sender(s), receiver(s), and routers. • Carries resource requests all the way through the network. • At each hop consults admission control and sets up reservation. Informs requester if failure.

31. Reservation Protocol: RSVP Upper layer protocols and applications IP service interface IP ICMP IGMP RSVP Link layer service interface Link layer modules

32. RSVP Goals • Used on connectionless networks. • Should not replicate routing functionality. • Should co-exist with route changes. • Support for multicast. • Different receivers have different capabilities and want different QOS. • Changes in group membership should not be expensive. • Reservations should be aggregate – I.e. each receiver in group should not have to reserve. • Should be able to switch allocated resource to different senders. • Limit control overhead. • Modular design – should be generic “signaling” protocol. • Result: • Receiver-oriented • Soft-state

33. Receiver-Initiated Reservation • Receiver initiates reservation by sending a reservation over the sink tree. • Assumes multicast tree has been set up previously. • Also uses receiver-initiated mechanism. • Hooks up with the reserved part of the tree. • How far the request has to travel to the source depends on the level of service requested. • Uses existing routing protocol, but routers have to store the sink tree (reverse path from forwarding path). • Properties: • Scales well: can have parallel independent connect and disconnect actions – single shared resource required. • Supports receiver heterogeneity: reservation specifies receiver requirements and capabilities.

34. Soft State • Routers keep state about reservation. • Periodic messages refresh state. • Non-refreshed state times out automatically. • Alternative: Hard state • No periodic refresh messages. • State is guaranteed to be there. • State is kept till explicit removal. • Why could there be a problem? • Properties of soft state: • Adapts to changes in routes, sources, and receivers. • Recovers from failures • Cleans up state after receivers drop outs • Philosophy: reservation is an optimization.

35. RSVP Service Model • Make reservations for simplex data streams. • Receiver decides whether to make reservation • Control messages in IP datagrams (proto #46). • PATH/RESV messages sent periodically to refresh soft state. • One pass: • Failed requests return error messages - receiver must try again. • No end to end ack for success.

36. Basic Message Types • PATH message • RESV message • CONFIRMATION message • Generated only upon request. • Unicast to receiver when RESV reaches node with established state. • TEARDOWN message • ERROR message (if PATH or RESV fails)

37. PATH Messages • PATH messages carry sender’s T-spec. • Token bucket parameters • Routers note the direction PATH messages arrived and set up reverse path to sender. • Receivers send RESV messages that follow reverse path and setup reservations. • If reservation cannot be made, user gets an error.

38. RESV Messages • RESV messages carry receiver’s R-spec. • Forwarded via reverse path of PATH. • Queuing delay and bandwidth requirements. • Source traffic characteristics (from PATH). • Filter specification • Which transmissions can use the reserved resources? • Reservation style. • Router performs admission control and reserves resources.

39. Router Handling of RESV Messages • If new request rejected, send error message. • If admitted: • Install packet filter into forwarding dbase. • Pass flow parameters to scheduler. • Activate packet policing if needed. • Forward RESV message upstream.

40. RSVP reservations • Reservations from multiple receivers for a single sender are merged together at branching points. • Reservations for multiple senders may be added up: • Video conference • Reservations for multiple senders may not be added up: • Audio conference, not many talk at same time. • Only subset of speakers (filters).

41. Reservation Styles: 3 styles • Wildcard/No filter – does not specify a particular sender for group. • Creates a single reservation shared by flows from all upstream senders belonging to the unicast (multicast) session. • The reservation propagates towards ALL sender hosts and automatically extend to new senders as they appear.

42. Reservation Styles • Fixed filter – sender explicitly specified for a reservation. • Video conference • Creates distinct reservations for data packets from a particular sender, not sharing them with other sender’ packets for the same session. • Dynamic filter / Shared-Explicit– valid senders may be changed over time. • Audio conference • Creates a single reservation shared by selected upstream senders. • Allows a receiver to explicitly specify the set of senders to be included.

43. RSVP Reservation Styles Reservations Sender Selection Shared Distinct Explicit Fixed Filter Shared Explicit Wildcard Filter Wildcard None • Shared reservations (WF and SE) are appropriate for multicast applications in which multiple sources are unlikely to transmit simultaneously (packetized audio for example). • FF style makes separate reservations for each sender, and is appropriate for video applications.

44. A C S1 R1 B D R2 S2, S3 R3 Example • Senders S1, S1, S3 • Receivers R1, R2, R3 • Router interfaces A,B,C,D

45. 4b 4b 4b 3b Wildcard Filter Reservation • R1, R2, and R3 want to reserve 4b, 3b, and 2b, respectively (b is given rate). A C S1 R1 B D R2 S2, S3 R3

46. S1:4bS2:5b S1:4b S2:5bS3:b S1:3bS3:b Fixed Filter Reservation • R1 wants to reserve 4b for S1 and 5b for S2. • R2 wants to reserve 3b for S1 and b for S3. • R3 wants to reserve b for S1. A C S1 R1 B D R2 S2, S3 R3

47. (S1,S2):b S1:3b (S2,S3):3b (S1,S2,S3):3b Dynamic Filter Reservation • R1 wants to reserve b for S1 and S2 (shared). • R2 wants to reserve 3b for S1 and S3 (shared). • R3 wants to reserve 2b for S2. A C S1 R1 B D R2 S2, S3 R3

48. Reservations in action - FF

49. Reservations in action – WF

50. Reservations in action - SE