1. 1 Chapter 6 Multimedia Networking Computer Networking: A Top Down Approach Featuring the Internet, 2 nd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2002. A note on the use of these ppt slides: We’re making these slides freely available to all (faculty, students, readers). They’re in powerpoint form so you can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following:  If you use these slides (e.g., in a class) in substantially unaltered form, that you mention their source (after all, we’d like people to use our book!)  If you post any slides in substantially unaltered form on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material. Thanks and enjoy! JFK / KWR Modified by Lindsay Wishnick, Sarah Biggs, and Marga Koburger All material copyright 1996-2002 J.F Kurose and K.W. Ross, All Rights Reserved

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

3. 3 IETF Integrated Services (Intserv) Specific architecture for providing QoS guarantees in the internet for individual application sessions Two key features: Resource reservation: routers maintain state info (a la Virtual Circuit) of allocated resources, QoS requirements Call Setup: Admit/deny new call setup requests

4. 4 Call Admission (Call Setup) Router must determine whether or not its resources are sufficient to meet the QoS requirements. 3 Step Process: 1.Arriving session must determine its needs 2.Arriving session signals for call setup 3.Router decides whether to admit the arriving session (Per-element admission)

5. 5 Call Setup: Step 1 Arriving session must determine its needs Declare its QoS requirement RSpec: defines the QoS being requested Characterize traffic it will send into network TSpec: defines traffic characteristics Rspec and Tspec are defined in RFCs 2210 and 2215

6. 6 Call Setup: Step 2 Arriving session signals for call setup Signaling protocol: needed to carry RSpec and TSpec to routers (where reservation is required) RSVP (RFC 2210) is currently the protocol of choice for the Internet

7. 7 Call Setup: Step 3 Question: Can newly arriving flow be admitted with performance guarantees while not violating QoS guarantees made to already admitted flows? Answer: The router calculates the local resources required by the session and considers the amount of resources it has already devoted to other sessions. The router only accepts the new session if it can still guarantee QoS for all sessions. This is Step 3!

8. 8

9. 9 Intserv: Call Setup Process request/ reply

10. 10 Setup Requests Request: Specifies traffic and QoS needs Router considers required resources and unreserved resources Reply: Whether the router can satisfy the request QoS call signal

11. 11 Intserv Service Classes Guaranteed service: Deals with worst case traffic arrival: leaky-bucket-policed source There is a simple (mathematically provable) bound on delay! [Parekh 1992, Cruz 1988] RFC 2212 Controlled-Load Network Service: "a quality of service closely approximating the QoS that same flow would receive from an unloaded network element.“ – RFC 2211 targets real-time multimedia applications that do not perform well when a network is loaded with traffic

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

13. 13 RSVP (Resource reSerVation Protocol) RSVP is a hop-by-hop signaling protocol that allows applications to reserve resources in the internet so they can receive the amount of bandwidth they need Implemented inside IP messages Supports quality of service requirements In this context “resources” refers to link bandwidth RFC 2205

14. 14 Applying RSVP Hosts use RSVP to request a specific amount of bandwidth from the network on the behalf of an application data flow Routers use RSVP to forward bandwidth reservation requests RSVP provides reservations in multicast trees RSVP is receiver-oriented: the receiver of a data flow initiates and maintains the resource reservation used for that flow Being oriented towards the receiver allows reservations from receivers with very different characteristics

15. 15 RSVP Characteristics Multicast Receiver-oriented: data originates from the sender, but reservation messages come from the receivers Data Flow Merged reservations Reservation message

16. 16 Multiple Multicasts in RSVP A session can consist of multiple multicast data flows Each sender in a session is the source of one or more data flows (for example a video data flow and an audio data flow) We assume routers and hosts identify the session to which a packet belongs by the packet’s multicast address The data flow to which a packet belongs must be identified (i.e. through an identifier field like IPv6)

17. 17 What RSVP is Not RSVP standard does not specify how networks provide reserved bandwidth for data flows only a protocol for letting applications reserve link bandwidth routers in the internet actually provide the reserved bandwidth for the data flows: usually through scheduling mechanisms from 6.6 RSVP is not a routing protocol: it does not determine the links where reservations are made underlying routing protocol determines the routes for the flows once the routes are in place, RSVP can reserve bandwidth along the route

18. 18 Heterogeneous Receivers Question: Consider a network in which some receivers can receive a flow at 28.8 Kbps and others at 128 Kbps. If a sender is multicasting a video to a to a group of such heterogeneous receivers, should the sender encode the video for low (28.8 Kbps) or high (128 Kbps) quality? Answer: Video and audio are encoded in layers. For example, a video could be encoded into a base layer at 20 Kbps and an enhancement layer at 100 Kbps. This way receivers with 28.8 Kbps access rates can receive the low-quality base-layer image and 128 Kbps receivers can receive both layers to construct a high-quality image.

