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

CS294-9 :: Fall 2003 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 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 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 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 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 RTP Packet Format V=2PXCCMPTSequence Number Timestamp Synchronization Source (SSRC) Identifier Contributing Source (CSRC) Identifier Data

CS294-9 :: Fall 2003 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 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 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 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 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 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 Video Profile Marker bit recommended to mean last packet associated with a timestamp. Timestamp clock: Hz Defines PT mapping for a number of different video encoding types.

CS294-9 :: Fall 2003 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 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 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 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 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?