Transcript INF 5070 – Media Storage and Distribution Systems

INF 5070 – Media Storage and Distribution Systems:
Protocols
without QoS Support
22/9 - 2003
Overview
Non-QoS protocols:
 Transport level protocols
 Application layer protocols
 Signaling protocols
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
Requirements for Continuous Media
 Acceptable delay
 Seconds in asynchronous on-demand applications
 Milliseconds in synchronous interpersonal communication
 Acceptable jitter
 Milliseconds at the application level
 Tolerable buffer size for jitter compensation
 Delay and jitter include retransmission, error-correction, ...
 Acceptable continuity
 Streams must be displayed in sequence
 Streams must be displayed at acceptable, consistent quality
 Acceptable synchronity
 Inter-media: different media played out at matching times
 Intra-media: time between successive packets must be conveyed to
receiver
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
Basic Techniques
 Delay and jitter
 Reservation (sender, receiver, network)
 Buffering (receiver)
 Scaling (sender)
 Continuity
 Real-time packet re-ordering (receiver)
 Loss detection and compensation
 Retransmission
 Forward error correction
 Stream switching (encoding & server)
 Synchronity
 Fate-sharing and route-sharing (networks with QoS-support)
 Time-stamped packets (encoding)
 Multiplexing (encoding, server, network)
 Buffering (client)
 Smoothing (server)
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
QoS vs. Non–QoS Approaches
 Internet without network QoS support
 Internet applications must cope with networking problems





Application itself or middleware
"Cope with" means either "adapt to" or "don’t care about“
"Adapt to" must deal with TCP-like service variations
"Don’t care about" approach is considered "unfair“
"Don’t care about" approach cannot work with TCP
 Internet with network QoS support
 Application must specify their needs
 Internet infrastructure must change – negotiation of QoS parameters
 Routers need more features



Keep QoS-related information
Identify packets as QoS-worthy or not
Treat packets differently keep routing consistent
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
Protocols for Non–QoS Approaches
Application Layer
Transport Layer
Network Layer
Complete freedom
 Compatibility is an application
issue
TCP/IP Protocol stack
flexibility
 Has Limited
only 4 layers
 UDP
 IP is central
 TCP
 Nothing
mustdevelopments
compete with IP at the
 New
network layer
No flexibility
 There is no QoS support
 IPv4
 Routing
is transparent for the
 IPv6
application
 Transport-unrelated functions are
Physical Layer
INF5070 – media storage and distribution systems
Various
application-layer
tasks
 Not a concern
2003 Carsten Griwodz & Pål Halvorsen
Traditional Transport Layer
Approaches
User Datagram Protocol (UDP)
 Described in
 Internet Engineering Note 88
 Request for Comments 768
 Internet Standard 6
 Often used in multimedia
 Connection-less
 Simple
 add pseudo-header
 calculate checksum
 finish header
 send to IP
 Unreliable
 Unordered
 Datagram-oriented
 Uncontrolled
 Optionally checksummed
INF5070 – media storage and distribution systems
streaming applications – can
build whatever needed on
top
 No...
 ... guarantees
 ... fairness
 ...
2003 Carsten Griwodz & Pål Halvorsen
Transmission Control Protocol (TCP)
 Described in
 Internet Engineering Note 2
 Request for Comments 793
 Internet Standard 7
 High fraction of today’s traffic
is TCP-based, e.g.,



 Connection-oriented
 Reliable
 Ordered
 Stream-oriented
 Flow-controlled
 Checksummed

 We need to know some
details about the TCP
behavior/traffic –
we’ll briefly look at TCP ...



INF5070 – media storage and distribution systems
electronic mail
web
file transfers
...
...retransmission timeouts
...congestion control
...friendliness
2003 Carsten Griwodz & Pål Halvorsen
TCP Round Trip Time Estimation
round 2
round 1
sender
receiver
EstimatedRTT = (1 - ) * EstimatedRTT +  * SampleRTT
usually,  = 0.125 [RFC 2988]
Initially, EstimatedRTT is based on packets sent during
“handshake” operation (connection setup), e.g., 3
The following RTTs are calculated using the formula above
taking one SampleRTT each round:
- going slightly up if EstimatedRTT < SampleRTT
- going slightly down if EstimatedRTT > SampleRTT
- e.g. ( = 0.5 ):
round 3
2) EstimatedRTT = .5 * 3 + .5 * 3 = 3
3) EstimatedRTT = .5 * 3 + .5 * 5 = 4
round 4
4) EstimatedRTT = .5 * 4 + .5 * 1 = 2.5
NOTE: the next RTT is
RTT
not necessarily ready
before the corresponding 65
round starts (and we start 4
sending the next packets) 32
1
INF5070 – media storage and distribution systems
time
2003 Carsten Griwodz & Pål Halvorsen
TCP Timeout
 The EstimatedRTT is used for the retransmission timer –
