INF 5070 Media Servers and Distribution Systems

INF 5070 – Media Servers and Distribution Systems: Protocols without Qo. S Support 19/9 - 2005

Overview Non-Qo. S protocols: q Transport level protocols q Application layer protocols q Signaling protocols INF 5070 – media servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

Requirements for Continuous Media q Acceptable delay Ø Ø q 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, . . . INF 5070 – media servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

Requirements for Continuous Media q Acceptable continuity Ø Ø q 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 INF 5070 – media servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

Basic Techniques q Delay and jitter Ø Ø Ø q Continuity Ø Ø Ø q Reservation (sender, receiver, network) Buffering (receiver) Scaling (sender) 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 servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

Qo. S vs. Non–Qo. S Approaches q Internet without network Qo. S support Ø Internet applications must cope with networking problems n Application itself or middleware n "Cope with" means either … o o q … “adapt to” which must deal with TCP-like service variations … “don’t care about” which is considered “unfair” and 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 Keep Qo. S-related information n Identify packets as Qo. S-worthy or not n Treat packets differently keep routing consistent INF 5070 – media servers and distribution systems 2005 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 – IP is THE protocol ü 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 servers and distribution systems Various application-layer tasks ü Not a concern 2005 Carsten Griwodz & Pål Halvorsen

Traditional Transport Layer Approaches

User Datagram Protocol (UDP) q Described in Ø Ø Ø q q q q Often used in multimedia streaming applications – can build whatever needed on top q Simple Internet Engineering Note 88 Request for Comments 768 Internet Standard 6 Connection-less Unreliable Unordered Datagram-oriented Uncontrolled Optionally checksummed Ø Ø q No. . . Ø Ø Ø INF 5070 – media servers and distribution systems add pseudo-header (UDP/IP) calculate checksum finish header send to IP . . . guarantees. . . fairness. . . 2005 Carsten Griwodz & Pål Halvorsen

Transmission Control Protocol (TCP) q Described in Ø Ø Ø q Internet Engineering Note 2 Request for Comments 793 Internet Standard 7 High fraction of today’s traffic is TCP-based, e. g. , Ø Ø Ø q q q Connection-oriented Reliable Ordered Stream-oriented Flow-controlled Checksummed Ø q We need to know some details about the TCP behavior/traffic we’ll briefly look at TCP. . . Ø Ø q Complex compared to UDP INF 5070 – media servers and distribution systems electronic mail web file transfers. . . Ø . . . retransmission timeouts. . . congestion control. . . friendliness 2005 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 servers and distribution systems time 2005 Carsten Griwodz & Pål Halvorsen

TCP Retransmission Timeout q The Estimated. RTT is used for the retransmission timer – timeout interval should be Ø Ø Ø q ≥ 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 q Retransmission interval given by Timeout. Interval = Estimated. RTT + 4 * Dev. RTT q Modifications Ø Ø timeout interval doubling each timeout (form of congestion control) fast retransmission – three duplicate ACKs (decrease delay) INF 5070 – media servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

TCP Congestion Control q TCP limit sending rate as a function of perceived network congestion Ø Ø q 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 servers and distribution systems 2005 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 threshold ssthresh is reached or an ACK is missing) round 3 16 8 round 4 4 2 1 time INF 5070 – media servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

TCP Congestion Control Normally, the threshold is 65 K Losing a single packet (TCP Tahoe): ü threshold drops to halve CONGESTION WINDOW ü CONGESTION WINDOW back to 1 sent packets per round (congestion window) Losing a single packet (TCP Reno): 80 ü threshold drops to halve CONGESTION WINDOW ü CONGESTION WINDOW back to new threshold 75 70 65 16 60 ssthresh 55 50% 50 45 40 35 8 30 ssthresh 25 20 4 15 2 10 1 5 time INF 5070 – media servers and distribution systems 2005 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 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 servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

TCP Friendliness q A protocol is TCP-friendly if Ø Ø q 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 Thus, if the rule is not violated … Ø … the AIMD algorithm with ≠ 1/2 and ≠ 1 is still TCP-friendly Ø … TCP-friendly protocols may n n 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 servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

TCP Congestion Control Alternatives q Why alternatives? Ø Improve throughput and variance n n n 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 o … what else to conclude from the loss? … which packets to retransmit? INF 5070 – media servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

TCP Congestion Control Alternatives q Original TCP Ø q q q TCP Tahoe TCP Reno TCP New-Reno Ø q q standard TCP headers TCP SACK (Selective Acknowledgements) TCP FACK (Forward Acknowledgements) Ø Ø q not in use must use a TCP option RFC 2018 “TCP Selective Acknowledgment Options” TCP Westwood+ Ø use bandwidth estimate for congestion events INF 5070 – media servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

