Streaming Media

Unicast Redundant traffic

Multicast One to many

Video Multicast Multicast Support

multicast enabled network Real-time Requirements Support

Supporting Real-time Requirements QoS and Resource reservation

Resource Reservation to bound data delivery delay, loss, jitter etc.

Adaptive Rate Control Adjust video traffic characteristics to

suit the Internet.

Multicast Group Addressing Distribution Tree Join(graft) Leave(prune)

Video Traffic Periodic generation of frames at

regular intervals. Variable bit rate. Frame periodicity must be maintained

for the video to appear “smooth” Data unavailable at playout is useless. Jitter (variability in interarrival times)

Buffering and Start-up Latency Congestion leads to Data Loss

Decreasing Data Rate Error Control

Summary Delay Sensitive, Loss Insensitive

Multicast and Heterogeneity The Internet is Heterogeneous

Infra-structural (Spatial) Traffic density (Temporal) Administrative

Fairness Goal Every receiver should receive video that is

commensurate to the resources available. Is this fair to “other” traffic?

Fairness Intra-session fairness Inter-session fairness

Rate Adaptive Digital Video Compression, Scene Complexity,

Motion

Video Encoder

Smoothing Buffer

Feedback

Network

Raw video stream is fed to encoder Encoder sends encoded data to

buffer Buffer level provides feedback Feedback is used to control data

output rate at encoder. Quantization, frame rate, pixel

resolution etc. are controlled.

Network feedback can also be used. Queueing information (internal to the

network) End-system information

Adaptive Bit-Rate Video Single Stream Adaptive Approach

Replicated Streams Adaptive Approach

Layered Video Streams Approach

RTP Real-Time Transport Protocol End-to-end Protocol NO notion of “Connection”. (hence

unreliable) Application level Requires framing and segmentation

be taken care of by lower layers.

RTP (continued) Divided into two parts (consecutive

ports for UDP) Data (audio + video packets, even-

numbered port) Control

Can use single PDU in case UDP is not used.

Real-time Transport Protocol

RTP Data Packets 12 byte header data (video/audio)

can be encapsulated in encoding-specific layer.

RTP Data Packet Header Payload Type (1 byte)

eg: JPEG etc. Timestamp (32 bits)

generation instant of the data Sequence marker (16 bits)

packet seq. number to help loss detection Marker bit

end of frame for video beginning of talk-spurt for audio

RTP Data Packet Header (contd) Synchronization Source Identifier

(32 bits) randomly generated identifying

session source.

RTP Control Channel Control protocol called RTCP

QoS monitoring and Congestion Control multicast all other receivers know how others are doing sender-report, helps receivers compute data-rate

Intermedia Synchronization wall-clock time + RTP timestamp allows synch of audio and video

Identification Detailed identification of participant instead of just a 32

bit identifier. Session size estimation and scaling

scaled to 5% of data rate

RTCP Packets

Several types to carry a variety of information Source description (SDES)

CNAME, email, location, name, ... Sender report (SR)

Bytes sent -> estimated rate Timestamp -> synchronization Receiver report (RR) Loss rate, interarrival jitter, roundtrip delay Explicit leave (BYE) Compound packets (SDES CNAME + RR)

RTCP traffic Control

RTP session scale: two to thousands of participants

RTCP traffic increases with session size Want to keep to small fraction of data

bandwidth (5%) Randomized response with rate decreasing

as number of participants increases Give active senders more bandwidth But limited by tolerable age of status

Single Stream Video Multicast Adjust video output rate Three parameters

refresh rate (?) quantizer (color scheme 4:2:2,

4:1:1….) movement detection threshold (what

defines motion) Application can specify which of

these to control

Single Stream Video Multicast RTCP is used for feedback

Feedback implosion probabilistic probing

Fair? (No…..)

Replicated Streams Destination Set Grouping

Multiple replicated streams on different multicast addresses.

Different quality and data rates. Receivers can switch streams

Switching Streams Congestion due to presence of two

streams simultaneously on the same link

Bandwidth Control Protocol Congestion History Checking before

stream switch. Local Area Bandwidth Limit restricts the

number of streams received in local area.

Layered Video Multicast Disjoint layers on different

addresses Cumulative subscription Many protocols making different

assumptions

RLM Receiver based Sender does not participate Receivers share loss information Receivers join and drop groups based

on these shared loss reports. Receivers back off when they or other

receivers see congestion. The higher the layer, the longer the

back-off duration.

Problems with RLM Receiver Consensus Fast Leaves and Joins Impact of failed experiments on

topologically unrelated receivers. UNFAIR Arguably the most cited and most

maligned protocol!!

TCP rate-based Congestion Control Analyze TCP to come with a magic formula

to describe Bandwidth = 1.3 * MTU / (RTT * sqrt(Loss))

Adapt sender rate to match such a formula. But what is RTT?

Let receivers make this decision. Define loss thresholds based on this formula,

for each layer. If loss exceeds this threshold, drop a layer…

http://www.psc.edu/networking/papers/tcp_friendly.html

Summary Multicast RTP/RTCP Rate Adaptation Issues:

Fairness Intra-session Inter-session

Stability Deployability Administrative Issues