INF 5070 Media Storage and Distribution Systems

INF 5070 – Media Storage and Distribution Systems: Protocols without Qo. S Support 22/9 - 2003

Overview Non-Qo. S protocols: ü Transport level protocols ü Application layer protocols ü Signaling protocols INF 5070 – 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 INF 5070 – 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 Qo. S-support) Ø Time-stamped packets (encoding) Ø Multiplexing (encoding, server, network) Ø Buffering (client) Ø Smoothing (server) INF 5070 – media storage and distribution systems 2003 Carsten Griwodz & Pål Halvorsen

Qo. S vs. Non–Qo. S Approaches ü Internet without network Qo. S support Ø Internet applications must cope with networking problems n n n 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 Qo. S support Ø Application must specify their needs Ø Internet infrastructure must change – negotiation of Qo. S parameters Ø Routers need more features n n n Keep Qo. S-related information Identify packets as Qo. S-worthy or not Treat packets differently keep routing consistent INF 5070 – media storage and distribution systems 2003 Carsten Griwodz & Pål Halvorsen

Protocols for Non–Qo. S Approaches Application Layer Transport Layer Network Layer Complete freedom ü Compatibility is an application issue TCP/IP Protocol stack ü Has Limitedlayers only 4 flexibility ü UDP ü IP isü TCP central ü Nothing must compete with IP at the ü New developments network layer No flexibility ü There is no Qo. S support ü IPv 4 ü Routing. IPv 6 ü is transparent for the application ü Transport-unrelated functions are Physical Layer INF 5070 – 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 ü Connection-less ü Unreliable ü Unordered ü Datagram-oriented ü Uncontrolled ü Optionally checksummed INF 5070 – media storage and distribution systems ü Often used in multimedia streaming applications – can build whatever needed on top ü Simple Ø add pseudo-header Ø calculate checksum Ø finish header Ø send to IP ü 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. . . Ø Ø Ø INF 5070 – 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 Estimated. RTT = (1 - ) * Estimated. RTT + * Sample. RTT usually, = 0. 125 [RFC 2988] Initially, Estimated. RTT is based on packets sent during “handshake” operation (connection setup), e. g. , 3 The following RTTs are calculated using the formula above taking one Sample. RTT each round: - going slightly up if Estimated. RTT < Sample. RTT - going slightly down if Estimated. RTT > Sample. RTT - e. g. ( = 0. 5 ): round 3 2) Estimated. RTT =. 5 * 3 +. 5 * 3 = 3 3) Estimated. RTT =. 5 * 3 +. 5 * 5 = 4 round 4 4) Estimated. RTT =. 5 * 4 +. 5 * 1 = 2. 5 NOTE: the next RTT is not necessarily ready RTT before the corresponding 6 5 round starts (and we start 4 sending the next packets) 3 2 1 INF 5070 – media storage and distribution systems time 2003 Carsten Griwodz & Pål Halvorsen

TCP Timeout ü The Estimated. RTT is used for the retransmission timer – timeout interval should be Ø Ø Ø ≥ estimated. RTT – 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: Dev. RTT = (1 - ) * Dev. RTT + * | Sample. RTT – Estimated. RTT |, usually, = 0. 25 ü Retransmission interval given by Timeout. Interval = Estimated. RTT + 4 * Dev. RTT ü Modifications Ø timeout interval doubling each timeout (form of congestion control) Ø fast retransmission – three duplicate ACKs (decrease delay) INF 5070 – 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 INF 5070 – 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 INF 5070 – 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 time INF 5070 – media storage and distribution systems 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 INF 5070 – 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 INF 5070 – 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 n n ECT - ECN Capable Transport, set by sender CE - Congestion Experienced, may be set by router ü Extends RED Ø if packet has ECT bit set n n n Ø ECN node sets CE bit TCP receiver sets ECN bit in ACK sender applies multiple decrease (AIMD) else n Act like RED INF 5070 – media storage and distribution systems 2003 Carsten Griwodz & Pål Halvorsen

Early Congestion Notification (ECN) ü Effects Ø Congestion is not oscillating - RED & ECN Ø ECN-packets are never lost on uncongested links Ø Receiving an ECN mark means n n n TCP window decrease No packet loss No retransmission INF 5070 – media storage and distribution systems 2003 Carsten Griwodz & Pål Halvorsen

TCP Friendliness A TCP connection’s throughput is bounded The TCP send rate limit is ü wmax - maximum retransmission window size ü RTT - round-trip time Congestion windows size changes ü AIMD algorithm ü additive increase, multiple In case of at least one loss in an RTT In case of no loss , 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 INF 5070 – 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 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) INF 5070 – media storage and distribution systems 2003 Carsten Griwodz & Pål Halvorsen

