Error Control for IPTV over xDSL Networks - CiteSeerX

Error Control for IPTV over xDSL Networks Ali C. Begen Video and Content Networking Business Unit Cisco Systems San Jose, CA 95134 USA [email protected]

Abstract—We discuss the necessity of error control for supporting IPTV over imperfect access networks. In particular, we consider typical DSL environments, and examine the physicallayer impairments and error-mitigation techniques. For these networks, we evaluate the performance of two different applicationlayer Forward Error Correction (FEC) methods. An overview of hybrid error-control methods and recent developments in standardization is also presented.

I. I NTRODUCTION With the advances in video and networking technologies, IP television (IPTV) is currently being deployed by many service providers throughout the world. By delivering video content, Internet telephony (VoIP) and conventional Internet data over a converged IP infrastructure, IPTV service providers offer subscribers many new exciting features that were not viable in traditional broadcasting. With IPTV, TV enthusiasts can enjoy interacting with programming content as well as with other viewers watching the same content. Customized channel lineups and on-demand capabilities enable viewers to access a much wider selection of content anytime they want to. An imminent impact of transmitting broadcast-quality video over IP is the dramatic increase in bandwidth consumption. On a global scale, it is estimated that monthly IP traffic will double every two years between 2007 and 2011, and exceed 28 exabytes (1018 bytes) by 2011, largely driven by the high-definition video applications [1]. Not surprisingly, this dramatic growth in bandwidth demand brings new challenges to the fore. Most importantly, many networks currently deployed in the Internet have not been optimized for large-scale distribution of high-bandwidth streams. Network impairments such as severe packet loss and jitter will impede IPTV services unless the service providers and operators deploy some form of error control for IPTV and scale their networks to a point where their subscribers can be simultaneously delivered highquality video content. In this study, our goal is to evaluate Forward Error Correction (FEC) as an error-control method for IPTV over a DSL access network infrastructure. We start our discussion in Section II with an overview of IPTV architecture, its requirements and the challenges faced today. We outline the basics of DSL data transmission in Section III. Section IV presents results for FEC-based error control. We conclude the paper in Section V with a brief overview of standardization efforts underway and future directions for IPTV.

II. IPTV A RCHITECTURE , R EQUIREMENTS AND C HALLENGES IPTV is the delivery of broadcast-quality television programming over IP. It is a managed service offered by a service provider to its users. IPTV should not be confounded with Internet video (also known as the over-the-top video), which refers to streaming video from servers potentially outside the service provider’s network. Since they are delivered over an uncontrolled, i.e., best-effort, network, video clips streamed from Web servers that belong to TV networks or that are used for video sharing such as YouTube and Yahoo Video, are not considered to be an IPTV service1 . Full-fledged IPTV services employ digital rights management, content and billing management, parental controls and quality assurance. On the other hand, a major difference between IPTV and traditional air/cable/satellite TV services is that not all programming is simultaneously broadcasted to the viewers due to the access network bandwidth limitations. A viewer only receives the stream(s) for the selected channel or the video-on-demand session. There has been a recent interest in both academia and industry to investigate the potentials of delivering IPTVlike services by using peer-to-peer (P2P) overlays. To date, several software implementations became available for public use. Among many others, Joost, PPLive and SoPCast gained relatively more popularity [2]2 . Recently, Huang et al. studied the impact of P2P sharing for IPTV services in the context of fiber-to-the-node (FTTN) networks [3]. The authors proposed a P2P-based IPTV service platform called MediaGrid and presented a detailed capacity analysis. The study identified the conditions when P2P sharing improves the service capacity and when it impedes the system performance. A. Architecture IPTV networks originate their content for transmission using many clustered components collectively called headends. There are three common types of IPTV headends to meet national, regional and local content distribution requirements. Super headends (SHE) receive and ingest content on the national level typically from satellites or off the air. After processing and encoding, the SHEs distribute the national content to video hub offices (VHO) over a core IP/MPLS 1 YouTube:

http://www.youtube.com, Yahoo Video: http://video.yahoo.com. http://www.joost.com/, PPLive: http://www.pplive.com/en/index.html, SopCast: http://www.sopcast.com/. 2 Joost:

632

