Transporting Multimedia Data in the Internet

These presentation materials describe Tekelec's present plans to develop and make available to its customers certain products, features and functionality. Tekelec is only obligated to provide those deliverables specifically included in a written agreement signed by Tekelec and customer.

Transporting Multimedia Data in the Internet

Dr. Dorgham Sisalem

Tekelec

[email protected]

Tekelec Confidential

Tekelec Confidential / For Discussion Purposes Only /

Non-Binding

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



Non-Binding

Media Exchange

encoding

packetization

OS

decoding

OSRoutelookup

FCFS

A/D D/A



Non-Binding

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



Non-Binding

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



Non-Binding

Streaming Media

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

sender

player



Non-Binding

Video/Audio Communication

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

sender

player



Non-Binding

What are transport protocols needed for?

• Addressing: application to application addressing

• Reliable delivery (if needed) the receiver application should receive the same data stream the source puts on the net

• Segment order maintenance: data segments should reach the application in the same order they left the sender

• Flow control: the data sending speed should adapt itself to the receivers speed

• Congestion control: the transmission speed can not be faster than the speed 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



Non-Binding

Application Addressing

• IP addresses enable us to get from one device to another

• Port numbers allow us to address one process at a device 80

7777788888

192.22.22.22 195.33.33.33



Non-Binding

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.


Transport Control Protocol



Non-Binding

TCP (RFC 793)

• TCP is connection oriented and full duplex.

• Reliability achieved 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



Non-Binding

IP encapsulation of TCP segments

IP header TCP header TCP data

20 bytes 20 bytes

TCP segment

IP datagram



Non-Binding

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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Non-Binding

• Connection establishment is done with a three way handshake

TCP connection Establishment

clientserver

SYN 141 (0)win 100, <mss 1024>

SYN 181 (0) win 100, <mss 1024>ACK 142

ACK 182



Non-Binding

TCP Data Exchange

client server142

ACK 143

• Gaps in the sequence numbers indicate losses to the receiver

• Missing or repeated acknowledgements indicate loss to the sender

144

ACK 143

143



Non-Binding

Normal TCP connection termination

FIN

ACK of FIN

FIN

ACK of FIN

deliver EOF to application

application CLOSE

application CLOSE

• 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.



Non-Binding

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.



Non-Binding

Window Flow Control

• Rate= (W packets x packet size) / RTT

RTT

time

time

Source

Destination

1 2 W

1 2 W

1 2 W

data ACKs

1 2 W



Non-Binding

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)



Non-Binding

Slow Start

data packetACK

receiversender

1 RTT

cwnd1

2

34

5678

cwnd cwnd + 1 (for each ACK)



Non-Binding

Congestion Avoidance

cwnd1

2

3

1 RTT

4

data packetACK

cwnd cwnd + 1 (for each cwnd ACKS)

receiversender



Non-Binding

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



Non-Binding

TCP Tahoe (Jacobson 1988)

window

SStime

CA

SS: Slow StartCA: Congestion Avoidance



Non-Binding

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


User Datagram Protocol



Non-Binding

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 header UDP header UDP data

20 bytes 8 bytes

UDP datagram

IP datagram



Non-Binding

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)



Non-Binding

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



Non-Binding

UDP vs. TCP Traffic Characteristics

packet/s

time

Sender

p

time

loss

window

SStime

CA


packet/s

time

Receiver

p

window

SStime

CA



Real Time Transport Protocol

Based on slides by Vincent Roca



Non-Binding

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)



Non-Binding

RTP: Functions

• Standardized by the IETF and used by ITU-T as well

• Designed to be scalable, flexible and separate data and control mechanisms

IP UDP RTP Media content



Non-Binding

RTP: Header

V P X Sequence number

PayloadM

Timestamp

Synchronization Source Identifier (SSRC)

Payload

Ct

Contributing Source Identifier (CSRC)



Non-Binding


CC

RTP: Header


PayloadM

Timestamp


Payload

V

RTP version



Non-Binding


CC

RTP: Header


PayloadM

Timestamp


Payload

P

Padding for encryption



Non-Binding

CC


RTP: Header


PayloadM

Timestamp