TCP Congestion Control Alternatives • TCP/IP Header Format for TCP Tahoe, Reno and New Reno Version IHL Type of service PRE To. S Total length Identification DM Fragment offset Time to live Protocol Header checksum Source address Destination Address Options Source port Destination port Sequence number Piggyback acknowledgement THL unused U A P R S F Advertised window Checksum Urgent pointer Data INF 5070 – media servers and distribution systems IP header TCP header THL – TCP header length U: URG – urgent A: ACK – acknowledgement P: PSH – push R: RST – reset S: SYN – sync F: FIN – finalize 2005 Carsten Griwodz & Pål Halvorsen

TCP Congestion Control Alternatives • TCP/IP Header Format for TCP SACK and FACK Version IHL Type of service PRE To. S Total length Identification DM Fragment offset Time to live Protocol Header checksum Source address Destination Address Options Source port Destination port Sequence number Piggyback acknowledgement THL unused U A P R S F Advertised window Checksum Urgent pointer 5 SACK opt. len. Left edge 1 st block, bits 31 -16 Left edge 1 st block, bits 15 -0 Right edge 1 st block, bits 31 -16 Right edge 1 st block, bits 15 -0 Left edge 2 nd block, bits 31 -16 Left edge 2 nd block, bits 15 -0 … … Right edge last block, bits 15 -0 5 Left edge 1 st block Right edge 1 st block … Right edge last block SACK opt. len. IP header Left edge: first sequence number of a block of received packet after a lost packet Right edge: first sequence number AFTER that block Only 40 bytes TCP options allowed, therefore never TCP header at oncemore than 4 blocks reported 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 Data INF 5070 – media servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

TCP Congestion Control Alternatives Feature Original TCP Tahoe New. Reno SACK FACK Retransmission Go back-n strategy Retransmit lost packet, continue after last sent By SACK blk Slow start No Yes Yes Yes Congestion avoidance No Yes Yes Yes Fast retransmit No Yes Yes Yes Fast recovery No No Stay in f. rec. No No Yes (3 duplicate ACKs) Yes Consider gaps In flight packet estimation By TCP sequence number By 1 st SACK blk Cong. window halving Immediately Linear decrease INF 5070 – media servers and distribution systems No 2005 Carsten Griwodz & Pål Halvorsen

Simulation results Lossy transfer with small delays (link: 500 kbps, 105 ms delay): INF 5070 – media servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

TCP Westwood+ q q Very recent Developed for wireless networks with many losses Ø Losses in wireless networks are often non-congestion losses but corruption losses q Side effect Ø Less unfair against long round-trip times q Implemented in Linux q Procedure Ø Ø q TCP Westwood uses ACK packets provide a bandwidth estimate “Faster recovery” Ø After loss indication by a triple-ACK go into faster recovery n Use bandwidth estimate to set new congestion window size and new slow start threshold INF 5070 – media servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

TCP Westwood+ sender receiver Low pass filter for bandwidth estimate: new RTTmin 7 6 5 Westwood ssthresh 4 3 2 DUPACKs INF 5070 – media servers and distribution systems Reno ssthresh 1 time 2005 Carsten Griwodz & Pål Halvorsen

TCP Westwood+ INF 5070 – media servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

TCP Congestion Control q TCP congestion control is based on the notion that the network is a “black box” – congestion indicated by a loss q Sufficient for best-effort applications, but losses might severely hurt traffic like audio and video streams congestion indication can enable features like quality adaptation q Use active queue management to detect congestion INF 5070 – media servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

Random Early Detection (RED) q Random Early Detection (discard/drop) (RED) uses active queue management q Drops packet in an intermediate node based on average queue length exceeding a threshold Ø Ø q 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 servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

Early Congestion Notification (ECN) q 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 q 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 servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

Early Congestion Notification (ECN) q Effects Ø Ø Ø Congestion is not oscillating - RED & 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 servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

XCP – e. Xplicit Congestion Notification q q Protocol for connections with high bandwidthdelay product Routers return explicit feedback to the host Ø Ø q 20 bytes header between IP and TCP Router does not need to know flows Ø Ø TCP XCP IP Link Operation Ø Application The TCP/XCP/IP stack Routers adjust sending speed of hosts continously Adjustments are done by changing headers Host use feedback from routers to change their congestion window Router INF 5070 – media servers and distribution systems Router 2005 Carsten Griwodz & Pål Halvorsen

XCP Header 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Format| Protocol | Length | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Throughput | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delta_Throughput | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reverse_Feedback | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version Format Protocol Length Unused : : : 1 1 (Full header), 2 (Minimal header) Next level protocol (6 for TCP) 20 0 RTT : Round Trip Time as measured from the sender in milliseconds Throughput: The current throughput in bytes/ms in use by the sender Delta_Throughput: The wanted change in throughput wanted by the sender, measured in bytes/second. Reverse_Feedback: The contents of the Delta_Throughput field when the message is returned back to the sender from the receiver. INF 5070 – media servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

