ALF and RTP

1. ALF and RTP Ketan Mayer-Patel CS294-9 :: Fall 2003

2. RTP Overview • Multiparty multimedia conferencing applications. • Applicable to most continuous media types. • Thin protocol • As is, doesn’t specify everything you need. • Serves as a skeleton that can be filled out. • Provides a handle on a few basic dimensions of a CM stream. • Allows functionality without full knowledge. CS294-9 :: Fall 2003

3. Application Level Framing • THE primary design principle behind RTP. • Clark and Tennenhouse, 1990 • Data should be organized into units that make the most sense for the application. • What makes sense for a video application? • What makes sense for a stock ticker? • What makes sense for an audio application? CS294-9 :: Fall 2003

4. ALF cont’d • Application Data Unit (ADU) • Interface to the network and the service model of protocols should be in terms of ADU’s. • Ex: TCP • What does it provide now? • What should it provide instead? CS294-9 :: Fall 2003

5. FLA (ALF run backwards) • Why don’t network mechanisms work in terms of ADU’s? • What can we do instead? • Let the applications construct ADU’s that fit the underlying network mechanism. • RTP provides a framework for doing this for continuous media streams. • Most common case: fitting the MTU CS294-9 :: Fall 2003

6. RTP Session Architecture • Multiple participants. • Possibly using multicast. • Multiple streams per participant. • Dynamic membership. • Participants come and go. • No assumption of central control. • Participants may not know about each other. CS294-9 :: Fall 2003

7. V=2 P X CC M PT Sequence Number RTP Packet Format Timestamp Synchronization Source (SSRC) Identifier Contributing Source (CSRC) Identifier Contributing Source (CSRC) Identifier Data CS294-9 :: Fall 2003

8. RTP and the Network Stack • Network protocols are layered. • What does RTP require from the layers underneath it? • Best effort delivery. • Length of packet. • Multiplexing among data types • What provides this? • UDP CS294-9 :: Fall 2003

9. SSRC • Identifies the stream. • Not just the participant. • All packets with the same SSRC go together. • Picked at random. • Why do we need this? • No assumption of stream association from underlying network mechanism. • Possible problems? • Collision CS294-9 :: Fall 2003

10. Timestamp vs. Sequence No. • Timestamp relates packet to real time. • Timestamp values sampled from a media specific clock. • Sequence number relates packet to other packets. • Allows many packets to have the same timestamp but different sequence numbers. CS294-9 :: Fall 2003

11. MPEG example • How does the timestamp/seq. no mechanism support MPEG? • Out of order transmission. • Sequence numbers increase monotonically. • Timestamps reflect reference relationships. • Large frames. • Natural ADU = frame. But that won’t work. • One video frame likely to be split into parts and packed into multiple RTP packets. • Timestamps associate packets together as part of the same frame, while seq. no distinguish packets from each other. CS294-9 :: Fall 2003

12. Audio silence example • Consider audio data type. • What do you want to do during silence? • Not send anything. • Why might this cause problems? • Other side needs to distinguish between loss and silence. • How does the timestamp/seq. no mechanism help? • After receiving no packets for a while, next packet received will reflect a big jump in timestamp, but have the correct next seq. no. Thus, receiver knows what happened. CS294-9 :: Fall 2003

13. RTP Profiles • Associated with a media type. • Provides association between PT field and specific media format. • Defines sampling rate of timestamp. • May also define or recommend a definition for the “marker” bit. CS294-9 :: Fall 2003

14. Video Profile • Marker bit recommended to mean last packet associated with a timestamp. • Timestamp clock: 90000 Hz • Defines PT mapping for a number of different video encoding types. CS294-9 :: Fall 2003

15. Audio Profile • Marker bit set on the first packet after a silence period where no packets sent. • Timestamp equals sampling rate. • Recommends 20ms minimum frame time. • Recommends that samples from multiple channels be sent together. • Defines PT for a number of different audio encoding types. CS294-9 :: Fall 2003

16. RTP Payloads • Value of PT field given a particular profile identifies a payload type. • Each payload type associated with format specific definition for the rest of the packet. • Typically: • Format specific header. • Data CS294-9 :: Fall 2003

17. Payload Design Goals • Overall goal is to apply ALF principle as much as possible: • Each packet should be as independently processable as possible. • Loss • Out of order • Duplications • Payload definition should allow the application to fit RTP packets to the MTU. CS294-9 :: Fall 2003

18. RTP and Continuous Media • Periodic • Timestamp/Seq. no mechanism. • Robust • Media specific payload definitions that attempt to define packet-sized ADU’s. • Often large • Marker bit, timestamp/seq. no • Correlated • No real support. CS294-9 :: Fall 2003

19. ALF vs. Abstraction • Main message of the ALF paper: • Network should work in terms most congruent with what the application is trying to do. • Main obstacle to ALF: • Design of network mechanisms wants to hide details and provide general-purpose API’s. • Success of sockets • Abstraction and encapsulation • Tension between ALF and abstraction • What to expose? • How do we expose it? CS294-9 :: Fall 2003