Transporting Multimedia Data in the Internet

1. Transporting Multimedia Data in the Internet Dr. Dorgham Sisalem Tekelec sisalem@iptel.org

2. IP Based Multimedia Communication • Audio/Video samples are digitized, compressed and sent in IP packets • Compression schemes use limitations of human ears/eyes to reduce bandwidth • Reduce audio bandwidth using silence suppression • Reduce video bandwidth using motion detection • Media data needs to be transported from sender to receiver • Media data differ in their characteristics

3. Media Exchange D/A A/D encoding decoding packetization FCFS Route lookup OS OS

4. Example audio encoding techniques G.711 PCM (non-linear) 4KHz bandwidth 64Kb/s G.722 SB-ADPCM 48/56/64Kb/s 4-8KHz bandwidth G.728 LD-CELP 4KHz bandwidth 16Kb/s G.729 CS-ACELP 4KHz bandwidth 8Kb/s G.723.1 MP-MLQ 5.3/6.3Kb/s 4KHz bandwidth GSM RPE/LTP 4KHz 13Kb/s

5. Example video encoding techniques MPEG1 Up to 1.5Mb/s MPEG2 Up to 10Mb/s (HDTV quality) MPEG4 5-64Kb/s (mobile, PSTN) 2Mb/s (TV quality) MPEG7, MPEG21 H.261 and H.263 n 64Kb/s, 1n 30

6. Streaming Media sender • not interactive • Delay • Less stringent • loss • Stringent, (can be long for the first packet but should then not vary a lot) • Rate • Need a minimum but can vary (as long as the play out buffer does not become empty) • Data constantly generated and played out player

7. Video/Audio Communication sender • person-to-person • interactive • Delay • Stringent (should be small and constant) • Loss • Could be tolerated (depending on the situation and language) • Rate • Need a minimum and should not vary a lot • Data constantly generated and played out • Except for silence suppression player

8. What are transport protocols needed for? • Addressing: application to application addressing • Reliable delivery (if needed) the receiver application should receive the same datastream the source puts on the net • Segment order maintenance: data segments should reach the applicationin the same order they left the sender • Flow control: the data sending speed should adapt itself to the receiversspeed • Congestion control: the transmission speed can not be faster than thespeed of the slowest link traversed on the connections path • Segmentation: data is sent in segments that provide the highest throughout. • Media transport protocols should further inform the receiver about the content of the data

9. Application Addressing • IP addresses enable us to get from one device to another • Port numbers allow us to address one process at a device 195.33.33.33 192.22.22.22 77777 88888 80

10. Internet Transport Protocols • We will focus on the two main Internet transport protocols: UDP and TCP. • Transmission Control Protocol (TCP) • Connection oriented protocol intended to provide a reliable end-to-end byte stream over an unreliable network. • User Datagram Protocol (UDP) • Connectionless protocol that provides an unreliable end-to-end datagram service.

11. Transport Control Protocol

12. TCP (RFC 793) • TCP is connection oriented and full duplex. • Reliabilityachieved using acknowledgments, round trip delay estimations and data retransmission. • TCP uses a variable window mechanism for flow control. • Congestion control and avoidance is realized using slow start and congestion avoidance schemes. • Specified in RFC 793; corrections and finer details in Host Requirement RFCs 1122 and 1123. • Used for FTP, HTTP, mail

13. IP encapsulation of TCP segments IP datagram TCP segment IP header TCP header TCP data 20 bytes 20 bytes

14. TCP header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

15. TCP connection Establishment SYN 141 (0)win 100, <mss 1024> SYN 181 (0) win 100, <mss 1024> ACK 142 ACK 182 • Connection establishment is done with a three way handshake client server

16. TCP Data Exchange 142 144 ACK 143 ACK 143 client server 143 • Gaps in the sequence numbers indicate losses to the receiver • Missing or repeated acknowledgements indicate loss to the sender

17. Normal TCP connection termination • 4 segments are needed to terminate a TCP connection • Each end must be shut down independently. • Either end can send a FIN when is it done. • The other end ACK’s the FIN. application CLOSE FIN deliver EOF to application ACK of FIN application CLOSE FIN ACK of FIN

