1. Chapter 6 outline r 6.1 Multimedia Networking Applications r 6.2 Streaming stored audio and video m RTSP r 6.3 Real-time, Interactive Multimedia: Internet Phone Case Study r 6.4 Protocols for Real- Time Interactive Applications m RTP,RTCP m SIP r 6.5 Beyond Best Effort r 6.6 Scheduling and Policing Mechanisms r 6.7 Integrated Services r 6.8 RSVP r 6.9 Differentiated Services

2. Last two lectures r Principles for QoS r Leaky bucket + WFQ m Guaranteed QoS (bounded delay) r How to realize them in the Internet architecture?

3. IETF Integrated Services Architecture for providing QoS guarantees in IP networks for individual application sessions r Resource reservation: routers maintain state info (like a VC) of allocated resources, QoS req’s r Admit/deny new call setup requests Question: can newly arriving flow be admitted with performance guarantees while not violated QoS guarantees made to already admitted flows?

4. IntServ scenario r Resource reservation m traffic, QoS declaration m call setup, signaling (RSVP) m per-element admission control m QoS-sensitive scheduling (e.g., WFQ) request/ reply

5. Traffic characterization and QoS spec. In order to know if a router has sufficient resources, an arriving session must: m declare its QoS requirement R-spec: defines the QoS being requested m characterize traffic it will send into network T-spec: defines traffic characteristics Specific form of R-spec and T-spec depends on the requested service.

6. Signaling for call setup r R-spec and T-spec are sent to routers (where reservation is required) m RSVP protocol does signaling, later m RFC 2210

7. Pre-element call admission r Router determines whether it can support the new session. Depends on: m T-spec m R-spec m Existing resource commitments made to other sessions. WFQ (1) T-spec R-spec (2) (3) Reply: whether request Can be satisfied RSVP signaling setup

8. Intserv QoS: Two service models Guaranteed service: [rfc2211] r worst case traffic arrival: leaky- bucket-policed source r simple (mathematically provable) bound on delay [Parekh 1992, Cruz 1988] Controlled load service: [rfc 2212] r "a quality of service closely approximating the QoS that same flow would receive from an unloaded network element.“ r No guarantee, but with high probability the packets will go through a router without excessive delay. WFQ token rate, r bucket size, b per-flow rate, R D = b/R max arriving traffic

9. RSVP: signaling protocol to make reservation r RSVP is present in both end-hosts and routers m Host, on behave of a flow, sends requests m Routers forward requests r Implementation features: m Multicast-oriented m Receiver-oriented r RSVP belongs to which layer? Does it follow the principle of end-to-end augment? m Application layer, or m Transport layer, or m Network layer

10. RSVP is not… r a protocol to provide bandwidth m Routers decide bandwidth allocation (possibly no bandwidth) r a routing protocol m The RSVP daemon consults the local routing protocol(s) to obtain routes. RSVP is designed to operate with existing and future unicast and multicast routing protocols. A host sends IGMP messages to join a multicast group, but it uses RSVP messages to reserve resources along the delivery path(s) from that group.

11. RSVP functionalities r RSVP handles heterogeneous receivers. m Different hosts on the same multicast delivery tree may have different capabilities and therefore need different QoS. r RSVP adapts to changing group membership as well as changing routes. m For dynamic adaptability and robustness, RSVP maintains “soft state” in the routers. The only permanent state is in the end systems, which periodically send their RSVP control messages to refresh the router state. In the absence of refresh, RSVP state in routers will time out and be deleted.

12. RSVP messages r Path messages: RSVP sender host sends a Path message downstream. These store the ‘path state’ in each node along the way. This path state includes the IP address of the previous hop node which is used to route the Resv message in the reverse direction. m Distribute traffic source information m Collect path information m Install necessary state

13. RSVP messages r Resv message: Each receiver host sends a Resv message upstream towards the senders. These messages must follow the exact reverse path the data will use. They create and maintain the reservation state in each node along the path. m Follow the reserved path of PATH messages m Specify the resource requirements m Setup state in the path

14. Last words: scalability and Diffserv Access Backbone Diffserv region Per flow policing and marking Per-class scheduling RSVP signaling Trust Boundary