19. 19 Heterogeneous Receivers The sender does not need to know the receiving rates of the receivers – only the maximum rate of all the receivers The sender encodes the data in multiple layers and sends all layers up to the maximum rate into the multicast tree The receivers pick the layers that are appropriate for their receiving rates Receivers communicate to the network the rates they can handle to keep from wasting bandwidth RSVP gives foremost attention to the issue of reserving resources for heterogeneous receivers

20. 20 RSVP in Action!

21. 21 More Action!

22. 22 Reserving Bandwidth The amount of bandwidth reserved by a router on a link should not exceed the link’s capacity When a router receives a reservation message, it first checks whether the upstream links have extra bandwidth If the admission test fails, the router returns an error message RSVP does not define an admission test, but it assumes the router is performing them When the reservation message reaches the sender successfully, a confirmation message is sent to the receiver so it knows that the request is successful

23. 23 Maintaining Reservations Reservations maintained with soft states in routers Each reservation is associated with a timer When the timer expires, the reservation is removed The receiver must periodically refresh the reservation by sending reservation messages No need to break down or clean up link Can explicitly tear down state if wish Adapts easily to route and tree changes

24. 24 Implementing RSVP RSVP can be implemented with other quality of service protocols (e.g. differentiated service) Implemented with differentiated service, differentiated service would mark and prioritize traffic while RSVP secures the resources needed to transmit the traffic RSVP impairs performance on backbone routers too complex other protocols used on network backbone http://www.networkmagazine.com/article/NMG20010720 S0009

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

26. 26 IETF Differentiated Services Difficulties associated with Intserv: Scalability: Using RSVP, need to process resource reservations and maintain per-flow state for each flow going through the router At a backbone router, this can incur potentially significant overhead in large networks Flexible Service Models: Intserv provides for a small number of service classes Service classes do not allow more qualitative or relative definitions of service distinctions Relative service distinction: Platinum, Gold, Silver

27. 27 IETF Differentiated Services Diffserv approach: Scalability: simple functions placed in network core, with relatively complex functions at “edge” routers (or hosts) Flexibility: Does not define specific services or service classes, instead provides functional components with which service classes can be built

28. 28 Diffserv Architecture Edge router: - per-flow traffic management - marks packets as in-profile and out-profile Core router: - per class traffic management - buffering and scheduling based on marking at edge - preference given to in-profile packets - Assured Forwarding scheduling... r b marking

29. 29 Edge-router Packet Marking Possible usage of marking: Class-based marking: packets of different classes marked differently Intra-class marking: conforming portion of flow marked differently than non-conforming one Profile: pre-negotiated rate A, bucket size B Packet marking at edge based on per-flow profile User packets Rate A B

30. 30 Distinguishing Packets Question: A differentiated services router distinguishes between packet flows by using the packets’ A: markings B: source IP address C: source IP address and markings D: none of the above Answer: A: markings

31. 31 Classification and Conditioning Packet’s mark is in the DS field in the IPv4 or IPv6 packet header 6 bits used for Differentiated Service Code Point (DSCP), determines per-hop behavior (PHB) that the packet will receive 2 bits are currently unused

32. 32 Traffic Classification and Conditioning Packets that arrive at the edge of the network are “classified” Classifier selects packets based on values in packet header fields Examples: source address, destination address, source port, destination port, protocol ID Packet then sent through appropriate marking function DS field is set according to the marker Packets then forwarded to destination

33. 33 Classifying Packets Question: In a differentiated services architecture, packets can be classified according to their A: Protocol identifiers B: Source and destination port numbers C: Source and destination IP address D: All of the above Answer: D: All of the above

34. 34 Traffic Classification and Conditioning (more) Sometimes, may be desirable to limit traffic injection rate of some class: user declares traffic profile, in which limits are set for peak rate and “burstiness” Incoming packet flow compared with negotiated profile, packet shaped/dropped if non-conforming

35. 35 Forwarding (Per-Hop Behaviors) Defined as “a description of the externally observable forwarding behavior of a Diffserv node applied to a particular Diffserv behavior aggregate” Can result in different classes of traffic receiving different performances (different observable behaviors) Does not specify what mechanisms to use to ensure 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

36. 36 Per-Hop Behavior Question: While a per-hop behavior defines differences in performance among classes, it does not mandate any particular mechanism for achieving these performances, True or False Answer: True

37. 37 Forwarding (Per-Hop Behaviors) Per-Hop Behaviors currently being developed: Expedited Forwarding: Packet departure rate of a class must equal or exceed a configured rate Provides a class with a minimum guaranteed rate Assured Forwarding: Creates 4 classes of traffic Each class is guaranteed a minimum amount of bandwidth Each class is subdivided into three drop preference partitions, so packets will be dropped based on their drop preference values

38. 38 How has QoS been implemented? ATM Very complicated Signaling and TSPEC TSPEC didn’t make much sense to application developers ATM “to the desktop” never took off IETF: Integrated Services Group (Intserv) Per flow guarantees, Token Buckets, RSVP, Scheduling Very expensive to implement – doesn’t scale well IETF: Differentiated Services Group (Diffsrv) No resource reservation protocol Coarse-grain guarantees Very scalable Of limited use