1-4244-1457-1/08/$25.00 © IEEE This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE CCNC 2008 proceedings. Authorized licensed use limited to: Cisco. Downloaded on September 7, 2009 at 08:11 from IEEE Xplore. Restrictions apply.

Video Hub Office (VHO) Regional Headend (RHE)

Super Headend (SHE)

Video Switching Office (VSO) National Content

Receiver Encoder

Receiver Encoder Acquisition

STB

Regional Content

IPTV Service Assurance

VoD Caches CA/DRM

IPTV Service Assurance

Streamers

STB

VoD Servers

IP/MPLS Core Network Core Router

STB

Metro Aggregation and Distribution Network

Metro Ethernet

Access Network Aggregation Router

Core Router

Distribution

DSLAM xDSL

Aggregation

Access

STB

Home

IPTV architecture.

network. VHOs aggregate national, regional and local content with the on-demand services, and serve metropolitan areas with a population of between 100,000 to 500,000 homes. VHOs are connected to video switching offices (VSO) over metro aggregation networks. VSOs distribute the IPTV streams to the customer premises over access networks. A high level of IPTV architecture is shown in Fig. 1. The most prevalent transport technique for linear IPTV is to multicast UDP/IP packets with a payload of MPEG-2 Transport Stream (TS). Some of the newer standard-compliant video architectures use RTP/UDP/IP encapsulation in order to benefit from the appealing features of RTP [4] such as error repair and stream monitoring. An MPEG-2 TS consists of a sequence of fixed-length packets (188 bytes) that contain one or more Packetized Elementary Streams (PES). Up to seven of these packets are combined together to produce a payload of up to 1316 bytes. With the addition of headers for RTP (12 bytes), UDP (8 bytes) and IPv4 (20 bytes), the total IP packet size becomes 1356 bytes. It is important to note that MPEG-2 TS was originally designed for low-jitter and lowloss environments, which is generally not true for IP networks. Thus, it is ultimately the application’s responsibility to make sure that MPEG-2 TS packets are delivered to the clients in order and without errors. B. Requirements IPTV is intended to provide entertainment-caliber video. Delivering IPTV service over a packet-switched network demands near zero packet loss and limited jitter. Moderate amount of delay variation (e.g., up to 200 ms) can be mitigated by employing a de-jittering buffer in the set-top boxes (STB). Lost packets can also be recovered by various error-control methods. Nevertheless, due to statistical nature of packet switching, satisfying these strict requirements is sometimes difficult in practice, and errors will occur. A conventional industry benchmark for entertainment-grade IPTV service quality is to deliver no more than one perceivable

error during a two-hour movie. Fig. 2 shows the upper bounds on the packet loss rates as a function of the video bitrate for different values of mean time between the artifacts (MTBA). We observe that high-definition video streams require lower packet loss rates. However, if the errors occur in bursts, higher packet loss rates can be tolerated. −5

10 Packet Loss Rate Requirement

Fig. 1.

STB

STB

Aggregation Router

Core

STB

FTTx

Streamers

VoD Servers

CA/DRM

uBR CMTS

Ad Insertion

−6

10

−7

10

−8

10

0

MTBA: 1 Hour (Random) MTBA: 1 Hour (Burst = 8ms) MTBA: 2 Hours (Random) MTBA: 2 Hours (Burst = 8ms) MTBA: 4 Hours (Random) MTBA: 4 Hours (Burst = 8ms) 5

10 Mbps

15

20

Fig. 2. Packet loss rate requirements for standard and high-definition videos in case of random and 8 ms-bursty errors.

One effective approach to keep the error rate due to congestion low is to use video admission control. Service providers often assume that not all of the subscribers will consume their bandwidth at the same time, and thus, usually oversubscribe their networks. While this design choice works well for delayinsensitive data applications, admitting IPTV subscribers arbitrarily without sufficient provisioning and resource allocation leads to unacceptable video quality perceived by not only newly admitted users, but also existing users. Thus, it is often necessary to enforce traffic management and admission control in IPTV networks. C. Challenges Channel Change Time: Conventional analog TV services offer virtually instant zapping times. A similar low response time is also expected by the IPTV users. However, zapping time in IPTV is adversely affected by several factors including