18. Flow Control in TCP • TCP uses a sliding window mechanism to adjust the senders transmission speed to that of the receiver. • The sliding window specifies the amount of data the sender is allowed to transmit without receiving additional ACKs. • ACK segments contain the last correctly received byte and the number of bytes the receiver is still willing to accept.

19. Window Flow Control RTT 1 2 W data 1 2 W • Rate= (W packets x packet size) / RTT 1 2 W Source time ACKs Destination 1 2 W time

20. TCP Congestion Control • To avoid congestion in advance, the sender must adapt its transmission window to the available link bandwidth. • On connection establishment TCP uses a window of the size of 1 MSS as Congestion Window, cwnd. • Increase the window size till some loss is noticed • Decrease the window after a loss and start increasing again • Slow Start: the congestion window is increased by 1 MSS for each acknowledged segment (exponential increase of cwnd). • The receiver also announces how much buffer it still has for the connection (advertised window) • At any time the sender has a transmission window of min (advertised window, congestion window)

21. Slow Start sender receiver cwnd 1 data packet 1 RTT ACK 2 3 4 5 6 7 8 cwnd  cwnd + 1 (for each ACK)

22. Congestion Avoidance sender receiver cwnd 1 data packet ACK 2 1 RTT 3 4 cwnd  cwnd + 1 (for each cwnd ACKS)

23. Congestion Avoidance • ssthresh = ½ of window before loss • Slow start upto ssthresh • Starts when cwnd  ssthresh • Set at beginning of communication to a large value • Updated after a loss • On each successful ACK: cwnd  cwnd + 1/cwnd • Linear growth of cwnd each RTT: cwnd  cwnd + 1

24. TCP Tahoe (Jacobson 1988) window time CA SS SS: Slow Start CA: Congestion Avoidance

25. TCP over Wireless • In fixed networks losses are considered as congestion indication • In wireless networks losses might occur due to the characteristics of the physical link • Reacting to losses in a similar manner as in fixed netwroks is thus wasteful • Solutions: • Use a new TCP • Use mechanisms for distinguishing between congestion and wireless losses

26. User Datagram Protocol

27. UDP (RFC 768) • UDP is a simple, datagram-oriented protocol. • Each output operation by a process produces exactly one UDP datagram, which causes one IP datagram to be sent. IP datagram UDP datagram IP header UDP header UDP data 20 bytes 8 bytes

28. UDP header • port numbers: used to identify the sending and the receiving process. • UDP and TCP modules demultiplex incoming data from IP. • UDP port numbers are looked at only by UDP. 16-bit source port number 16-bit destination port number 16-bit UDP length 16-bit UDP checksum data (if any)

29. When should I use UDP? • UDP is not reliable!! • The amount of data to be transmitted is small. • The overhead of creating connections and ensuring reliable delivery may be more work than re-transmitting the entire data set. • Signaling protocols • Applications that fit a “query-response” model. • The response can be used as a positive acknowledgement to the query. • Messaging • The application provides its own reliable data delivery mechanism. • When minimizing overhead is more important than reliability. • e.g. video or speech transmission • You can even turn off UDP checksum

30. UDP vs. TCP Traffic Characteristics packet/s packet/s Receiver Sender p p time time window window SS SS time time CA CA SS: Slow Start CA: Congestion Avoidance SS: Slow Start CA: Congestion Avoidance loss time

31. Real Time Transport Protocol Based on slides by Vincent Roca

32. Real Time Transport Protocol (RTP) • Why another transport protocol? • media content type • talk spurts • sender identification • timing • intra-media synchronization: remove jitter with playout buffers • inter-media synchronization: lip-synch between audio-video • loss detection • segmentation and reassembly • security (encryption)

33. RTP: Functions Media content IP UDP RTP • Standardized by the IETF and used by ITU-T as well • Designed to be scalable, flexible and separate data and control mechanisms

34. RTP: Header V P X M Ct Payload Sequence number Timestamp Synchronization Source Identifier (SSRC) Contributing Source Identifier (CSRC) Payload