Comparison of Non-Qo. S 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, quasi-broadcasting, conferencing INF 5070 – 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 (Open. Div. X) DCCP VDP Video Datagram Protocol Research, for Vosaic MSP Media Streaming Protocol Research, UIUC INF 5070 – 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 Qo. S feedback and session information INF 5070 – 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 ü Integrated with applications ü RTP follows principles of Ø Application Level Framing and Ø Integrated Layer Processing INF 5070 – media storage and distribution systems 2003 Carsten Griwodz & Pål Halvorsen

RTP Control Protocol (RTCP) ü Companion protocol to RTP (tight integration with RTP) Ø Monitoring n n Ø Feedback to members of a group about delivery quality, loss, etc. n n Ø Sources may adjust data rate Receivers can determine if Qo. S problems are local or network-wide Loose session control n n Ø of Qo. S of application performance Convey information about participants Convey information about session relationships Automatic adjustment to overhead n report frequency based on participant count ü Typically, “RTP does. . . ” means “RTP with RTCP does. . . ” INF 5070 – media storage and distribution systems 2003 Carsten Griwodz & Pål Halvorsen

RTP ü RTP services are: Ø Sequencing Ø Synchronization Ø Payload identification Ø Qo. S 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 Ø Qo. S provision or reservation INF 5070 – 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) INF 5070 – 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 k. Hz, other rates possible INF 5070 – 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 n n Ø Particular codecs with additional requirements Payload formats defined for each codec: syntax and semantic of RTP payload Payload types n n static: RTP AV profile document dynamic: agreement on per-session basis ü Profiles and Payload Formats in RTP Framework INF 5070 – media storage and distribution systems 2003 Carsten Griwodz & Pål Halvorsen

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) INF 5070 – 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 INF 5070 – 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 7 bit payload type Allows identification of the payload’s content type Marker bit Meaning depends on payload profile, e. g. frame boundary 4 bit CSRC count, indicates the number of contributing sources in the header INF 5070 – 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 Several 32 bit CSRC Contribution source identifier, the number is indicated by CC A mixer copies the original sources’ SSRCs here INF 5070 – 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 AAL 5 n do-it-yourself packaging ü Header extensions for payload specific fields possible Ø specific codecs Ø error recovery mechanisms INF 5070 – media storage and distribution systems 2003 Carsten Griwodz & Pål Halvorsen

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” with several items like canonical names, email, location, . . . ) Ø BYE explicit leave Ø APP extensions, application specific INF 5070 – media storage and distribution systems 2003 Carsten Griwodz & Pål Halvorsen

RTCP Sender / Receiver Reports ü Sender report Ø Sender Information n n Ø Timestamps (RTP, NTP) Packet Count, Byte Count List of statistics per source heard (receiver reports) ü Receiver report Ø for each source: n n loss statistics inter-arrival jitter timestamp of last SR delay between reception of last SR and sending of RR ü Analysis of reports Ø cumulative counts for short and long time measurements Ø NTP timestamp for encoding- and profile independent monitoring INF 5070 – media storage and distribution systems 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 n n Ø Ø 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 INF 5070 – media storage and distribution systems 2003 Carsten Griwodz & Pål Halvorsen

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 INF 5070 – media storage and distribution systems 2003 Carsten Griwodz & Pål Halvorsen

RTP Identifiers SSRC chosen by sender S 1 SSRC chosen by mixer M 1 S 3 S 3: 19 S 1: 10 M 1 S 2: 1 M 1: 33 (10, 1) T 1 S 4: 13 R 1 M 2: 17 (19, 13, 33) S 4: 13 S 2 S 4 Translators keep SSRCs and CSRCs from mixed sources S 1 and S 2 CSRCs contain previous SSRCs, but not previous CSRCs INF 5070 – 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 INF 5070 – 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 n n Ø For very low-bit-rate codecs For very loss-intolerant codecs Practical n All low-volume web servers INF 5070 – media storage and distribution systems 2003 Carsten Griwodz & Pål Halvorsen

Progressive Download Web server Backpressure ! Decoder Receive buffer TCP Stack Can recreate timing from media file Accepts buffer underruns Serves requested files as quickly as possible Network (uncongested) INF 5070 – media storage and distribution systems 2003 Carsten Griwodz & Pål Halvorsen

Progressive Download Web server Retransmission Timeout Decoder Receive buffer TCP Stack Network (congested) INF 5070 – 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 n Ø Assign priorities to SPEG packets n Ø 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 n n Total delay is increased High priority packets win more often INF 5070 – media storage and distribution systems 2003 Carsten Griwodz & Pål Halvorsen

Priority Progress Streaming Packets to send High priority Medium priority Low priority Progress Queue INF 5070 – 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) ü 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 INF 5070 – 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) ü 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 INF 5070 – media storage and distribution systems 2003 Carsten Griwodz & Pål Halvorsen

Receiver-driven Layered Multicast (RLM) INF 5070 – 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 n n Ø Small layers n n n Ø 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 n n Bad enough Best possible mix ü Other problems Ø Ø Synchronization problems PIM-SM removes sub-trees quickly n Join and leave operations are very slow INF 5070 – media storage and distribution systems 2003 Carsten Griwodz & Pål Halvorsen