633 This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE CCNC 2008 proceedings. Authorized licensed use limited to: Cisco. Downloaded on September 7, 2009 at 08:11 from IEEE Xplore. Restrictions apply.

Fast Path AS0 AS1 AS2 AS3 LS0 LS1 LS2 OAM

CRC

Scrambler & FEC

CRC

Scrambler & FEC

Interleaver

Tone Ordering

III. OVERVIEW OF DSL I MPAIRMENTS AND I NTERLEAVING DSL is a data-link technology for high-speed data that runs over the legacy telephone cable plants. These plants use unshielded twisted pair and were originally designed to merely carry low-band analog voice traffic. Thus, the subscriber lines are strongly subject to signal attenuation and external noises when they are used for broadband transmission. The noises, e.g., the background noise, crosstalk and impulse noises, diversely impact the range and achievable speed of different flavors of xDSL technologies. In this section, we overview the mitigation techniques for the crosstalk and impulse noise as these are the most difficult noise sources to mitigate. Crosstalk is a phenomenon between two neighboring wires that is due to the capacitive and inductive coupling. This coupling induces undesired currents on each of the communication channels. If the noise is due to the signal traveling in the opposite direction, it is referred to as the near-end crosstalk (NEXT). If the induced signal travels in the same direction, the noise is referred to as the far-end crosstalk (FEXT). Crosstalk is a significant source of noise, however, it is usually addressed by using Trellis Coding and ReedSolomon (RS) codes. Excessive crosstalk noise may cause dribbling, i.e., random, errors. Impulse noise is a non-stationary stochastic type of noise that can be induced due to the electromagnetic interference from domestic sources such as nearby electrical equipments, appliances, communication devices as well as external events

like lighting. Impulse noises occur in the form of spikes of different amplitude and duration at random intervals. Studies report that the noise characteristics often differ significantly for different service providers. In addition, the operators may observe diverse noise characterization in different loops in the same network. While this non-stationary behavior of the impulse noises renders the statistical analysis difficult, it is imperative for operators to understand how their network is impacted by impulse noise (For a statistical analysis and characterization of impulse noises, see [10]). In the sections that follow, we focus on error mitigation for impulse noise in an ADSL environment. Note that the components of physical transmission for different xDSL technologies may differ, although the concept and solutions are mostly the same across different technologies. A simplified transmitter reference model for an ADSL system is sketched in Fig. 3. An ADSL transceiver unit (ATU) supports up to four downstream simplex bearer channels, denoted by AS0 through AS3, and up to three duplex bearer channels, denoted by LS0, LS1 and LS2. There is also a duplex interface for operations, administration, maintenance (OAM) and control of the ADSL system. There are two paths shown between the Mux/Sync Control and Tone Ordering. The first path is the fast path that provides low latency. The second path is the interleaved path that provides a lower error rate at the expense of increased latency. After Mux/Sync Control, the incoming data is protected against bit errors by cyclic redundancy checks (CRC) and RSbased FEC. Essentially, K data bytes are encoded to produce an RS codeword with a size of N = K + R bytes, where R is the number of parity bytes. The RS codewords are then scrambled to randomize the data stream and transmitted over either the fast or interleaved path. Tone Ordering receives the RS codewords from both paths and encodes them into discrete multi-tone (DMT) symbols. The line data rate of a DSL link is determined by the RS codeword size and how many RS codewords are encoded into each DMT symbol.

MUX/Sync

Internet Group Management Protocol (IGMP) signaling delay, i.e., leave and join delays, MPEG decoding delay, i.e., program specific information (PSI) including program association table (PAT) and program map table (PMT) acquisition delays, random access point (RAP) delay, i.e., I-frame acquisition delay, conditional access system (CAS) key acquisition delay, and de-jittering buffer delay in the STB. There are a number of solutions currently being developed to reduce the impact of these delay sources. For an overview, see [5]. Network Management: Given that IPTV is highly bandwidth-intensive, network management becomes critical for successful IPTV deployments. Load balancing across the network and providing enough share of bandwidth to lowbandwidth applications is required to keep a certain level of service quality. Thus, the management of IPTV networks is an important issue and should be considered as a critical component of IPTV service assurance [6]. Video Quality Monitoring (VQM): VQM tools enable the service providers to monitor the quality-of-experience (QoE) of each subscriber in real time and take necessary actions against misbehaving servers, routers, switches and flows. As the quality metric, video mean opinion score (VMOS) [7], peak signal-to-noise ratio (PSNR), moving picture quality metric (MPQM) [8] and media delivery index (MDI) [9] can be adopted. In addition, VQM can also be used as a proactive tool to identify the upgrades and additional provisioning required for the network before service disruptions occur.