Payload

X

Extension bitAllows adding experimental headers



Non-Binding

CC


RTP: Header


Payload

Timestamp


Payload

Marker bitUsage depends on codec and media (end of frame for example)

M



Non-Binding

M


RTP: Header


Payload

Timestamp


Payload

Contributers CountNumber of sources contributing to this packetAdded by mixers and ranges from 0 to 15

CC



Non-Binding


CC

RTP: Header


M

Timestamp


Payload

Audio/Video encoding method

Payload



Non-Binding

CC


RTP: Header


PayloadM

Timestamp


Payload

Sequence number

Number of packet incresed by one for each new packet



Non-Binding

MCC


RTP: Header


Payload

Timestamp


Payload

Timestamp

Different fixed value for each compressiontype (160 for 20 ms at 8000 Hz)



Non-Binding


RTP: Header


PayloadM

Timestamp


Payload

Synchronization source identifier (SSRC)

A random number identifying the source(unique per source)chosen randomly detect and solve collisions



Non-Binding

RTP: Header


PayloadM

Timestamp


Payload

Identify the contributing sources to this packet(added by mixers)




Non-Binding

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



Non-Binding

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



Non-Binding

RTCP generalities

• Five RTCP packets SR sender reports

tx and rx statistics from active senders

RR receiver reportsrx statistics from other participants, or fromactive senders if more than 31 sources

SDES source description, including CNAME

BYE explicit leave

APP application specific extensions



Non-Binding

RTCP generalities… (cont’)