timeout interval should be



≥ estimatedRTT – avoiding unnecessary retransmissions
but not too much larger – slow retransmit, large delay
margin should be large when lot of fluctuations, otherwise small
 Additionally, TCP uses RTT variation – deviated RTT:
DevRTT = (1 - ) * DevRTT +  * | SampleRTT – EstimatedRTT |, usually, = 0.25
 Retransmission interval given by
TimeoutInterval = EstimatedRTT + 4 * DevRTT
 Modifications
 timeout interval doubling each timeout (form of congestion control)
 fast retransmission – three duplicate ACKs (decrease delay)
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
TCP Congestion Control
 TCP limit sending rate as a function of perceived
network congestion


little traffic – increase sending rate
much traffic – reduce sending rate
 Congestion algorithm has three major “components”:
 additive-increase, multiplicative-decrease (AIMD)
 slow-start
 reaction to timeout events
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
TCP Congestion Control
Initially, the CONGESTION WINDOW
is 1 MSS (message segment size)
receiver
round 1
sender
round 2
sent packets
per round
(congestion window)
Then, the size increases by 1 for each
received ACK (until a threshold is
reached or an ACK is missing)
round 3
16
8
round 4
4
2
1
time
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
TCP Congestion Control
Normally, the threshold is 65 K
Losing a single packet (TCP Tahoe):
sent packets
per round
(congestion window)
80
75
 threshold drops to halve CONGESTION WINDOW
 CONGESTION WINDOW back to 1
Losing a single packet (TCP Reno):
 threshold drops to halve CONGESTION WINDOW
 CONGESTION WINDOW back to new threshold
70
65
16
60
55
50
45
40
35
8
30
25
20
4
15
2
10
1
5
INF5070 – media storage and distribution systems
time
2003 Carsten Griwodz & Pål Halvorsen
TCP Congestion Control
 TCP congestion control is based on the notion that the
network is a “black box” –
congestion indicated by a loss
 Sufficient for best-effort applications, but losses might
severely hurt traffic like audio and video streams
 congestion indication better enabling features like
quality adaptation
 Use
active queue management to detect congestion
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
Random Early Detection (RED)
 Random Early Detection (discard/drop) (RED) uses
active queue management
 Drops packet in an intermediate node based on
average queue length exceeding a threshold


TCP receiver reports loss in ACK
sender applies MD
 Current Internet RED
 restricted to packet drop as congestion indication, but
 could also only indicate congestion setting congestion
experienced (CE) bit in packet header
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
Early Congestion Notification (ECN)
 Early Congestion Notification (ECN) - RFC 2481
 an end-to-end congestion avoidance mechanism
 Implemented in routers and supported by end-systems
 Not multimedia-specific, but very TCP-specific
 Two IP header bits used


ECT - ECN Capable Transport, set by sender
CE - Congestion Experienced, may be set by router
 Extends RED
 if packet has ECT bit set




ECN node sets CE bit
TCP receiver sets ECN bit in ACK
sender applies multiple decrease (AIMD)
else

Act like RED
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
Early Congestion Notification (ECN)
Tail drop
RED
ECN
 Effects
 Congestion is not oscillating - RED & ECN
 ECN-packets are never lost on uncongested links
 Receiving an ECN mark means



TCP window decrease
No packet loss
No retransmission
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
TCP Friendliness
A TCP connection’s
throughput is bounded
 wmax - maximum retransmission
window size
 RTT - round-trip time
Congestion windows size
changes
 AIMD algorithm
 additive increase, multiple
decrease
TCP is said to be fair
 Streams that share a path will
reach an equal share
The TCP send rate limit is
wmax
Rs 
RTT
In case of at least one loss
in an RTT
w    w,  1
2
In case of no loss ,
w  w  , 1
That’s not generally true
 Bigger RTT
 higher loss probability per RTT
 slower recovery
 Disadvantage for long-distance
