280 likes | 421 Views
Survey of Error Recovery Techniques for IP-Based Audio-Visual Multicast Applications. Georg Carle and Ernst W. Biersack lnstitut EURECOM. 2011. 05. 24 Kim, Dong Joo. 1 /28. Contents. 2 /28. Abstract. IP-based networks are inexpensive
E N D
Survey of Error Recovery Techniques for IP-Based Audio-Visual Multicast Applications Georg Carle and Ernst W. Biersack lnstitut EURECOM 2011. 05. 24 Kim, Dong Joo 1/28
Contents 2/28
Abstract • IP-based networks • are inexpensive • offer no guarantees for loss or delay • For Audio-Visual Multicast • recovery from losses due to congestion is a key problem that must be solved • In this paper • overview of existing transport-layer error control mechanisms • suitability for use in IP-based networks • requirements of error control mechanisms • different network scenarios are used to assess the performance of retransmission-based error correction and forward error correction 3/28
Backgrounds; Transport Protocol Requirements • Web traffic • TCP that uses a closed loop congestion control algorithm • continuous media (CM) applications use UDP that does not have a congestion control mechanism • Goal : use of cheap network services, tolerating high loss rate, and delay violations by network and by servers • powerful real-time error control mechanisms for audio-visual applications are needed • Characteristics of CM streams • Strict timing requirements • arriving after a certain point in time, it is useless • Some tolerance of loss • the amount of loss that can be tolerated depends on the medium, the coding techniques used, and human perception • A certain periodicity • video, for instance, consists of a fixed number of frames per second. when transmitting CM across a network this periodicity is normally lost 4/28
Backgrounds; Transport Protocol Requirements • Multipoint Transport Services • Existing protocols is classified according to the degree of reliability they provide • 1:N or multicast service vs. M:N or multi-peer service 5/28
Backgrounds; Application Scenarios • For non-real-time application • reliably deliver a data stream • requirements are very general • a single protocol such as TCP to be used by a large variety of applications • For real-time application • specific requirements which make certain protocol mechanisms more suitable than others. • characteristics of the application data units(ADUs) • end-to-end delay requirement • reliability requirement • coding techniques • since it is difficult to design error recovery protocols that are well suited for the whole range of parameters, solutions are targeted for specific applications scenarios. 6/28
Backgrounds; Application Scenarios • Three different application scenarios • each application scenario is characterized by ADU size, availability, life span, priority, delay budget, and reliability requirements 7/28
Backgrounds; Mechanisms for Error Recovery • ARQ (Automatic Repeat Request) • Lost data detection (detected by the receiver; timeout) • Acknowledgment strategy (ACKs or NAKs) • the two best known retransmission strategies: Go-Back-N & selective retransmission • trade-off : simplicity of receiver implementation vs. transmission efficiency • FEC (Forward Error Correction) • reconstruction of lost packets at the receiver • add parity, Reed-Solomen codes • do not need a return path • require very little time of recovery • have overhead • a single parity packet can be used to repair the loss of different data packets seen by different receivers 8/28
Backgrounds; Mechanisms for Error Recovery • Hybrid Error Control (ARQ/FEC) • ARQ and FEC can be used in combination 9/28
Backgrounds; Mechanisms for Error Concealment • Approximation or interpolation • audio-video transmission disguises the loss • recovery and concealment can also be combined • buffering is used, it increase the end-to-end latency and may be in conflict with the real-time requirement. 10/28
Model of the End-to-End Delay of a CM Data Transmission • Retransmissions for real-time applications • In the past, it was not suitable, possible today due to technology advances • Exploitation of End-to-End Delay Budget 11/28
Network Properties • IP-Based Networks • offers a datagram service with best-effort service quality with no guarantees for loss rate, delay, and in-sequence delivery • TCP congestion control algorithm used • more open-loop applications based on UDP are used, higher losses can be observed • one solution is resource reservation offered by RSVP(Resource Reservation Protocol) • IP Best-Effort service model vs. IP integrated Service model • In a future Internet, reservation will allow the provisioning of IP services with guaranteed QoS that will need some kind of tariffing • powerful error control mechanisms will continue to play an important role 12/28
Network Properties • ATM-Based Networks • offers a connection-oriented network service • can be used to implement IP integrated services • Error Characteristics in ATM Networks • different error control mechanisms in a certain case • Fast Reservation Protocol with Immediate Transmission (FRP/IT) • different priorities to different virtual connections (VCs) • trade off additional overhead vs. higher network utilization • Special Properties of ATM Networks Relevant to CM Error Control • guarantee in-sequence delivery • bounds on delay and error probability • increased reliability for retransmissions or to ensure low-delay retransmissions 13/28
Network Properties • Comparison of ATM and IP Networks • ATM networks • for CBR, VBR, known delay bounds • for UBR, UBR, unknown delay bounds • mean delay and delay variation may be much smaller than they are in IP services • IP networks • provide a best-effort type service • no delay bounds are given • mechanisms for access control and scheduling exist that allow IP services to be provided with QoS guarantees • in IP/RSVP-based networks, delay bounds can also be given 14/28
Mechanisms for Multicast Error Control • Key challenges of reliable multicast services • Multiple receivers with heterogeneous connections and processing capabilities • Feedback implosion • Defending on where loss in the multicast tree happens, different error scenarios result 15/28
Mechanisms for Multicast Error Control • Basic Mechanisms(1/4) • The approaches can be classified according to the following questions: • Who detects loss: the sender (waiting for all ACKs) or the receiver (using NAKs) • How to send feedback: using unicast or multicast, with the option of applying algorithms for NAK suppression • What is retransmitted: original data or parity • Who retransmits: the source, servers within the network, or other group members • How to retransmit: using unicast, multicast, or subgroup-multicast • How to cope with heterogeneity: adapting to the slowest/most impaired receiver, or ignoring receivers that do not reach certain limits • Loss Detection • sender-initiated protocols : • receivers return positive ACKs • the sender is responsible for error detection • has problems in case of large groups; cause congestion and losses in the sender’s neighborhood • receiver-initiated protocols : • the receiver is responsible for error detection • receiver issues a NAK by unicast or multicast • far more scalable than sender-initiated protocols for large groups 16/28
Mechanisms for Multicast Error Control • Basic Mechanisms(2/4) • Feedback • Unicast vs. Multicast • Multicasting control messages proves useful when receivers are locally concentrated • When receivers are far apart, multicasting control messages has negative impact due to the large propagation delay, consuming significant network resources in comparison with unicast transmissions • NAK Suppression : Slotting and Damping Algorithms • NAK suppression reduces the amount of feedback the sender must process • Slotting describes a mechanism where receivers send feedback via multicast either immediately or after a delay of one or more time slots • Damping describes a mechanism in which a receiver suppresses its own feedback packet if feedback from other receivers corresponds to its own state • optimized this algorithm is employed on various protocols • It increases the mean delay until the first NAK reaches the transmitter (disadvantage) 17/28
Mechanisms for Multicast Error Control • Basic Mechanisms(3/4) • Data Retransmission vs. Parity Retransmission • Retransmission of missing original data (ARQ) is the most popular approach • Retransmission of parity results in much improved throughput and bandwidth usage for reliable multicast to a large number of receivers • In local networks, it is neither possible nor desirable • Source-Based vs. Decentralized Retransmission • Source-Based Retransmission • has advantage of simplicity • suffers from limited efficiency in large groups and much loss rates • XTP, MTP, RAMP employ source-based retransmission • Decentralized Retransmission • achieves better scalability using group communication servers (GCSs) • improves bandwidth efficiency and latency 18/28
Mechanisms for Multicast Error Control • Basic Mechanisms(4/4) • Heterogeneity • Applying a conservative policy, adapts to the needs of the slowest or most impaired receiver • provide several levels of service for different receivers • eject slow receivers that represent a performance bottleneck • Reliable Real-Time vs. Fully Reliable Multicast protocols • for real-time service, after a given deadline, successful delivery of data is no longer important, but protocols are based on the same basic mechanisms for feedback processing and error recovery • for non-real-time service, within the given delay budget, feedback processing and error recovery is subject to the same performance trade-offs • Transport protocols for real-time reliable multicast services have in common the trade-off between reliability and delay budget. By increasing the delay budget available for error recovery, the residual error probability in terms of no 19/28
Error Control Mechanisms for CM Data Transmission • ARQ-Based Error Control for CM Data Transmission • Audio Transmission : • Unicast interactive voice for small RTT (Slack ARQ by Dempsey and Liebeherr) • Non-interactive voice to multiple recipients with large RTT(STORM by Xu, Yavatkar et al.)Designated receiver (DR) for local recovery • Video transmission : • Challenge (Internet): rate control • Potential solution: layering • Receiver-driven layered multicast (RLM, by McCanne et al.) • Retransmission-based loss recovery protocol for non-interactive transmission to multiple receivers (LVMR by Li, Paul, Ammar) 20/28
Error Control Mechanisms for CM Data Transmission • FEC-Based Error Control for CM Data Transmission • FEC Schemes Suitable for IP Networks : • Video-specific FEC scheme ; applied to MPEG(Priority Encoding Transmission(PET) developed at ICSI, Berkely) • Transport layer protocol framework to support delivery of CM over the Internet(RTP developed by IETF, RTP+FEC, RTCP) • FEC Schemes Suitable for ATM Networks : • no plans are known for widespread use of any approach • For AAL, proposed schemes • Long-Interleaver Scheme (based on a Reed-Solomon code) • Short-Interleaver Scheme by ITU SG13; more limited error contol capabilities but better delay properties 21/28
Taxonomy of Protocol Mechanisms for Real-Time Audio-Visual Services • Overview • the suitability and performance of multicast protocol mechanisms depends on specific properties of the communication scenario • Network scenarios are determined by error and loss characteristics, delay characteristics and fan out characteristics. • Network Scenarios with Characteristic Properties (1/2) • Network Scenario 1: • losses on individual link • important role in many multicast scenarios • Examples: • losses occurred in subnets • point-to-multicast connections in wireless terminals • Problems: • lead to high bandwidth consumption & poor scaling for large groups • selective retransmission of missing packets requires a large amount of control messages and transmitter status information • Solutions: • hybrid error control scheme with parity retransmissions • local retransmission 22/28
Taxonomy of Protocol Mechanisms for Real-Time Audio-Visual Services • Network Scenarios with Characteristic Properties (2/2) • Network Scenario 2: • losses on shared link • heterogeneous RTTs • Examples: • Different distances to receivers • Large queueing delays for certain receivers • Occurs at IP multicast routers, ATM switches • Problems: • NACKs for common losses arrive within large time interval (implosion) • Local recovery not appropriate • Solutions: • RTT-aware NACK processing at the transmitter • Error detection and NACK processing close to location of error(Group Communication Servers) 23/28
Assessment of Error control Mechanisms for Different Scenarios • Scenario-specific Selection of Mechanisms • FEC is of particular benefit in the following scenarios: • Large groups • No feedback • Heterogeneous RTTs • Limited buffer • ARQ if of particular benefit in the following scenarios: • Heterogeneous loss • Loss on shared links of multicast tree dominates • small groups • Non-interactive applications • ARQ by local recovery: • large groups (good for individual losses, heterogeneous RTT) 24/28
Assessment of Error control Mechanisms for Different Scenarios • Assessment of Mechanisms Using Application Scenarios 25/28
Communication Subsystems Supporting Different Error Control Schemes • Selection of appropriate error control scheme • application-specific & network-specific parameters • two approaches exist • Design a single protocol that provides the full set of protocol mechanisms and can be configured with respect to application and network scenario. • supports all error control schemes • applicable for different CM applications • Use a communication subsystem which selects between different protocols for CM error control • feasibility complexity • can be integrated within either applicatio nor communication subsystem • Both approaches will most likely coexist in practice 26/28
Conclusion • ARQ-based schemes can be applied for real-time applications • ARQ adapted for real-time in combination with FEC is very promising • No mechanism works best for all scenarios • Selection of protocol mechanisms is highly challenging task • When network elements support different priorities, ARQ and FEC allow for recovery from excessive delays • Not yet exist a general solution under all network conditions and applicable for all CM applications • It is still an open question if there will ever be a single error recovery protocol 27/28
Thank you Kim, Dong Joo Hankuk University of Foreign Studies Dept. of Information and Communications Engineering sangnamleader@hufs.ac.kr