An XCP network (simplified) Network RTT: 100 ms Router’s capacity: 200. 000 B/s (available 200. 000 B/s) Sender’s capacity: 10. 000 B/s (available 10. 000 B/s) Sender’s current throughput: 0 B/s (or 0 B/ms) 1 1 6 20 0 10. 000 0 Sender 1 1 6 20 0 100 RTT Current Throughput 0 Delta Throughput 200. 000 0 Feedback Router INF 5070 – media servers and distribution systems 1 2 6 20 0 100 0 0 200. 000 Receiver 2005 Carsten Griwodz & Pål Halvorsen

XCP bandwidth distribution q. XCP distributes bandwidth fairly q. Bandwidth does not oscillate INF 5070 – media servers and distribution systems 2005 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 servers and distribution systems 2005 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 servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

Application Layer Approaches

Progressive Download q In-band in long-running HTTP response Ø Ø Ø q If packet loss is. . . Ø Ø q Plain file for the web server Even simpler than FTP No user interactions – start, stop, . . . 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 servers and distribution systems 2005 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 servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

Progressive Download Web server Retransmission Timeout Decoder Receive buffer TCP Stack Network (congested) INF 5070 – media servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

Priority Progress Streaming q Unmodified TCP (other transports conceivable) Unmodified MPEG-1 video-in (other encoding formats conceivable) q Real-time video processing q Ø Ø 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 Ø q 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 servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

Priority Progress Streaming Packets to send High priority Medium priority Low priority Progress Queue INF 5070 – media servers and distribution systems To TCP 2005 Carsten Griwodz & Pål Halvorsen

Receiver-driven Layered Multicast (RLM) q Requires Ø Ø q Operation Ø Ø q IP multicast layered video codec (preferably exponential thickness) 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 servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

Receiver-driven Layered Multicast (RLM) q Requires Ø Ø q Operation Ø Ø q IP multicast layered video codec (preferably exponential thickness) 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 servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

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

Receiver-driven Layered Multicast (RLM) q Layer size considerations Ø Ø Adaptations are in steps of 1 layer Big layers n n Ø Small layers n n n Ø 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 q Join experiments have huge impact Quality changes are very visible 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 servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

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

Stream Control Transmission Protocol (SCTP) q Stream Control Transmission Protocol Ø Ø RFC 2960, IETF Standards Track & SCTP Unreliable Data Mode Extension Features n n n q (draft-ietf-tsvwg-usctp-00. txt) 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 servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

Stream Control Transmission Protocol (SCTP) q 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 servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

Stream Control Transmission Protocol (SCTP) q SCTP packets Ø Ø Consist of one or more chunks Chunks are bundled automatically Chunks: ü ü ü ü ü INF 5070 – media servers and distribution systems DATA SACK INIT ABORT SHUTDOWN HEARTBEAT ERROR ECNE CWR & responses 2005 Carsten Griwodz & Pål Halvorsen

Stream Control Transmission Protocol (SCTP) q Deadlines Ø Ø q Applications can give deadline for packet sending Once sent, delivery is guaranteed (retransmission) Reliability Ø Sender and receiver window are computed n n n Ø Ø n Retransmission n n not before 4 th missing report always before new packets Sender can specify n n q Ø Proposed extension Max. number of retransmissions n n Ø q unordered delivery per packet Unreliable transport – V 1 Ø per stream in bytes changed per stream as in TCP are piggybacked contain ranges of packets Delivery Ø Arrival is reported by SACK chunks n Ø q 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 servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

Datagram Congestion Control Protocol (DCCP) q Datagram Congestion Control Protocol Ø Ø q Transport Protocol Ø Ø Ø q Under development http: //www. ietf. org/html. charters/dccp-charter. html 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 servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

Datagram Congestion Control Protocol (DCCP) q 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 servers and distribution systems Loss probability Number of packets ack’d by one ACK 2005 Carsten Griwodz & Pål Halvorsen

Selective Retransmission-RTP (SR-RTP) q Features Ø Ø Ø q Congestion Manager Ø Ø q Relies on a layered video codec Supports selective retransmission Uses congestion control to choose number of video layers 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 servers and distribution systems 2005 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 servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

Selective Retransmission-RTP (SR-RTP) q Binomial Congestion Control Ø Provides a generalization of TCP AIMD Increase Decrease Ø 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 INF 5070 – media servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen

Selective Retransmission-RTP (SR-RTP) q SQRT Ø Ø Ø Special case of binomial congestion control k=0. 5, l=0. 5 Name because w 0. 5 = sqrt(w) AIMD q Effect of SQRT Ø Ø Ø Average bandwidth is like TCP’s Maximum is lower SQRT covers a step function with less steps INF 5070 – media servers and distribution systems SQRT 2005 Carsten Griwodz & Pål Halvorsen

The End: Summary

Summary q Non-Qo. S protocols: Ø Transport level protocols n n n Ø Application layer protocols n n n Ø RTP Priority progress streaming RLM DCCP. . . Signaling protocols n q UDP TCP. . . RTSP Next time, we look at protocols supporting Qo. S INF 5070 – media servers and distribution systems 2005 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 servers and distribution systems 2005 Carsten Griwodz & Pål Halvorsen