Receiver-driven Layered Multicast (RLM) INF 5070 – media storage and distribution systems 2003 Carsten Griwodz & Pål Halvorsen

Stream Control Transmission Protocol (SCTP) ü Stream Control Transmission Protocol Ø RFC 2960, IETF Standards Track & SCTP Unreliable Data Mode Extension (draft-ietf-tsvwg-usctp-00. txt) Ø Features n n n Connection-oriented Message-oriented Reliable (with extension also: unreliable, partially reliable) Fully ordered, unordered, partially ordered delivery Multi-homed ü Origin Ø Signaling protocol for SS 7 transport over IP networks Ø Players n Motorola, Cisco, Siemens, Nortel Networks, Ericsson, Telcordia, UCLA, ACIRI INF 5070 – media storage and distribution systems 2003 Carsten Griwodz & Pål Halvorsen

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 INF 5070 – 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 n This prevents delay, not bundling Chunks: ü ü ü ü ü INF 5070 – media storage and distribution systems 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 n n n Ø Ø Arrival is reported by SACK chunks n n Ø per stream in bytes changed per stream as in TCP are piggybacked contain ranges of packets Retransmission n n not before 4 th missing report always before new packets ü Delivery Ø Sender can specify n n unordered delivery per packet ü Unreliable transport – V 1 Ø Proposed extension Ø Max. number of retransmissions n n Ø specified per stream 0 is legal Ordered and unreliable is possible ü Unreliable transport – V 2 Ø Proposed extension Ø Sender demands ACKs n n Receiver must ACK Even if packets were not received ü Unreliable, unordered, implicitly TCP-friendly transport protocol INF 5070 – 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) n n n Ø Add congestion control schemes on the fly Choose a congestion control scheme TCP-friendly Rate Control (TFRC) is included Half-Connection n Data Packets sent in one direction INF 5070 – 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) n n n 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 Retransmission timeout INF 5070 – media storage and distribution systems Loss probability 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 n n decode at correct rate send NAKs INF 5070 – 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 RTCP UDP Stack Retransmission demand UDP Stack Congestion Manager Forwarding to the Congestion Manager Network INF 5070 – 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 Decrease Ø 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 n n Ø 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 INF 5070 – 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 w 0. 5 = sqrt(w) AIMD ü Effect of SQRT Ø Average bandwidth is like TCP’s Ø Maximum is lower Ø SQRT covers a step function with less steps INF 5070 – 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: n n Ø Internet telephony and conferences: n n Ø 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 n n sender announces multicast stream no explicit session setup INF 5070 – 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 n n Ø potentially new functionality integration with Web security varying quality need for control protocol n start, stop, pause, … ü Control protocol from MPEG committee ü RTSP is also usable for Ø Near video-on-demand (multicast) Ø Live broadcasts (multicast, restricted control functionality) Ø. . . INF 5070 – 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 n n Ø Ø typically via RTP unlike “HTTP streaming” Server maintains state – setup and teardown messages Server as well as clients can send requests INF 5070 – 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 INF 5070 – media storage and distribution systems 2003 Carsten Griwodz & Pål Halvorsen

RTSP Methods OPTIONS 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 INF 5070 – media storage and distribution systems 2003 Carsten Griwodz & Pål Halvorsen

RTSP Operation ü Integration with other real-time and multimedia protocols HTTP server HTT pres enta t P GE T ion desc ripti on f RTSP server data source ile RTSP SETUP RTSP OK RTSP PLAY RTSP OK RTSP TEARDOWN RTSP OK RTP VIDEO RTP AUDIO media server INF 5070 – media storage and distribution systems RTSP plug-in AV subsystem web browser 2003 Carsten Griwodz & Pål Halvorsen

The End: Summary

Summary ü Non-Qo. S protocols: Ø Transport level protocols n n n Ø Application layer protocols n n Ø UDP TCP. . . RTP. . . Signaling protocols n RTSP ü Next time, we look at protocols supporting Qo. S INF 5070 – media storage and distribution systems 2003 Carsten Griwodz & Pål Halvorsen

Some References 1. 2. 3. q Charles Krasic, Jonathan Walpole, Wu-chi Feng: "Quality-Adaptive Media Streaming by Priority Drop", 13 th 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”, 2 nd 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: q q q q 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 INF 5070 – 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 n n n Name translation User location Feature negotiation Call control Changing features INF 5070 – 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 INF 5070 – media storage and distribution systems 2003 Carsten Griwodz & Pål Halvorsen

SIP Operation – Proxy Mode ü Proxy forwards requests Ø possibly in parallel to several hosts Ø cannot accept or reject call Ø useful to hide location of callee INF 5070 – media storage and distribution systems 2003 Carsten Griwodz & Pål Halvorsen

SIP Operation – Redirect Mode INF 5070 – 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 INF 5070 – media storage and distribution systems 2003 Carsten Griwodz & Pål Halvorsen