traffic
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
TCP Friendliness
 A protocol is TCP-friendly if


Colloquial: It long-term average
throughput is not bigger than TCP’s
Formal: Its arrival rate is at most
some constant over the square root
of the packet loss rate
Rr  p  C
P – packet loss rate
C – constant value
Rr – packet arrival rate
 The AIMD algorithm with ≠1/2 and ≠1 is still TCP-friendly,
if the rule is not violated
 TCP-friendly protocols may 



if the rule is not violated -
Probe for available bandwidth faster than TCP
Adapt to bandwidth changes more slowly than TCP
Use different equations or statistics, i.e., not AIMD
Not use slow start (i.e., don’t start with w=0)
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
Comparison of Non-QoS Philosophies
Pro UDP
Pro TCP
Scalable due to multicast
Proxies, caches and reflectors
are beneficial anyway, can replace multicast
ISPs dislike multicast
Faster
Existing optimization is for TCP
only one end-to-end delay for packet delivery
routers, firewall, OS network stacks
Application controls retransmission
No need to handle retransmissions
Scalable codecs are needed anyway
Lossless
codecs don’t need additional loss resistance
Small buffers possible
if loss is handled gracefully
TCP-friendliness
TCP-friendly without additional work
can be implemented (end-to-end)
variations of the algorithm possible
Works through firewalls
One-fits-all protocol possible
Most applications are on-demand
on-demand, quasi-broadcasting, conferencing
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
Using Standard Protocols
Over UDP
RTP
Real Time Protocol
IETF std, supported by ITU-T &
Industry
Over TCP
RTP in RTSP over TCP
standardized worst-case fallback
firewall-friendly
Alternative Transport
SCTP
Stream Control Transmission Protocol
IETF RFC, supported by telephone
industry
RLM
TCP-friendly, needs fine-grained
layered video
"Progressive Download" or
"HTTP Streaming"
SR-RTP
application-level prefetching and
buffering
trivial, cheap, firewall-friendly
Datagram Congestion Control
Protocol
IETF RFC, driven by TCP-friendliness
researchers
Priority Progress Streaming
PRTP-ECN
needs special encoding
needs special routers for ’multicast’
Partially reliable transport protocol
using ECN
Research, Univ. Karlstad
TCP-friendly with RTP/UDP
needs special encoding
(OpenDivX)
DCCP
VDP
Video Datagram Protocol
Research, for Vosaic
MSP
Media Streaming Protocol
Research, UIUC
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
RTP: An Application
Layer Approach
Real-time Transport Protocol (RTP)
 Real-time Transport Protocol (RTP)
 RFC 1889
 Designed for requirements of real-time data transport
 NOT real-time
 NOT a transport protocol
 Two Components:
 Real-Time Transport Protocol (RTP)
 RTP Control Protocol (RTCP)
 Provides end-to-end transport functions
 Scalable in multicast scenarios
 Media independent
 Mixer and translator support
 RTCP for QoS feedback and session information
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
Real-time Transport Protocol (RTP)
 No premise on underlying
resources


layered above transport protocol
no reservation / guarantees
application
media
encapsulation
 Integrated with applications
RTP
RTCP
 RTP follows principles of

Application Level Framing
and

Integrated Layer Processing
TCP
IPv4/6
Ethernet
INF5070 – media storage and distribution systems
UDP
ST-2
ATM
AAL5
ATM
2003 Carsten Griwodz & Pål Halvorsen
RTP Control Protocol (RTCP)
 Companion protocol to RTP (tight integration with RTP)
 Monitoring



Feedback to members of a group about delivery quality, loss, etc.



Sources may adjust data rate
Receivers can determine if QoS problems are local or network-wide
Loose session control



of QoS
of application performance
Convey information about participants
Convey information about session relationships
Automatic adjustment to overhead