DMT Symbols

Interleaved Path

Fig. 3. Simplified ADSL transmitter reference model showing the fast and interleaved paths [11].

It is important to note that R bytes of parity can correct up to T = R2 bytes in error in a codeword. In other words, an impulse noise that causes more than R2 bytes to be in error, renders the decoding of the codeword impossible. One can increase the amount of redundancy, i.e., R, to be able to endure long-lasting impulse noises, however, this directly reduces the net data rate available to the user. A more effective approach is to interleave multiple codewords to improve the resiliency against bursty errors. The number of interleaved codewords


is referred to as the interleaver depth and denoted by D. As a result of interleaving, the bursty errors are spread over several codewords and can be corrected by a smaller amount of redundancy. The cost of interleaving is the increase in latency and required memory space. The impulse noise protection (IN P ) is the number of consecutive DMT symbols that can be corrected by the RS code in the event of an impulse noise. It is proportional to the number of parity bytes times the interleaver depth. The derivation of IN P is tabulated along with other pertaining parameters for typical ADSL/ADSL2+ configurations in Table I. Parameter & Relation

ADSL

ADSL2+

Data bytes per RS codeword, K

239 bytes

69 bytes

Parity bytes per RS codeword, R

16 bytes

10 bytes

Correctable byte errors per RS codeword,T = R 2 Total bytes per RS codeword, N = K +R Number of RS codewords per DMT symbol, S −1 DMT duration, tDM T Line data rate, LDR = Net data rate, N DR = Interleaver depth, D

N S×tDM T LDR × K N

Size of required memory, B = (N − 1) × (D − 1) Interleaving delay, ID =

B LDR

×D Block size (Protection period), P P = N LDR

8 bytes

5 bytes

255 bytes

79 bytes

1

11

250 µs

250 µs

8.0 Mbps

27.4 Mbps

7.5 Mbps

24 Mbps

32

352

7874 bytes

27378 bytes

7.87 ms

7.97 ms

8.16 ms

8.10 ms

Correctable error burst length, BL = D×T

256 bytes

1760 bytes

Impulse noise protection, IN P = BL×S N

1

2

TABLE I T YPICAL CONFIGURATION OF INTERLEAVING IN ADSL AND ADSL2+. R EPRODUCED FROM [12].

In order to demonstrate the effectiveness of interleaving, let us consider the following example from [12]. Kerpez reported that the average arrival rate of impulses that caused an error was one every 750 seconds, implying that one IP packet was lost every 750 seconds, if it was transmitted over the fast path without interleaving. If interleaving was used, the mean time between the error events increased. Specifically, when an error occurred, the number of DMT symbols that could not be recovered was one, two and three or more with a probability of 85%, 12% and 3%, respectively. In an ADSL system with IN P = 1, two or more DMT errors would be required to render the whole block undecodable. In other words, 8 ms of data (up to seven 1356-byte IP packets at the line rate) would 750 = 5000 seconds (1.4 hours). In case of be lost every 1−%85 ADSL2+ where IN P = 2, up to 19 IP packets would be lost every 25000 seconds (7 hours). Evidently, 8 ms of interleaving can increase the mean time between the error events by a large factor. However, one should keep in mind that longer interleaving or stronger FEC protection may be needed for the links experiencing more frequent, longer and stronger impulse noises. IV. FEC-BASED E RROR C ONTROL Let us consider the IPTV architecture sketched in Fig. 1, where the IPTV streams are sourced from the streamers in

