protocols without qos support
Post on 03-Jan-2016
62 Views
Preview:
DESCRIPTION
TRANSCRIPT
ProtocolsProtocolswithout QoS Supportwithout QoS Support
20/9 - 2004
INF 5070 – Media Servers and Distribution Systems:
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
Overview
Non-QoS protocols:
Transport level protocols
Application layer protocols
Signaling protocols
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
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, ...
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
Requirements for Continuous Media
Acceptable continuity
Streams must be displayed in sequence
Streams must be displayed at acceptable, consistent quality
Acceptable synchronity
Intra-media: time between successive packets must be conveyed to receiver
Inter-media: different media played out at matching times
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
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)
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
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 …
o … “adapt to” which must deal with TCP-like service variationso … “don’t care about” which is considered “unfair” and 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
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
TCP/IP Protocol stack Has only 4 layers IP is central Nothing must compete with IP at
the network layer There is no QoS support Routing is transparent for the
application Transport-unrelated functions
are application-layer tasks
Protocols for Non–QoS Approaches
Transport LayerTransport Layer
Application LayerApplication Layer
Network LayerNetwork Layer
Physical LayerPhysical LayerVarious Not a concern
No flexibility – IP is THE protocol IPv4 IPv6
Limited flexibility UDP TCP New developments
Complete freedom Compatibility is an application
issue
Traditional Transport Layer Approaches
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
User Datagram Protocol (UDP) Described in
Internet Engineering Note 88
Request for Comments 768 Internet Standard 6
Connection-less Unreliable Unordered Datagram-oriented Uncontrolled
Optionally checksummed
Often used in multimedia streaming applications – can build whatever needed on top
Simple add pseudo-header (UDP/IP) calculate checksum finish header send to IP
No... ... guarantees ... fairness ...
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
Transmission Control Protocol (TCP)
Described in Internet Engineering Note 2 Request for Comments 793 Internet Standard 7
Connection-oriented Reliable Ordered Stream-oriented Flow-controlled Checksummed
Complex compared to UDP
High fraction of today’s traffic is TCP-based, e.g., electronic mail web file transfers ...
We need to know some details about the TCP behavior/traffic we’ll briefly look at TCP ... ...retransmission timeouts ...congestion control ...friendliness
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
TCP Round Trip Time EstimationEstimatedRTT = (1 - ) * EstimatedRTT + * SampleRTT
usually, = 0.125 [RFC 2988]
sender receiver
Initially, EstimatedRTT is based on packets sent during “handshake” operation (connection setup), e.g., 3
rou
nd
1
The following RTTs are calculated using the formula abovetaking one SampleRTT each round: - going slightly up if EstimatedRTT < SampleRTT - going slightly down if EstimatedRTT > SampleRTT - e.g. ( = 0.5 ):
2) EstimatedRTT = .5 * 3 + .5 * 3 = 3
3) EstimatedRTT = .5 * 3 + .5 * 5 = 4
4) EstimatedRTT = .5 * 4 + .5 * 1 = 2.5
RTT6543
21
time
rou
nd
2ro
un
d 3
rou
nd
4
NOTE: the next RTT isnot necessarily ready before the corresponding round starts (and we startsending the next packets)
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
TCP Retransmission 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 byTimeoutInterval = EstimatedRTT + 4 * DevRTT
Modifications timeout interval doubling each timeout (form of congestion
control) fast retransmission – three duplicate ACKs (decrease delay)
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
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
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
TCP Congestion Control sender receiver Initially, the CONGESTION
WINDOW is 1 MSS (message segment size)
rou
nd
1ro
un
d 2
rou
nd
3ro
un
d 4
sent packetsper round(congestion window)
time
16
8
4
2
1
Then, the size increases by 1 for each received ACK (until a threshold is reached or an ACK is missing)
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
TCP Congestion Control
16
8
4
2
1
Normally, the threshold is 65 K
sent packetsper round
(congestion window)
time
40
20
10
5
80
15
30
25
35
75
55
45
50
65
60
70
Losing a single packet (TCP Tahoe): threshold drops to halve CONGESTION WINDOW CONGESTION WINDOW back to 1Losing a single packet (TCP Reno): threshold drops to halve CONGESTION WINDOW CONGESTION WINDOW back to new threshold
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
TCP Congestion Control Alternatives
Why alternatives? Improve throughput and variance
Early TCP implementations did little to minimize network congestion
Loss indication forces setting new congestion window threshold to half of the last congestion window size
But …o … what else to conclude from the loss?o … which packets to retransmit?
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
TCP Congestion Control Alternatives
Original TCP not in use
TCP Tahoe TCP Reno TCP New-Reno
standard TCP headers
TCP SACK (Selective Acknowledgements) TCP FACK (Forward Acknowledgements)
must use a TCP option RFC 2018 “TCP Selective Acknowledgment Options”
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
TCP Congestion Control Alternatives• TCP/IP Header Format for TCP Tahoe, Reno and New Reno
Destination AddressSource address
Time to live Protocol Header checksumIdentification DM Fragment offset
Version IHL Type of service Total lengthPRE ToS
Data
OptionsSource port Destination port
Sequence numberPiggyback acknowledgement
THL
THL – TCP header lengthU: URG – urgentA: ACK – acknowledgementP: PSH – pushR: RST – resetS: SYN – syncF: FIN – finalize
F Advertised windowSRPAUunusedChecksum Urgent pointer
IP header
TCP header
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
THL F Advertised windowSRPAUunused
TCP Congestion Control Alternatives
• TCP/IP Header Format for TCP SACK and FACK
Destination AddressSource address
Time to live Protocol Header checksumIdentification DM Fragment offset
Version IHL Type of service Total lengthPRE ToS
Data
OptionsSource port Destination port
Sequence numberPiggyback acknowledgement
Checksum Urgent pointer
IP header
TCP header
5 SACK opt. len. Left edge 1st block, bits 31-16Left edge 1st block, bits 15-0Right edge 1st block, bits 31-16
Right edge 1st block, bits 15-0Left edge 2nd block, bits 31-16Left edge 2nd block, bits 15-0
Right edge last block, bits 15-0
……
5 SACK opt. len.Left edge 1st block
Right edge 1st block
Right edge last block…
Left edge: first sequence number of a block of received packet after a lostpacket
Right edge: first sequence number AFTERthat block
Only 40 bytes TCP options allowed, therefore never more than 4 blocks reported at once
Sequence number of packet that triggered ACK must be in first block unless it is in the sequence number field
Always use as many blocks as possible
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
TCP Congestion Control Alternatives
Feature Original TCP
Tahoe RenoNew-Reno
SACK FACK
Retransmission strategy
Go back-n
Retransmit lost packet, continue after last sent
By SACK blk
Slow start No Yes Yes Yes Yes Yes
Congestion avoidance
No Yes Yes Yes Yes Yes
Fast retransmit
No Yes Yes Yes Yes Yes
Fast recovery
No No Yes (3 duplicate ACKs)
Stay in f. rec. No No No Yes Yes
Consider gaps
In flight packet estimation
By TCP sequence number By 1st SACK blk
Cong. window halving
Immediately Linear decrease
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
Simulation results
Sequence number development
0
100
200
300
400
500
600
700
800
900
1000
0 5 10 15 20Time (s)
Seq
uenc
e nu
mbe
r (s
egm
ent n
umbe
r)
TCP New Reno
SACK TCP
FACK TCP
Lossy transfer with small delays (link: 500kbps, 105ms delay):
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
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 can enable features like
quality adaptation
Use active queue management to detect congestion
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
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
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
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
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
Early Congestion Notification (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
Tail drop
RED
ECN
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
TCP Friendliness
RTT
wRs
max
A TCP connection’s throughput is bounded
wmax - maximum retransmission window size
RTT - round-trip time
The TCP send rate limit is
21, ww
In case of loss in an RTT:
In case of no loss:
1, ww
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
That’s not generally true Bigger RTT
higher loss probability per RTT slower recovery
Disadvantage for long-distance traffic
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
TCP Friendliness A protocol is TCP-friendly if
Colloquial: It long-term averagethroughput is not bigger than TCP’s
Formal: Its arrival rate is at mostsome constant over the square rootof the packet loss rate
Thus, if the rule is not violated …
… the AIMD algorithm with ≠ 1/2 and ≠ 1 is still TCP-friendly
… TCP-friendly protocols may 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)
CpRr P – packet loss rate
C – constant value
Rr – packet arrival rate
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
Comparison of Non-QoS Philosophies
Pro UDP Pro TCPScalable due to multicast Proxies, caches and reflectors
are beneficial anyway, can replace multicast
ISPs dislike multicast
Fasteronly one end-to-end delay for packet delivery
Existing optimization is for TCProuters, firewall, OS network stacks
Application controls retransmission No need to handle retransmissions
Scalable codecs are needed anyway Losslesscodecs don’t need additional loss resistance
Small buffers possibleif loss is handled gracefully
TCP-friendlinesscan be implemented (end-to-end)
variations of the algorithm possible
TCP-friendly without additional work
Works through firewalls
One-fits-all protocol possibleon-demand, quasi-broadcasting, conferencing
Most applications are on-demand
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
Using Standard Protocols
Over UDP Over TCPAlternative Transport
RTPReal Time Protocol
IETF std, supported by ITU-T & Industry
RTP in RTSP over TCPstandardized worst-case
fallbackfirewall-friendly
SCTPStream Control Transmission
ProtocolIETF RFC, supported by
telephone industry
RLMTCP-friendly, needs fine-
grained layered video"Progressive Download" or
"HTTP Streaming"application-level prefetching
and bufferingtrivial, cheap, firewall-friendly
DCCPDatagram Congestion Control
ProtocolIETF RFC, driven by TCP-friendliness researchers
SR-RTPTCP-friendly with RTP/UDP
needs special encoding (OpenDivX)
VDPVideo Datagram Protocol
Research, for Vosaic
Priority Progress Streamingneeds special encoding
needs special routers for ’multicast’
PRTP-ECNPartially reliable transport
protocol using ECNResearch, Univ. Karlstad
MSPMedia Streaming Protocol
Research, UIUC
RTP: An Application Layer Approach
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
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
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
Real-time Transport Protocol (RTP) No premise on underlying
resources layered above transport
protocol no reservation / guarantees
Integrated with applications
RTP follows principles of Application Level
Framing and
Integrated Layer Processing
UDP
IPv4/6
EthernetAAL5ATM
ST-2
RTP RTCP
mediaencapsulation
application
TCP
ATM
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
RTP Control Protocol (RTCP) Companion protocol to RTP (tight integration with RTP)
Monitoring of QoS of application performance
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 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 ...”
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
RTP RTP services are:
Sequencing Synchronization Payload identification QoS feedback and session information …
RTP supports Multicast in a scalable way Mixers and translators to adapt to bandwidth limitations Generic real-time media and changing codecs on the fly Encryption
RTP is not designed for: Reliable delivery QoS provision or reservation
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
RTP Quality Adaptation
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)
Application
RTCP RTP
Decoding
Application
UDP/IP UDP/IP
RTCPRTP
Encoding
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
RTP Packet Format
Typical IETF RFC bit-exact representation
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, ...) || .... |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
a byte
a longword (32 bit)
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
RTP Packet Format
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, ...) || .... |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Header extension bitTrue if header extension is
present
Version number, always 2Padding indicator bit
if set, number of padding bytes is in last byte of payload
4 bit CSRC count, indicates the number of contributing sources in the header
Marker bitMeaning depends on payload
profile, e.g. frame boundary
7 bit payload typeAllows identification of the payload’s
content type
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
RTP Packet Format
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, ...) || .... |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 bit sequence number(ordering and loss
detection)
Several 32 bit CSRCContribution source identifier, the number is
indicated by CCA mixer copies the original sources’ SSRCs
here
32 bit timestamp (synchronization)
32 bit SSRCSynchronization source identifier, a random
number identifying the senderHeader extension, multiples of
32 bit
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
RTP Packet Format Relatively long header (>40 bytes)
large overhead when carrying small payloads 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, if do-it-yourself packaging
Header extensions for payload specific fields possible specific codecs error recovery mechanisms
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
RTCP Packets
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” withseveral items like canonical names, email,
location,...)
BYE explicit leave
APP extensions, application specific
R SR / RR BYESDES APP
Compound (UDP) Packet
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
RTP Mixer
Mixes reconstructed streams into a single stream
Reconstructs constant spacing generated by sender
Resynchronizes incoming 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 for example in conference bridges
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
RTP 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
ATM UDP
ProtocolTranslator
MPEGSource
MPEGSink
H.263Sink
ProfileTranslator
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
RTP Identifiers
S1 S3
S2 S4
M1 M2T1 R1
S1:10
S2:1
M1:33 (10,1)
M1:33 (10,1)
S4:13
S4:13
S3:19
M2:17 (19,13,33)
SSRC chosen by sender S1
Translators keep SSRCs and CSRCs
SSRC chosen by mixer M1
CSRCs from mixed sources S1 and S2
CSRCs contain previous SSRCs, but not previous CSRCs
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
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
Other Application Layer Approaches
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
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
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
Progressive Download
TCP Stack TCP Stack
Decoder
Receive buffer
Web server
Network (uncongested)
Backpressure !
Serves requested files as quickly as possible
Can recreate timing from media file
Accepts buffer underruns
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
Progressive Download
TCP Stack TCP Stack
Decoder
Receive buffer
Web server
Network (congested)
Retransmission
Timeout
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
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
More variations conceivable: color, resolution Assign priorities to SPEG packets
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
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
Priority Progress Streaming
Smoothing buffer
MPEG decoderViewer
TransparentOS Issues
TCP Net
bottlenecksslow TCP down
TCP
SPEG transcoderbuffer size to accountfor priority reordering& TCP backpressure
Priority Progess Queue
SPEG transcoder
MPEG file
Priority MapperTiming Generator
High priority
Medium priority
Low priorityTo TCP
Priority Progress Queue
Packets to send
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
Receiver-driven Layered Multicast (RLM)
Requires IP multicast layered video codec
(preferably exponential thickness)
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
Sender
Router
Receiver
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
Receiver-driven Layered Multicast (RLM)
Requires IP multicast layered video codec
(preferably exponential thickness)
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
Sender
Router
Receiver
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
Receiver-driven Layered Multicast (RLM)
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
Receiver-driven Layered Multicast (RLM)
Layer size considerations Adaptations are in steps of 1 layer Big layers
Join experiments have huge impact Quality changes are very visible
Small layers 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
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
Receiver-driven Layered Multicast (RLM)
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
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
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
Stream Control Transmission Protocol (SCTP)
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
Association
This side is dual-homed
Streams
Association endpoints
Stream to idle destination addressOnly HEARTBEAT messages
Stream to active destinationaddress
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
Stream Control Transmission Protocol (SCTP)
SCTP packets Consist of one or more chunks Chunks are bundled automatically
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 /\ \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunks: DATA SACK INIT ABORT SHUTDOWN HEARTBEAT ERROR ECNE CWR & responses
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
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
per stream in bytes changed per stream as in TCP
Arrival is reported by SACK chunks
SACK chunks 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
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
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
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
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
)321()83
3,1min(32
1
2ppbp
tbp
RTT
T
RTO
Steady state TCP send rate Loss
probability
Number of packets ack’d by one ACK
Retransmission timeout
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
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
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
Selective Retransmission-RTP (SR-RTP)
UDP Stack UDP Stack
Decoder
Smoothing buffer
MPEG-4 server
Network
SR-RTPRTCP
SR-RTPRTCP
CongestionManager
RTCP reportIncludes loss information
Forwarding to theCongestion Manager
Update allowedBandwidthfor stream
Transmission schedule ofa layered video
Retransmission demand
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
Selective Retransmission-RTP (SR-RTP)
Binomial Congestion Control Provides a generalization of TCP AIMD
Congestion window size wt depends on losses per RTT
TCP’s AIMD: = 1, = .5, k = 0 and l = 1
k + l = 1: binomial congestion control is TCP friendly
0, kt
tRTTt www
Increase
10, ltRTTt ww
Decrease
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
Selective Retransmission-RTP (SR-RTP)
AIMD
SQRT
SQRT Special case of binomial congestion
control k=0.5, l=0.5 Name because w0.5 = sqrt(w)
Effect of SQRT Average bandwidth is like TCP’s Maximum is lower SQRT covers a step function with
less steps
AIMD
SQRT
Signaling Protocols
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
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:
receiver controlled delivery of content explicit session setup
Internet telephony and conferences: 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
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
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) ...
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
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
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
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 (stream state) so far Data stream caching is under discussion
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
RTSP Methods
OPTIONSC S
determine capabilities of server/clientC S
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
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
media server
RTSP Operation Integration with other real-time and multimedia
protocols
HTTPserver
RTSPserver
datasource
web browser
AVsubsystem
RTSPplug-in
HTTP GETpresentation description file
RTSP SETUPRTSP OK
RTSP PLAYRTSP OK
RTP AUDIO
RTP VIDEO
RTSP TEARDOWNRTSP OK
The End:Summary
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
Summary
Non-QoS protocols: Transport level protocols
UDP TCP ...
Application layer protocols RTP Priority progress streaming RLM DCCP ...
Signaling protocols RTSP
Next time, we look at protocols supporting QoS
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
Some References1. 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
2. Charles Krasic, Jonathan Walpole: "Priority-Progress Streaming for Quality-Adaptive Multimedia", ACM Multimedia Doctoral Symposium, Ottawa, Canada, October 2001
3. 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.htmlThe following RFCs might be interesting with respect to this lecture:
RFC 793: Transmission Control Protocol RFC 2988: Computing TCP's Retransmission Timer RFC 768: User Datagram Protocol RFC 2481: A Proposal to add Explicit Congestion Notification (ECN) to IP RFC 1889: RTP: A Transport Protocol for Real-Time Applications RFC 1890: RTP Profile for Audio and Video Conferences with Minimal Control RFC 2960: Stream Control Transmission Protocol RFC 2326: Real Time Streaming Protocol
Appendix
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
Partially Reliable Transport Protocol using Early Congestion Notification (PRTP-ECN)
Research Nearly TCP-friendly Receiver-only extension to TCP
Media streaming applications can accept some packet loss Media streaming applications prefer small delay and jitter
TCP
WebServer
serves files as
Net TCP
quickly as possible
prefetchbuffer
decoder
viewer
if full, stop reading(TCP backpressure)
application specifiesacceptablelevel of loss
in case of lossacknowledge receiptbut set ECN mark
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
Partially Reliable Transport Protocol using Early Congestion Notification (PRTP-ECN)
PRTP-ECN is nearly TCP-friendly PRTP-ECN sender applies AIMD exactly like TCP On an unloaded link
All packets arrive the receiver PRTP-ECN behaves like TCP
Some retransmissions are prevented Send window is less frequently filled More frequent claiming of the share Higher goodput (effective throughput)
Note This receiver manipulation has been used before
PRTP-ECN is its friendly use TCP-Daytona is the unfriendly use It does not set the ECN mark The result is a TCP stack for denial-of-service attacks
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
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
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
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
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
SIP Operation – Proxy Mode
Proxy forwards requests possibly in parallel to several hosts cannot accept or reject call useful to hide location of callee
location server
Site A
User with
1. Invite u@domain
7. OK
“symbolic name”8. ACK u@domain
11. OK
2. W
he
re?
3. u
ser
@h
os
t
Site B
4. Invite user@host
6. OK
5. “Ring”
calls another
9. ACK user@host
10. OKProxy Mode
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
SIP Operation – Redirect Mode
location server
Site A
User with
1. Invite u@domain1
4. Moved temporarily
“symbolic name”
5. ACK u@domain1
2. W
her
e?
3.d
om
ain
2
calls another
Redirect Mode
Site B
6. Invite user@domain2
7. OK
7. “Ring”
8. ACK user@domain2
Location: user@domain2
2004 Carsten Griwodz & Pål Halvorsen
INF5070 – media servers and distribution systems
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
top related