report frequency based on participant count
 Typically, “RTP does ...” means “RTP with RTCP does ...”
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
RTP
 RTP services are:
 Sequencing
 Synchronization
 Payload identification
 QoS feedback and session information
 RTP supports
 Multicast in a scalable way
 Generic real-time media and changing codecs on the fly
 Mixers and translators to adapt to bandwidth limitations
 Encryption
 RTP is not designed for:
 Reliable delivery
 QoS provision or reservation
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
RTP Functions
 RTP with RTCP provides:
 Support for transmission of real-time data
 Over multicast or unicast network services
 Functional basis for this:
 Loss detection – sequence numbering
 Determination of media encoding
 Synchronization – timing
 Framing - “guidelines” in payload format definitions
 Encryption
 Unicast and multicast support
 Support for stream “translation” and “mixing” (SSRC; CSRC)
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
RTP Profile (RFC 1890)
 Set of standard encodings and payload types
 Audio: e.g. PCM-u, GSM, G.721
 Video: e.g. JPEG, H.261
 Number of samples or frames in RTP packet
 Sample-based audio: no limit on number of samples
 Frame-based audio: several frames in RTP packet allowed
 Clock rate for timestamp
 Packetized audio: default packetization interval 20 ms
 Video: normally 90 kHz, other rates possible
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
RTP Profiles
 Payload type identification
 RTP provides services needed for generic A/V transport



Particular codecs with additional requirements
Payload formats defined for each codec: syntax and semantic of RTP payload
Payload types


static: RTP AV profile document
dynamic: agreement on per-session basis
 Profiles and Payload Formats in RTP Framework
Additional
Profiles
Payload
Formats
Dynamic Payload Types
AV Profile
RTP / RTCP
INF5070 – media storage and distribution systems
PT mapping outside RTP
(e.g. SDP)
2003 Carsten Griwodz & Pål Halvorsen
RTP Quality Adaptation
Application
Decoding
RTP
Application
Encoding
RTCP
Encoding
RTCP
Decoding
RTP
UDP/IP
UDP/IP
 Component interoperations for control of quality
 Evaluation of sender and receiver reports
 Modification of encoding schemes and parameters
 Adaptation of transmission rates
 Hook for possible retransmissions (outside RTP)
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
RTP Packet Format
Typical IETF RFC bit-exact representation
a longword (32 bit)
a byte
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC
|M|
PT
|
SEQ
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
TST
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
synchronization source (SSRC) identifier
|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
contributing source (CSRC) identifiers
|
|
....
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
header extension
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
payload (audio, video, ...)
|
|
....
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
RTP Packet Format
Version number, always 2
Padding indicator bit
if set, number of padding bytes is in last byte of payload
Header extension bit
True if header extension is present
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC
|M|
PT
|
SEQ
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
TST
|
7 bit payload type
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
synchronization source (SSRC) identifier
|
Allows
identification
of
the
payload’s
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
contributing sourcecontent
(CSRC) identifiers
|
type
|
....
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Marker
bit
|
header extension
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Meaning depends on payload profile,
|
payload
(audio,
video, ...)
|
e.g.
frame
boundary
|
....
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 bit CSRC count, indicates the number of
contributing sources in the header
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
RTP Packet Format
16 bit sequence number
32 bit timestamp
32 bit SSRC
Synchronization source identifier, a random number
identifying the sender
Header extension, multiples of 32 bit
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC
|M|
PT
|
SEQ
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
TST
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
synchronization source (SSRC) identifier
|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
contributing source (CSRC) identifiers
|
|
....
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
header extension
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
payload (audio, video, ...)
|
Several 32 bit CSRC
|
....
|
Contribution
source
identifier,
the
number
is
indicated
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
by CC
A mixer copies the original sources’ SSRCs here
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
RTP Packet Format
 Relatively long header (>40 bytes)
 overhead carrying possibly small payload
 header compression
 other means to reduce bandwidth (e.g. silence suppression)
 No length field
 exactly one RTP packet carried in UDP packet
 Can use TCP or ATM AAL5

do-it-yourself packaging
 Header extensions for payload specific fields possible
 specific codecs
 error recovery mechanisms
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
RTCP Packets
R
SR / RR
SDES
BYE
APP
Compound (UDP) Packet
 Several RTCP packets carried in one compound packet
 RTCP Packet Structure
 SR
Sender Report (statistics from active senders:
bytes sent -> estimate rate)
 RR
Receiver Report (statistics from receivers)
 SDES
Source Descriptions (sources as “chunks” with
several items like canonical names, email, location,...)
 BYE
explicit leave
 APP
extensions, application specific
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
RTCP Sender / Receiver Reports
 Sender report

Sender Information