a VSO and transmitted over the aggregation router(s) and a DSLAM. On this path, there are multiple sources for packet losses. Packets can be lost due to overloading of the streamers, routing failures, queue overflows in the routers, DSLAMs and STBs, noises on the DSL links and contention on the in-home links3 . Since the FEC used at the DSL physical layer cannot detect and recover the packets lost anywhere else on the path, an end-to-end error-control method is often required to satisfy the IPTV QoE requirements. Furthermore, when a whole block of data is lost on the DSL link, the lost information can only be recovered by a higher-layer error-control protocol. One effective approach for end-to-end reliability is to use application-layer FEC (AL-FEC). AL-FEC groups the source packets into blocks each with a duration of one protection period and applies protection on each block independently to generate a desired number of repair packets. The source as well as the repair packets are then transmitted to the receiver(s). At the receiver side, the lost packets can be recovered by erasure decoding provided that sufficient number of repair packets are received. Recovery probability increases with the number of repair packets per block, which, however, cannot be increased arbitrarily to keep the FEC overhead at an acceptable level. One way to reduce the FEC overhead is to extend the block size. However, this is not viable beyond a threshold either, as the time required to decode and play video after a channel change or rewind/fast-forward operation is fundamentally tied to the duration of the protection period. In this section, we present the trade-offs between the FEC overhead and protection period for ideal FEC codes and the Pro-MPEG CoP3 codes. Ideal codes can recover the lost packets as long as the number of missing packets is not larger than the number of repair packets. CoP3 codes [13], on the other hand, were proposed to combat bursty losses. While their design and computational complexity is relatively simpler, CoP3 codes usually introduce larger overhead for an equal amount of error protection. CoP3 codes can be one dimensional (column or row) or two dimensional (column and row). Although better error-recovery performance can be achieved by two-dimensional CoP3 codes, in this study we consider only one-dimensional (column) CoP3 codes, as it is more widely deployed. As the results will show, the performance of both ideal and CoP3 codes heavily depends on the burst duration. To quantify this dependency, we study random as well as bursty losses at different average packet loss rates. Due to the lack of space, we only focus on the unicast transmission for on-demand video and broadcast TV with trick modes. The simulations were conducted for a standard-definition (SD) and a high-definition (HD) video stream that were H.264 encoded at 2 and 6 Mbps, respectively. These streams were 3 When the communication channel between a DSL modem and the DSLAM experiences heavy quality degradation, the DSL modem may lose its synchronization with the DSLAM and requires resynchronization to reactivate the DSL line. During this process, which may take several tens of seconds, the IPTV service will be disrupted. This is considered a system outage and IPTV error-repair mechanisms do not recover from such outages.


transmitted in MPEG-2 TS packets, each with a size of 1356 bytes. For both streams, we considered two FEC latency budget values, 100 and 400 ms. Latency budget is the time difference between the first source packet and the last repair packet belonging to a particular block. Depending on how the source and repair packets are transmitted, latency budget determines the maximum usable block size. For example, in the ideal code simulations, we adopted the default sending arrangement proposed for Raptor codes [14]. This arrangement allowed us to use the full latency budget for the block size and have a constant total sending rate. For the CoP3 runs, we used the burst sending arrangement, where the repair packets of a block were interleaved with the first few packets of the subsequent block [14]. This way, source sending rate was kept the same and almost all of the latency budget could be used for the block size. One disadvantage of this arrangement was that the total sending rate was bursty. At different average packet loss rates and burst durations, we computed the minimum amount of overhead required to achieve an MTBA of two hours (Each block in error counts as one artifact). The results are presented in Fig. 4. Our findings can be summarized as follows: •

•

•

•

Below a certain threshold of average packet loss rate (≈ 10−4 ), the amount of required overhead does not vary much and is comparable for both ideal and CoP3 codes. At higher loss rates, the CoP3 code may become infeasible to use. That is, even 100% overhead may not suffice to achieve the required QoE. For the ideal code, bursty packet losses require larger overhead than random losses for all packet loss rates. For the CoP3 code, random losses require smaller and larger overhead than bursty losses for the loss rates below and above a certain threshold, respectively. At high packet loss rates, random losses can easily render the CoP3 code undecodable. So, larger overhead is required. In contrast, bursty losses occur less frequently and can be recovered easily if sufficient interleaving is employed. At mid-range packet loss rates, the CoP3 code requires a similar or even smaller overhead than the ideal code if the losses occur in bursts. This is due to the sending arrangements adopted for each code. In the ideal code case, sending both the source and repair packets of a block during the same block increases the number of packets lost during a burst. In the CoP3 code case, repair packets are transmitted during the subsequent block, keeping the number of packets lost in a burst unchanged. Thus, the effective burst size is larger for the ideal code with the default sending arrangement and requires more protection compared to the CoP3 code with the burst sending arrangement. We repeated the same set of simulations to achieve an MTBA of four hours. While the results did not change considerably at low loss rates, larger overhead was required for both FEC codes at higher loss rates. The difference between the cases of MTBA of two and