35. RTP: Header RTP version V V P X M CC Payload Sequence number Timestamp Synchronization Source Identifier (SSRC) Contributing Source Identifier (CSRC) Payload

36. RTP: Header Padding for encryption P CC Payload V P X M Sequence number Timestamp Synchronization Source Identifier (SSRC) Contributing Source Identifier (CSRC) Payload

37. RTP: Header Extension bit Allows adding experimental headers X V P X M CC Payload Sequence number Timestamp Synchronization Source Identifier (SSRC) Contributing Source Identifier (CSRC) Payload

38. RTP: Header Marker bit Usage depends on codec and media (end of frame for example) V P X M CC Payload Sequence number Timestamp Synchronization Source Identifier (SSRC) Contributing Source Identifier (CSRC) Payload

39. RTP: Header Contributers Count Number of sources contributing to this packet Added by mixers and ranges from 0 to 15 V P X M CC Payload Sequence number Timestamp Synchronization Source Identifier (SSRC) Contributing Source Identifier (CSRC) Payload

40. RTP: Header Audio/Video encoding method V P X M CC Payload Sequence number Timestamp Synchronization Source Identifier (SSRC) Contributing Source Identifier (CSRC) Payload

41. RTP: Header Number of packet incresed by one for each new packet Sequence number V P X M CC Payload Sequence number Timestamp Synchronization Source Identifier (SSRC) Contributing Source Identifier (CSRC) Payload

42. RTP: Header Different fixed value for each compression type (160 for 20 ms at 8000 Hz) V P X M CC Payload Sequence number Timestamp Timestamp Synchronization Source Identifier (SSRC) Contributing Source Identifier (CSRC) Payload

43. RTP: Header A random number identifying the source (unique per source) chosen randomly  detect and solve collisions V P X M Payload Sequence number Timestamp Synchronization source identifier (SSRC) Synchronization Source Identifier (SSRC) Contributing Source Identifier (CSRC) Payload

44. RTP: Header V P X M Payload Sequence number Timestamp Identify the contributing sources to this packet (added by mixers) Synchronization Source Identifier (SSRC) Contributing Source Identifier (CSRC) Payload

45. Time management Two times… • RTP time • Random initial offset (for each stream) • RTP timestamp present in each data packet • Describes the sampling instant of the payoad • Increases by 160 for packets carrying 20ms worth of samples (160) • NTP time (or wallclock time) • Absolute time (use Network Time Protocol format) • NTP timestamp present in each RTCP Sender Report • Relates RTP time to actual time • Enables inter-stream synchronization

46. Real time Transport Control Protocol (RTCP) • Separate packets sent on a different port number • Packets sent in intervals determined based on number of end systems and available bandwidth • several functions • feedback on the quality of data distribution • let everybody evaluate the number of participants • persistant transport-level canonical name for a source, CNAME • usually: user@host • will not change, even if SSRC does! • provides binding across multiple media tools for a single user

47. RTCP generalities • Five RTCP packets • SR sender reports tx and rx statistics from active senders • RR receiver reports rx statistics from other participants, or from active senders if more than 31 sources • SDES source description, including CNAME • BYE explicit leave • APP application specific extensions

48. RTCP generalities… (cont’) • distribution • use same distribution mechanisms as data packets (nm multicast) • multiple RTCP packets can be concatenated by translators/mixers  compound RTCP packet • scalability with session size • RTCP traffic should not exceed 5% of total session bandwidth requires an evaluation of number of participants RTCP tx interval = f(number of participants) • at least 25% of RTCP bandwidth is for source reports let new receivers quickly know CNAME of sources!

49. SR RTCP packets • includes • SSRC of sender identify source of data • NTP timestamp when report was sent • RTP timestamp corresponding RTP time • packet count total number sent • octet count total number sent • followed by zero or more receiver report…

50. RR RTCP packets • includes • SSRC of source identify the source to which this RR block pertains • fraction lost since previous RR (SR) sent (= int(256*lost/expected)) • cumul # of packets lost long term loss • highest seq # received compare losses • interarrival jitter smoothed interpacket distortion • LSR time when last SR heard • DLSR delay since last SR