Timestamps (RTP, NTP)
Packet Count, Byte Count
List of statistics per source heard
(receiver reports)
 Receiver report




...
Reception Report
Profile Specific Extensions
loss statistics
inter-arrival jitter
timestamp of last SR
delay between reception of last SR
and sending of RR
 Analysis of reports

Reception Report
for each source:


Header
Sender Information
cumulative counts for short and
long time measurements
NTP timestamp for encoding- and
profile independent monitoring
INF5070 – media storage and distribution systems
Header
Reception Report
...
Reception Report
Profile Specific Extensions
2003 Carsten Griwodz & Pål Halvorsen
RTP Mixer
 Mixer
 Reconstructs constant spacing generated by sender
 Translates audio encoding to a lower-bandwidth
 Mixes reconstructed audio streams into a single stream
 Resynchronizes incoming audio packets




New synchronization source value (SSRC) stored in packet
Incoming SSRCs are copied into the contributing synchronization
source list (CSRC)
Forwards the mixed packet stream
Useful in conference bridges
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
RTP Translator
MPEG
Sink
MPEG
Source
ATM
UDP
H.263
Sink
Protocol
Translator
Profile
Translator
 Translation between protocols
 e.g., between IP and ST-2
 Two types of translators are installed
 Translation between encoding of data
 e.g. for reduction of bandwidth without adapting sources
 No resynchronization in translators
 SSRC and CSRC remain unchanged
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
RTP Identifiers
SSRC chosen by sender S1
SSRC chosen by mixer M1
S1
S3
S3:19
S1:10
M1
S2:1
M1:33 (10,1)
M1:33 (10,1)
T1
S4:13
R1
M2
M2:17 (19,13,33)
S4:13
S2
S4
Translators keep SSRCs and CSRCs
CSRCs from mixed sources S1 and S2
CSRCs contain previous SSRCs, but not previous CSRCs
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
Protocol Development
 Changes and extensions to RTP
 Scalability on very large multicast groups
 Congestion Control
 Algorithms to calculate RTCP packet rate
 Several profile and payload formats
 Efficient packetization of Audio / Video
 RTCP-based retransmission
 Loss / error recovery
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
Other Application Layer
Approaches
Progressive Download
 In-band in long-running HTTP response
 Plain file for the web server
 Even simpler than FTP
 No user interactions – start, stop, ...
 If packet loss is ...
 ...low – rate control by back-pressure from client
 ...high – client’s problem
 Applicability
 Theoretical



For very low-bit-rate codecs
For very loss-intolerant codecs
Practical

All low-volume web servers
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
Progressive Download
Web server
Backpressure !
Decoder
Receive buffer
TCP Stack
TCP Stack
Can recreate timing from
media file
Accepts buffer underruns
Serves requested files as
quickly as possible
Network (uncongested)
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
Progressive Download
Web server
Retransmission
Timeout
Decoder
Receive buffer
TCP Stack
TCP Stack
Network (congested)
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
Priority Progress Streaming
 Unmodified TCP (other transports conceivable)
 Unmodified MPEG-1 video-in (other encoding formats conceivable)
 Real-time video processing
 Convert MPEG to Spatially Scalable MPEG (SPEG) – 10-25% overhead
 Packetize SPEG to separate by frame and by SNR quality step


Assign priorities to SPEG packets


More variations conceivable: color, resolution
Dynamic utility curves indicate preference for frame or SNR dropping
Write SPEG packets in real-time into reordering priority progress queue
 Queues are long
 Much longer than TCP max window
 Dynamically adjustment allows fast start and dynamic growth
 With longer queues


Total delay is increased
High priority packets win more often
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
Priority Progress Streaming
Priority Progess Queue
Timing Generator
Priority Mapper
SPEG transcoder
Smoothing buffer
SPEG transcoder
MPEG decoder
Viewer
buffer size to account
for priority reordering
& TCP backpressure
MPEG file
TCP
Net
TCP
Transparent
OS Issues
bottlenecks
slow TCP down
Packets to send
High priority
Medium priority
Low priority
Priority Progress Queue
INF5070 – media storage and distribution systems
To TCP
2003 Carsten Griwodz & Pål Halvorsen
Receiver-driven Layered Multicast (RLM)
 Requires
 IP multicast
 layered video codec