four hours was more apparent for the CoP3 code and when the latency budget was 100 ms. V. R ECENT S TANDARDIZATION E FFORTS AND F UTURE D IRECTIONS The increasing interest of the service providers in the IPTV has fueled several international and regional standards developing organizations to expedite their efforts in this area. In this section, we briefly overview these efforts. In April 2006, ITU-T TSB directorship formed a new focus group on IPTV, called FG-IPTV4 . The initial goals for FGIPTV were to define IPTV and IPTV framework, specify architecture and QoE requirements, describe service scenarios, network management and control mechanisms, define security requirements, review existing standards and coordinate new standardization activities, and facilitate interoperability between middleware, applications, user interfaces and content formats. To achieve these goals efficiently, six working groups were chartered under FG-IPTV. FG-IPTV is expected to have its final meeting and transfer its work to Study Group 13 (SG 13: Next Generation Networks) in December 2007. ATIS, which is mainly driven by the North American telephone companies, also formed a forum to meet the service provider demands for IPTV standards. Similar to ITU-T FGIPTV, the ATIS IPTV Interoperability Forum (ATIS IIF) works on the architectural and QoE performance requirements, digital rights management, metadata, testing and interoperability5 . ATIS IIF also focuses on creating a reference IPTV architecture for the industry. On the European side, DVB develops digital video standards through ETSI. The newly developing DVB-IPI standard proposes the hybrid use of Raptor codes and Pro-MPEG CoP3 codes [15]. Initial performance improvements are evaluated in [14]. The IETF has recently initiated a new working group, called FEC Framework (fecframe), with the primary objective to develop a framework for using FEC codes to recover from packet losses in unicast and multicast media streams6 . In the Audio/Video Transport (avt) Working Group, RFC 4585 defined a new extended profile for RTP, called RTP/AVPF. This profile introduced NACK packets for RTCP and allowed to report multiple packet losses within a single RTCP report [16]. RFC 4588 [17] defined a new RTP payload format to be used for retransmissions. The new payload format is both unicast and multicast-friendly. An Internet draft is currently under development to extend RTCP so that it will be possible to send unicast feedback to a multicast sender [18]. This feature will enable source-specific multicast (SSM)-based IPTV applications to benefit from feedback-based error-repair mechanisms. Retransmission is a low-overhead and simple-to-design error-control method. Provided that the retransmission roundtrip time is not prohibitively large, using retransmission in combination with FEC can be an effective way to repair 4 ITU-T

FG-IPTV: http://www.itu.int/ITU-T/IPTV. IIF: http://www.atis.org/iif. 6 IETF FEC Framework WG: http://www.ietf.org/html.charters/fecframecharter.html. 5 ATIS


30

30 Ideal − Random Ideal − Burst = 8ms CoP3 (Column) − Random CoP3 (Column) − Burst = 8ms

25

20

Overhead (%)

Overhead (%)

25

15 10 5 0

Ideal − Random Ideal − Burst = 8ms CoP3 (Column) − Random CoP3 (Column) − Burst = 8ms

20 15 10 5

−6

10

−5

−4

10 10 Packet Loss Rate

0

−3

10

−6

10

−5

(a) 30 Ideal − Random Ideal − Burst = 8ms CoP3 (Column) − Random CoP3 (Column) − Burst = 8ms

25

Ideal − Random Ideal − Burst = 8ms CoP3 (Column) − Random CoP3 (Column) − Burst = 8ms

25

20

Overhead (%)

Overhead (%)

−3

10

(b)

30

15 10 5 0

−4


20 15 10 5

−6

10

−5