• distribution use same distribution mechanisms as data packets (nm 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 reportslet new receivers quickly know CNAME of sources!



Non-Binding

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…



Non-Binding

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



Non-Binding

SDES RTCP packet

• Must contain: a CNAME item (canonical identifier/name)

• May contain a NAME item (real user name) an EMAIL item a PHONE item a LOC item (geographic location) a TOOL item (application name) a NOTE item (transient msg, e.g. for status) a PRIV item (private extension)



Non-Binding

Example of RTCP compound packet

SRsenderreport

receiverreport

receiverreportS

SR

C

SS

RC

SS

RC

source 2 source 3

RTCP packet 1

SDES CNAME PHONE

SS

RC

RTCP packet 2

compound packet(single UDP datagram)



Non-Binding

RTP payload

• RTP is generic… define a payload for each target media! Example: MPEG1/2 video packetization must follow general guidelines

RFC 2736, December 1999 Goal:

« every packet received must be usefull !!! »

Potential problems over standard Internet packets may be

lost reordered fragmented by IP if size > MTU (max tx unit)



Non-Binding

RTP payload… (cont’)

• Example of what must not happen!!! loss multiplication effect due to bad framing

application data unit

fragment 1 fragment 2 fragment 3

application

RTPnetwork tx

fragment 2fragment 1

LOST

RTP

uncomplete data!!!application useless!!!

Src

Rx


Transport Mechanisms for Group Communication

Based on slides of Ofer Hadar, Jon Crowcroft



Non-Binding

Which Applications?

• Conferencing: Audio/video communication and application sharing First multicast session IETF 1992 Many-to-many scenarios

• Media Broadcast Internet TV and radio One to many scenario

• Gaming Many to many



Non-Binding

What is needed?

• Efficient transport: avoid sending the same content more than once

• Conference setup who is allowed to start a conference? Who fast can a conference be initiated?

• Security and privacy: How to prevent not-wanted people from joining? How to secure the exchanged content?

• Floor control: How to maintain some talking order?



Non-Binding

How to Realize? Centralized

• All register at a central point

• All send to central point

• Central point forwards to others

• Simple to implement

• Single point of failure

• High bandwidth consumption at center point Must receive N flows

• High processing overhead at center point Must decode N flows mix the flows and encode N flows With no mixing the central point would send Nx(N-1) flows

• Appropriate for small to medium sized conferences

• Simple to manage and administer: Allows access control and secure communication Allows usage monitoring Support floor control

• Most widely used scenario

• No need to change end systems

• Tightly coupled: Some instances know all information about all participants at all times



Non-Binding

Audio Mixing Server

G.711

E

G.729

E

GSM

E

Periodic timer

B

A

C

X=A+B+C

D

G.729

D

GSM

D

B

A

C

X-A=B+C

X-B=A+C

X-C=B+A

E: EncoderD: Decoder

G.711

D

G.729

D

GSM

D

G.711



Non-Binding

• All establish a connection to each other

• All can send directly to the others

• Each host will need to maintain N connections

• Outgoing bandwidth: Send N copies of each packet simple voice session with 64kb/s would translate to 64xN kb/s

• Incoming bandwidth: If silence suppression is used then only active speakers send data

• In case of video lots of bandwidth might be consumed Unless only active speakers send video

• Floor control only possible with cooperating users

• Security: simple! do not send data to members you do not trust

• End systems need to mix the traffic –more complex end systems

How to Realize? Full Mesh



Non-Binding

How to Realize? Peer-to-Peer

• Mixing is done at the end systems

• Increases processing over-head at the end systems

• Increases overall delay Possibly mixed a multiple times

• If central points leave a conference the conference is dissolved

• Security: Must trust all members Any member could send all data to non-trusted

users

• Access control: Must trust all members Any member can invite new members

• Floor control: requires cooperating users



Non-Binding

IP Multicast

• Previous scenarios build group communication on top of unicast sessions

• Enhance the network with support for group communication Optimal distribution is delegated to the network routers instead of end

systems

• Receivers inform the network of their wish to receive the data of a communication session

• Senders send a single copy which is distributed to all receivers



Non-Binding

Group Communication: Multicast or Broadcast?

• Broadcast: Sent to a broadcast address (all 1) Receivable by all reached hosts Wakeup all hosts even if they are not involved

• Multicast Sent to an address between 224.0.0.0 and 239.255.255.255

Do not describe a host or interface but a group of receivers

Receivable by all interested hosts All others filter it away



Non-Binding

What is multicast good for?

A

E

B

D

C

• File transfer from C to A,B,D and E• Unicast: multiple copies • Multicast: single copy



Non-Binding

IP Multicast

• True N-way communication Any participant can send at any time and everyone receives the message

• Unreliable delivery Based on UDP: Why?

Avoids hard problem (e.g., ACK explosion)

• Efficient delivery Packets only traverse network links once (i.e., tree delivery)

• Location independent addressing One IP address per multicast group

• Receiver-oriented service model Receivers can join/leave at any time Senders do not know who is listening



Non-Binding

IP Multicast

• Service All senders send at the same time to the same group Receivers subscribe to any group Routers find receivers

• Reserved IP addresses special IP addresses (class D): 224.0.0.0 through 239.255.255.255

class D: 1110+28 bits 268 million groups (plus scope for add. reuse)

224.0.0.x: local network only 224.0.0.1: all hosts Static addresses for popular services (e.g., SAP –Session

Announcement protocol)



Non-Binding

Multicast Routing

• What is the problem? Need to find all receivers in a multicast group Need to create spanning tree of receivers

• Design goals Minimize unwanted traffic Minimize router state Scalability Reliability



Non-Binding

Data Flooding (Source based Trees)

• Sends data to all nodes in network

• Problem Needs to prevent cycles Needs to send only once to all nodes in network Routers could keep track of every packet and check if it had

previously seen this packet, but that means too much states

Sender

R3R1

R2



Non-Binding

Reverse Path Forwarding (RPF)

• Simple technique for building trees

• Send out on all interfaces except the one with the shortest path to the sender

• In unicast routing, routers send to the destination via the shortest path

• In multicast routing, routers send away from the shortest path to the sender Need to have a reverse routing table

• Pruning: When no receivers want a session then inform the upper router not to send data

Need to periodically check whether this is still the case



Non-Binding

Reverse Path Forwarding Example

R5 R6

R3R2

R1

R4 R7

Sender

2. Router R2 accepts packets sent from Router R1 because that is the shortest path to the Sender. The packet gets sent out all interfaces.

1. Router R1 checks: Did the data packet arrive on the interface with the shortest path to the Sender? Yes, so it accepts the packet, duplicates it, and forwards the packet out all other interfaces except the interface that is the shortest path to the sender (i.e the interface the packet arrived on).

Drop

Drop3. Router R2 drops packets that arrive from Router R3 because that is not the shortest path to the sender. Avoids cycles.

1. No receivers so prune2. Next packets will not be forwarded to R53. R2 will periodically test R5



Non-Binding

Internet Group Management Protocol (IGMP)

• IGMP allows an end system to express interest in joining a certain multicast group

• Protocol for managing group membership IP hosts report multicast group memberships to neighboring routers Messages in IGMPv2 (RFC 2236)

Membership Query (from routers) Membership Report (from hosts) Leave Group (from hosts)

• Announce-listen protocol with suppression Hosts respond only if no other host has responded

• Soft-state protocol

• IGMP3 allows for joining the multicast data from certain senders



Non-Binding

IGMP Example (1)

Network 1

• Host 1 begins sending packets No IGMP messages sent Packets remain on Network 1

• Router periodically sends IGMP Membership Query

Network 2Router

1

2 4

3



Non-Binding

IGMP Example (2)

Network 1

• Host 3 joins conference Sends IGMP Membership Report message

• Router begins forwarding packets onto Network 2

• Host 3 leaves conference Sends IGMP Leave Group message Only sent if it was the last host to send an IGMP Membership Report message

Network 2Router

1

2 4

33

Membership Report

33

Leave Group



Non-Binding

Multicast Tunneling

• Problem Not all routers are multicast capable Want to connect domains with non-multicast routers between them

• Solution Encapsulate multicast packets in unicast packets Tunnel multicast traffic across non-multicast routers

• MBONE Multicast capable virtual network, subset of Internet Native multicast regions connection with tunnels



Non-Binding

Multicast Tunneling Example (1)

UR1 UR4

MulticastRouter 1

MulticastRouter 2

Sender 1

EncapsulatedData Packet

Unicast Routers

Multicast Router 1 encapsulates multicast

packets for groups that have receivers

outside of network 1. It encapsulates them

as unicast IP-in-IP packets .

Network 1

Receiver

Network 2

Multicast Router 2 decapsulates IP-in-IP

packets. It then forwards them using

Reverse Path Multicast .

UR2 UR3



Non-Binding

Multicast Tunneling Example (2)

MR1 MR2

VirtualInterfaces

Virtual Network Topology



Non-Binding

Operational Multicast Problems

• Require updates of routers

• Lack of experience

• Debugging is difficult

Not much of commercial analysis and debug tools

• Immature protocols and applications

Complicated routing protocols

• Interoperability

Flood and prune/explicit join



Non-Binding

Now about the Real Problems?

• Address allocation

• Security, privacy and IPR

• Busines model and motivation



Non-Binding

Multicast Address Allocation

• Problem Multicast addresses are a limited resource Current multicast address allocation scheme does not scale and makes

multicast routing more difficult Current practice is to randomly allocate an address

Addresses might collide

• Solution Static distribution

Allocate special portions for Ass Use dynamically allocated addresses



Non-Binding

Security, Privacy and Control

• Anybody can send data DoS and flooding attacks

• Anybody can receive data No privacy Could add authentication and authorization during a join request

Sender does not know receivers Who does the authentication?

Encryption for multicast Shared secret between lots of people

Not really a secret Need to update the keys

Intellectual Property Rights (IPR): How to do IPR protection for lots of receivers?

• Floor control is only realizable with cooperating users

• Loosly coupled: no entity knows all information about all other participants all the time



Non-Binding

Business Model and Motivation

• IP multicast reduces the needed bandwidth ISPs want to sell bandwidth

• Senders do not know receivers How to collect money from distributing content

• No security How to ensure protection against DoS, flooding

• Complex and requires new hardware and knowledge When is the sweet point received?

• Conferencing (few-to-few) Can just as well be done with unicast



Non-Binding

Commerical Multicast

• Use application level multicast Multicast routing done using end hosts

Hosts build a multicast routing tables and act as multicast router (but on application level)

User request content using unicast Content distributed over unicast to the final users



Non-Binding

Commerical Multicast

Content source

Traditional

Content source

Application levelmulticast

Documents

Transporting Multimedia Data in the Internet