(preferably exponential thickness)
Sender
Router
Receiver
 Operation
 Each video layer is one IP multicast group
 Receivers join the base layer and extension layers
 If they experience loss, they drop layers (leave IP multicast groups)
 To add layers, they perform “join experiments”
 Advantages
 Receiver-only decision
 Congestion affects only sub-tree quality
 Multicast trees are pruned, sub-trees have only necessary traffic
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
Receiver-driven Layered Multicast (RLM)
 Requires
 IP multicast
 layered video codec
(preferably exponential thickness)
Sender
Router
Receiver
 Operation
 Each video layer is one IP multicast group
 Receivers join the base layer and extension layers
 If they experience loss, they drop layers (leave IP multicast groups)
 To add layers, they perform "join experiments“
 Advantages
 Receiver-only decision
 Congestion affects only sub-tree quality
 Multicast trees are pruned, sub-trees have only necessary traffic
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
Receiver-driven Layered Multicast (RLM)
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
Receiver-driven Layered Multicast (RLM)
 Layer size considerations


Adaptations are in steps of 1 layer
Big layers



Small layers




Join experiments have huge impact
Quality changes are very visible
Many addresses are used
Multicast routing effort is high
Fair share is hard to achieve (don’t
release bandwidth quickly enough)
Exponential layer sizes


Bad enough
Best possible mix
 Other problems


Synchronization problems
PIM-SM removes sub-trees quickly

Join and leave operations are very slow
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
Receiver-driven Layered Multicast (RLM)
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
Stream Control Transmission Protocol (SCTP)
 Stream Control Transmission Protocol
 RFC2960, IETF Standards Track &
SCTP Unreliable Data Mode Extension (draft-ietf-tsvwg-usctp-00.txt)
 Features





Connection-oriented
Message-oriented
Reliable (with extension also: unreliable, partially reliable)
Fully ordered, unordered, partially ordered delivery
Multi-homed
 Origin
 Signaling protocol for SS7 transport over IP networks
 Players

Motorola, Cisco, Siemens, Nortel Networks, Ericsson, Telcordia, UCLA, ACIRI
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
Stream Control Transmission Protocol (SCTP)
Association
Streams
Association endpoints
This side is dual-homed
Stream to active destination
address
Stream to idle destination address
Only HEARTBEAT messages
 Connection Management
 4-way handshake for setup
 Always bi-directional association (no one-way teardown)
 Up to 216-1 streams per direction and association
 Cookie exchange against man-in-the-middle attack
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
Stream Control Transmission Protocol (SCTP)
 SCTP packets



Consist of one or more chunks
Chunks are bundled automatically
User can request unbundled packets

This prevents delay, not bundling
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 Number
|
Destination Port Number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Verification Tag
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Checksum
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Chunk Type | Chunk Flags |
Chunk Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\
\
/
Chunk Value
/
\
\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
INF5070 – media storage and distribution systems
Chunks:










DATA
SACK
INIT
ABORT
SHUTDOWN
HEARTBEAT
ERROR
ECNE
CWR
& responses
2003 Carsten Griwodz & Pål Halvorsen
Stream Control Transmission Protocol (SCTP)
 Deadlines


Applications can give deadline for
packet sending
Once sent, delivery is guaranteed
(retransmission)
 Reliability

Sender and receiver window are
computed





Arrival is reported by SACK chunks
SACK chunks



per stream
in bytes
changed per stream as in TCP
are piggybacked
contain ranges of packets
Retransmission


not before 4th missing report
always before new packets
 Delivery

Sender can specify


unordered delivery
per packet
 Unreliable transport – V1


Proposed extension
Max. number of retransmissions



specified per stream
0 is legal
Ordered and unreliable is possible
 Unreliable transport – V2


Proposed extension
Sender demands ACKs


Receiver must ACK
Even if packets were not received
 Unreliable, unordered, implicitly TCP-friendly transport protocol
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
Datagram Congestion Control Protocol (DCCP)
 Datagram Congestion Control Protocol
 Under development
 http://www.ietf.org/html.charters/dccp-charter.html
 Transport Protocol
 Offers unreliable delivery
 Low overhead like UDP
 Applications using UDP can easily change to this new protocol
 Accommodates different congestion control

Congestion Control IDs (CCIDs)




Add congestion control schemes on the fly
Choose a congestion control scheme
TCP-friendly Rate Control (TFRC) is included
Half-Connection