−4


0

−3

10

−6

10

(c)

−5

−4


−3

10

(d)

Fig. 4. Results for SD video, 100 ms of latency budget (a), HD video, 100 ms of latency budget (b), SD video, 400 ms of latency budget (c), and HD video, 400 ms of latency budget (d).

random and congestive losses. While a hybrid approach can eliminate the drawbacks of retransmission and FEC when they are used alone, computing the optimal balance between them is a difficult problem and open to further research. Acknowledgments: The author would like to thank Dave Oran and Greg Thompson of Cisco Systems for their constructive comments and suggestions. R EFERENCES [1] “Global IP traffic forecast and methodology, 20062011,” Cisco Systems, 2007. [Online]. Available: http://www.cisco.com/application/pdf/en/us/guest/netsol/ ns537/c654/cdccont 0900aecd806a81aa.pdf [2] A. Sentinelli, G. Marfia, M. Gerla, L. Kleinrock, and S. Tewari, “Will IPTV ride the peer-to-peer stream?” IEEE Commun. Mag., vol. 45, no. 6, pp. 86–92, June 2007. [3] Y. Huang et al., “Capacity analysis of MediaGrid: A P2P IPTV platform for fiber to the node (FTTN) networks,” IEEE J. Select. Areas Commun., vol. 25, no. 1, pp. 131–139, Jan. 2007. [4] RFC 3550, “RTP: A transport protocol for real-time applications.” [Online]. Available: http://www.ietf.org/rfc/rfc3550.txt [5] U. Jennehag, T. Zhang, and S. Pettersson, “Improving transmission efficiency in H.264 based IPTV systems,” IEEE Trans. Broadcast., vol. 53, no. 1, pp. 69–77, Mar. 2007. [6] K. Kerpez, D. Waring, G. Lapiotis, J. B. Lyles, and R. Vaidyanathan, “IPTV service assurance,” IEEE Commun. Mag., vol. 44, no. 9, pp. 166–172, Sept. 2006. [7] “Triple-play services quality of experience (QoE) requirements,” DSL Forum Tech. Rep. TR-126, 2006. [Online]. Available: http://www.dslforum.org/techwork/tr/TR-126.pdf

[8] A. Basso, I. Dalgic, F. Tobagi, and C. Lambrecht, “Study of MPEG-2 coding performance based on a perceptual quality metric,” in Picture Coding Symp. (PCS), 1996. [9] RFC 4445, “A proposed media delivery index (MDI).” [Online]. Available: http://www.ietf.org/rfc/rfc4445.txt [10] I. Mann, S. McLaughlin, W. Henkel, R. Kirkby, and T. Kessler, “Impulse generation with appropriate amplitude, length, interarrival, and spectral characteristics,” IEEE J. Select. Areas Commun., vol. 20, no. 5, pp. 901–912, June 2002. [11] “Asymmetric digital subscriber line (ADSL) transceivers,” ITUT Recommendation G.992.1, 1999. [12] K. J. Kerpez, “Models for packet loss bursts related to video quality of experience (QoE),” DSL Forum Contribution # dsl2005.460.03, 2005. [13] “Forward error correction for real-time video/audio transport over IP networks,” SMPTE Spec. 2022-1, 2007. [14] “DVB application layer FEC evaluations,” DVB Document A115 - TM 3783, 2007. [Online]. Available: http://www.dvb.org/ technology/bluebooks/a115.tm3783.AL-FEC\ Evaluation.pdf [15] “Digital video broadcasting (DVB); transport of MPEG 2 TS based DVB services over IP based networks,” ETSI TS 102 034 V1.3.1, 2007. [16] RFC 4585, “Extended RTP profile for real-time transport control protocol (RTCP)-based feedback (RTP/AVPF).” [Online]. Available: http://www.ietf.org/rfc/rfc4585.txt [17] RFC 4588, “RTP retransmission payload format.” [Online]. Available: http://www.ietf.org/rfc/rfc4588.txt [18] Internet Draft: draft-ietf-avt-rtcpssm-13, “RTCP extensions for single-source multicast sessions with unicast feedback.” [Online]. Available: http://tools.ietf.org/html/ draft-ietf-avt-rtcpssm-13