Data Packets sent in one direction
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
Datagram Congestion Control Protocol (DCCP)
 Congestion control is plugable
 One proposal is TCP-Friendly Rate Control (TFRC)



Equation-based TCP-friendly congestion control
Receiver sends rate estimate and loss event history
Sender uses models of SACK TCP to compute send rate
Steady state TCP
send rate
Loss probability
1
T
RTT
2bp
3bp
 tRTO min( 1,3
) p(1  32 p 2 )
3
8
Retransmission timeout
INF5070 – media storage and distribution systems
Number of packets ack’d by
one ACK
2003 Carsten Griwodz & Pål Halvorsen
Selective Retransmission-RTP (SR-RTP)
 Features
 Relies on a layered video codec
 Supports selective retransmission
 Uses congestion control to choose number of video layers
 Congestion Manager
 Determines the permitted send rate at the sender
 Uses TCP-friendly algorithm for rate computation
 Knowledge about encoding
 Required at sender to select video layers to send
 Required at receiver to


decode at correct rate
send NAKs
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
Selective Retransmission-RTP (SR-RTP)
MPEG-4 server
Transmission schedule of
a layered video
Decoder
Update allowed
Bandwidth
for stream
Smoothing buffer
RTCP report
Includes loss information
SR-RTP
SR-RTP
RTCP
RTCP
UDP Stack
Retransmission demand UDP Stack
Congestion
Manager
Forwarding to the
Congestion Manager
Network
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
Selective Retransmission-RTP (SR-RTP)
 Binomial Congestion Control
 Provides a generalization of TCP AIMD
Increase
wt  RTT  wt  
Decrease
k
t
w
,  0
wt  RTT    wtl ,0    1

Congestion window size wt depends on losses per RTT

Choose  and  in such a way that k=0, l=1
would result in TCP’s AIMD



Time to find sending rate is controlled by  and 
Target sending rate is determined by k and l
If k+l=1, binomial congestion control is TCP friendly
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
Selective Retransmission-RTP (SR-RTP)
 SQRT
 Special case of binomial congestion control
 k=0.5, l=0.5
 Name because w0.5 = sqrt(w)
AIMD
SQRT
AIMD
 Effect of SQRT
 Average bandwidth is like TCP’s
 Maximum is lower
 SQRT covers a step function with
less steps
INF5070 – media storage and distribution systems
SQRT
2003 Carsten Griwodz & Pål Halvorsen
Signaling Protocols
Signaling Protocols
 Applications differ:
 media delivery controlled by sender or receiver
 sender and receiver “meet” before media delivery
 Signaling should reflect different needs
 media-on-demand:



Internet telephony and conferences:



receiver controlled delivery of content
explicit session setup
bi-directional data flow, live sources
(mostly) explicit session setup, mostly persons at both ends
Internet broadcast


sender announces multicast stream
no explicit session setup
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
Real-Time Streaming Protocol (RTSP)
 Internet media-on-demand
 select and playback streaming media from server
 similar to VCR, but





potentially new functionality
integration with Web
security
varying quality
need for control protocol

start, stop, pause, …
 Control protocol from MPEG committee
 RTSP is also usable for
 Near video-on-demand (multicast)
 Live broadcasts (multicast, restricted control functionality)
 ...
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
RTSP Approach
 In line with established Internet protocols
 Similar to HTTP 1.1 in style
 Uses URLs for addressing:
rtsp://video.server.com:8765/videos/themovie.mpg
 Range definitions
 Proxy usage
 Expiration dates for RTSP DESCRIBE responses
 Other referenced protocols from Internet (RTP, SDP)
 Functional differences from HTTP
 Data transfer is separate from RTSP connection




typically via RTP
unlike “HTTP streaming”
Server maintains state – setup and teardown messages
Server as well as clients can send requests
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
RTSP Features
 Rough synchronization
 Media description in DESCRIBE response
 Timing description in SETUP response
 Fine-grained through RTP sender reports
 Aggregate and separate control of streams possible
 Virtual presentations
 Server controls timing for aggregate sessions
 RTSP Server may control several data (RTP) servers
 Load balancing through redirect at connect time
 Use REDIRECT at connect time
 Caching
 Only RTSP caching so far
 Data stream caching is under discussion
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
RTSP Methods
OPTIONS
CS
CS
determine capabilities of server/client
DESCRIBE
CS
get description of media stream
ANNOUNCE
CS
announce new session description
SETUP
CS
create media session
RECORD
CS
start media recording
PLAY
CS
start media delivery
PAUSE
CS
pause media delivery
REDIRECT
CS
redirection to another server
TEARDOWN
CS
immediate teardown
SET_PARAMETER
CS
change server/client parameter
GET_PARAMETER
CS
read server/client parameter
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
RTSP Operation
 Integration with other real-time and multimedia protocols
HTTP
server
RTSP
server
data
source
RTSP SETUP
RTSP OK
RTSP PLAY
RTSP OK
RTSP TEARDOWN
RTSP OK
RTP VIDEO
RTP AUDIO
media server
INF5070 – media storage and distribution systems
RTSP
plug-in
AV
subsystem
web browser
2003 Carsten Griwodz & Pål Halvorsen
The End:
Summary
Summary
 Non-QoS protocols:
 Transport level protocols




Application layer protocols



UDP
TCP
...
RTP
...
Signaling protocols

RTSP
 Next time, we look at protocols supporting QoS
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
Some References
1.
2.
3.

Charles Krasic, Jonathan Walpole, Wu-chi Feng: "Quality-Adaptive Media Streaming by Priority Drop", 13th
International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV
2003), June 2003
Charles Krasic, Jonathan Walpole: "Priority-Progress Streaming for Quality-Adaptive Multimedia", ACM
Multimedia Doctoral Symposium, Ottawa, Canada, October 2001
Kurose, J.F., Ross, K.W.: “Computer Networking – A Top-Down Approach Featuring the Internet”, 2nd ed.
Addison-Wesley, 2003
The RFC repository maintained by the IETF Secretariat can be found at
http://www.ietf.org/rfc.html
The following RFCs might be interesting with respect to this lecture:








RFC
RFC
RFC
RFC
RFC
RFC
RFC
RFC
793:
2988:
768:
2481:
1889:
1890:
2960:
2326:
Transmission Control Protocol
Computing TCP's Retransmission Timer
User Datagram Protocol
A Proposal to add Explicit Congestion Notification (ECN) to IP
RTP: A Transport Protocol for Real-Time Applications
RTP Profile for Audio and Video Conferences with Minimal Control
Stream Control Transmission Protocol
Real Time Streaming Protocol
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
Appendix
Session Initiation Protocol (SIP)
 Lightweight generic signaling protocol
 Internet telephony and conferencing
 call: association between number of participants
 signaling association as signaling state at endpoints (no
network resources)
 several “services” needed





Name translation
User location
Feature negotiation
Call control
Changing features
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
SIP Basics
 call user
 re-negotiate call parameters
 forwarding (manual and automatic)
 call center
 supports personal mobility (change of terminal)

through proxies or redirection
 terminate / transfer calls
 ASCII (readable) protocol – SIP vs. H.323


similarities (request/response, proxies ...)
differences (server state, server may initiate actions ...)
 control, location and media description (via SDP)
 extensible towards

usage for IP-IP, POTS-IP, inter-gateway interaction with firewalls, billing system,
...
 Different modes


proxy mode
redirect mo
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
1. Invite u@domain
7. OK
location server
3. user@host
Site A
2. Where?
SIP Operation – Proxy Mode
5. “Ring”
4. Invite user@host
6. OK
9. ACK user@host
User with
“symbolic name”
calls another
8. ACK u@domain
Proxy Mode 10. OK
Site B
11. OK
 Proxy forwards requests
 possibly in parallel to several hosts
 cannot accept or reject call
 useful to hide location of callee
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
1. Invite u@domain1
4. Moved temporarily
Location: user@domain2
User with
“symbolic name”
calls another
location server
3.domain2
Site A
2. Where?
SIP Operation – Redirect Mode
Redirect Mode
5. ACK u@domain1
7. “Ring”
6. Invite user@domain2
7. OK
8. ACK user@domain2
Site B
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen
SIP – Methods
 Basic Methods (RFC 2543):
TABLE
 Additional Methods (partially standardized):
 INFO: carry information between User Agents
 REFER: ask someone to send an INVITE to another
participant
 SUBSCRIBE: request to be notified of specific event
 NOTIFY: notification of specific event
INF5070 – media storage and distribution systems
2003 Carsten Griwodz & Pål Halvorsen