P. 1
Survey: RTCP Feedback In A Large Streaming Sessions

Survey: RTCP Feedback In A Large Streaming Sessions

|Views: 67|Likes:
Published by ijcsis
RTCP has limitation with scalability for large streaming sessions; because of the limitation of the bandwidth space that given to RTCP reports. Many researchers studied and still studying how to solve this limitation, and most of the researchers come out with tree structure as a solution but in a different ways.
RTCP has limitation with scalability for large streaming sessions; because of the limitation of the bandwidth space that given to RTCP reports. Many researchers studied and still studying how to solve this limitation, and most of the researchers come out with tree structure as a solution but in a different ways.

More info:

Published by: ijcsis on Dec 04, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

04/17/2011

pdf

text

original

(IJCSIS) International Journal of Computer Science and Information Security, Vol. 8, No.

8, November 2010

SURVEY: RTCP FEEDBACK IN A LARGE STREAMING SESSIONS
Adel Nadhem Naeem1, Ali Abdulqader Bin Salem2 Mohammed Faiz Aboalmaaly3 and Sureswaran Ramadass4
National Advanced IPv6 Centre Universiti Sains Malaysia Pinang, Malaysia

Abstract—RTCP has limitation with scalability for large streaming sessions; because of the limitation of the bandwidth space that given to RTCP reports. Many researchers studied and still studying how to solve this limitation, and most of the researchers come out with tree structure as a solution but in a different ways. Keywords- RTCP/RTP; Scalability; Large Streaming Sessions

The SR provides more statistics summarizing data transmission from the sender, e.g. timestamps, count of RTP data packets, and number of payload octet’s transmitted [4]. • RRs are used mainly in sender-based adaptive applications (The packet loss parameter in the RRs has been used as an indicator of congestion in the network). The SR is useful in lip-synchronization (inter-media synchronization) and in calculating transmission bit rates.

I.

INTRODUCTION

Communication is everywhere in our life and as a part of it is multimedia communication like, VoIP, multimedia conferencing, teleconferencing, video surveillance, satellite communication, etc. Multimedia communication is mainly using Real time protocol (RTP) that works together with Real time control protocol (RTCP) to do transfer data that depend on real time like video or audio over networks. RTCP is used to monitor RTP-Packets and reports feedback [1]. The main function of RTCP is to transmit periodically the sender and receiver reports to all members in RTP/RTCP. These reports allow a host to know if a problem exists or not and if the problem is local or global [2]. RTCP like other protocols and techniques facing a lot of problems, one of the important problems is RTCP scalability. [3] Increasing the number of hosts in RTP/RTCP sessions caused some problems under the name of the scalability problems; the problems can be the feedback delay, storage problem, flood of initial/bye RTCP reports, etc. II. SCALABILITY OF RTCP

What does scalability mean when it uses with RTCP term, increase the number of hosts in one session then increase the number of RTCP report, which means RTCP scalability. RTCP is kind of reports' protocol that sends/receive reports from/to hosts in one session. These reports limited to bandwidth size, RTCP given 5% from the whole session bandwidth size. RTCP has two types of the report: Sender report and Receiver report. Sender report uses 75% of RTCP bandwidth size while Receiver report uses 25%. The limitation of bandwidth size of RTCP makes it control the interval of sending receiving reports, increasing the number of hosts caused to increase the interval of sending receiving time and that makes the reports useless [6]. III. CHALLENGES OF RTCP SCALABILITY

RTP is a real time transmission protocol of audio and video, which provide several functions that help the transmission of audio and video such as [4]. Identification of payload data type, give a Sequence numbering to detect packet loss and to order packets, Time stamping so that data is played out at the right speeds [5]. RTCP is the attached protocol to RTP, and its working by sending/receiving reports, and it has several kinds of reports the main reports in RTCP are the sender report (SR) and receiver report (RR). Both include performance statistics on the total number of packets lost since the beginning of transmission, the fraction of packet loss in the interval between sending this feedback report and sending the previous one, the highest sequence number received, jitter, and other delay measurements to calculate the round-trip feedback delay time.

Many researchers studied and wrote about RTCP problems, and the most important problems are about the scalability of RTCP and reports’ feedback in a large streaming session. The scalability in RTCP faces many problems when it comes to a group of thousands of users. Some of these problems are addressed in [2 ... 11]. The first serious study done by ElMerakby, with three main researches 1998 “A Scalability Scheme for the Real-time Control Protocol”, 2000 “Design and Performance of a Scalable Real Time Control Protocol: Simulations and Evaluations”, and 2005 “Scalability improvement of the real time control protocol” where she studied RTCP problems with scalability and suggested a solution by divide the large session group to small session groups [4, 8, 9].

57

http://sites.google.com/site/ijcsis/ ISSN 1947-5500

(IJCSIS) International Journal of Computer Science and Information Security, Vol. 8, No. 8, November 2010

A. Feedback delay challenge One of the important challenges is the feedback delay and caused by increasing the group size, because of the limitation of the bandwidth size the RTCP reporting interval increased which decreases the significance and value of the feedback, and then the feedback reports either send rarely or not at all [3, 4, 8, 9]. B. Storage challenge The group size could be known if every member stores a count of distinct for every member it heard during the session using the unique Synchronization Source identifier (SSRC) found in the RTP header [3, 4, 8, 9]. C. Multicasting RRs to the whole group (bandwidth effect) Every member in the session group will multicast RRs (Receiver Report) to all other which are not senders and that causes a load at every member processing and Congestion will happen because of members increase then RR increase also[4, 8, 9, 10]. D. Initial/bye flood challenge If many members join/leave the session at the same time, a flood of join/Bye packets will happen and congestion in the network may occur, especially at members who have low bandwidth links [3, 4, 5, 8, 9]. El-Merakby tried to explain that the normal case for RTCP feedback reports are multicast mainly for receivers to calculate the group size and thus compute their RTCP reporting interval, and the suggested solution is saying that the members do not need to compute the whole size of the multicast group and RRs are not multicast, and to divide the big session to many groups. The proposed structure is called S-RTCP, and shown in Fig 1, explains how members organize dynamically in a multi-level hierarchy of local regions.

The following are the advantages of using the scheme in large RTCP groups [4, 8, 9]: • Resolving the storage scalability problem: Members do not need to store the state of the distinct member in the group because they are in a different small group size. Timely reporting of feedback reports: Feedback reports become more useful because the number of members became less. Effective use of the bandwidth: the formation of local regions where RRs are not multicast but are sent with limited scope and not global scope decrease the number of RRs. Decrease in the number of redundant reports: the total number of redundant RRs, which used to be multicast, is decreased, because the measurements in RRs are aggregated into AGRs summarizing the quality of the received data.

In the other side, another researcher was interesting in the same area, Julian from University of Cambridge. He published an article with title “An Extensible RTCP Control Framework for Large Multimedia Distributions” in 2003. Julian thought that is two serious challenges with RTCP and they are: the growing of using unidirectional and asymmetric broadcast architectures, and the second challenge: per-receiver RTCP reporting frequency diminishes prohibitively due to the bandwidth-sharing algorithm [2]. A. The growing deployment of unidirectional and asymmetric broadcast architectures challenge In RTP/RTCP, the data and control share a many-to-many communication channel, such as that provided by IP multicast [11]. The unidirectional and asymmetric broadcast architectures have problems with these issues; instead the channel allows not only the bidirectional flow of communication from sources to receivers and vice-versa, but also direct receiver-to-receiver communication over a single channel [2, 11]. B. Per-receiver RTCP reporting frequency diminishes prohibitively due to the bandwidth-sharing algorithm RTCP is keeping the frequency of reports inversely proportional to the number of members. And because of that RTCP institutes a bandwidth-sharing algorithm that divides the resources of the control channel among members’ group. The standard bandwidth-sharing algorithm used by RTCP expects that as groups grow in size, the frequency of individual feedback reports will decrease [2]. This problem is the same challenge that introduced by El-Merakby, 1998 with a challenge title Feedback delay challenge [4]. To solve these challenges, two new schemes are devised that are complementary to the existing RTCP feedback algorithm and influence the unique characteristics of summaries to efficiently scale the feedback of the unicast backchannel for large groups. The two schemes that influence summarization to scale the backchannel: biasing and hierarchical aggregation [2].

Figure 1. Structure of El-Merakby scheme [9].

Each region has an aggregator (AG). Each member sends the RR feedback to its AG which gathers and aggregates statistics from these reports which is passed to a manager or to another AG level. Additional statistics are computing by the manager to evaluate the transmission quality and to estimate the regions which suffer from congestion. Time-to-Live (TTL) field in the IP header is used by the scheme to build the multilevel hierarchy with locally scoped regions [4, 8, 9].

58

http://sites.google.com/site/ijcsis/ ISSN 1947-5500

• •

(IJCSIS) International Journal of Computer Science and Information Security, Vol. 8, No. 8, November 2010

The technique of biasing provides preferential treatment to the feedback of one or more groups of receivers. The technique of hierarchical aggregation supports the existence of multiple summarization nodes throughout a collection topology, which distributes the load and bandwidth usage of summarization, and in turn lends much-needed support to heterogeneous topologies as well as to frequency-driven applications.

The MS-RTCP managers join the control multicast group, while the MS-RTCP children join the data multicast group. Each group of children constructs a region which is controlled by a manager. Each child should know its region before sharing the RTP session. The Load Balancing Manager (LBM) accomplishes this target by testing the real position of each child and the real number of children per region. The scheme structure is shown in Fig. 2.

In 2005, another researcher was interesting in scalability of RTCP, but instead of studying the main RTCP protocol. He decided to study S-RTCP (Scalable Real Time Protocol) that invented by El-Marakby [4, 8,9], Elramly published two papers “Scalability Solutions For Multimedia Real-Time Control Protocol (PDPTA'06)” 2005, and “Analysis, Design, and Performance Evaluation of MS-RTCP: More Scalable Scheme for the Real-Time Control Protocol” 2005. Elramly introduced a new protocol MS-RTCP (More Scalable Real Time Control Protocol). MS-RTCP scheme is based on a hierarchical structure, distributed management, and EL-Marakby scheme. The idea of El-Marakby scheme is depending on a tree-based hierarchy of report summarizers. The tree leafs (nodes) in the session send RRs to some node that acting as AG (aggregator), collects and summarizes these reports. The summaries result then passed up to the next highest level in the tree, until finally they reach the sender or some other appropriate feedback point. The summarization scheme is most useful when the nodes at one level of a sub-tree see similar network performance. ElMarakby uses network hop counts to a summarizer, measured through Time To Live (TTL), to group hosts together in the tree. She also proposed a dynamic scheme for building the tree [4, 8, 9, 12, 13]. The most important introduced problems by Elramly to El-marakby scheme (S-RTCP): 1. Fault tolerance is not guaranteed: When any AG is crashed or has left the RTP session, all the children in its region search for other AG. This will affect the convergence time during this interval, and will make an old child to a new one. Load balancing is not guaranteed: The load balancing depends on the maximum number of children with which the AGs deals. This is not sufficient, because if we suppose that the maximum number of each AG is 100 children, we may find AG has 90 children and another has 10 children. The structure of the model depends on the central processing unit (manager). Hence, if the manager is crashed there is no other unit that can take place. The model in this case will become unstable (failed in worst case). Overkill the small groups, which the IP telephone is mainly dealing with. This is due to the condition of low children number per AG that was put after the model evaluation [8]. Election of LAN Aggregator (LAG) is not sufficient. Source Description (SDES) items [1] about any multicast group member will take a long time to access it.
Figure 2. General view of Elramly schem [13].

2.

3.

4.

5.

The suggested solution and the proposed protocol MS-RTCP: 1. Fault tolerance guarantee: any control component in the MS-RTCP has a spare one. If one or more scheme components fail, can replace the failed one with its spare one by the decision from the GM (or FTM) until the failed one is fixed and the normal situation is re-established. 2. Load balancing guarantee: the decision for receiving a new child in the RTP session depends on the real number of children per scheme manager. Consequently, if any new child joins a session, it is told with the best manager taking in consideration the manager load (real children number) and the new child position. 3. The basic idea of the MS-RTCP is based on the management distribution. So, the central management processing is eliminated, as the scheme has one manager for each management process. 4. The maximum number of children per manager reaches the upper limit at which the RTP session is working safely (some hundreds or more). Hence, if a small group joins the RTP session, the MS-RTCP will be transformed to the simple RTCP view with one manager and it’s spare. The other MS-RTCP managers will be found, but with minimal overhead (neglected values).

59

http://sites.google.com/site/ijcsis/ ISSN 1947-5500

(IJCSIS) International Journal of Computer Science and Information Security, Vol. 8, No. 8, November 2010

5.

6.

The LAN Manager (LAN-M) has its pre-determined spare component. So, in this scheme, no need to elect another LAN-M when the basic one fails. The GM can access any data about any MS-RTCP entity by requesting the SDESM (or by CDM in case of any problem happened for the SDES-M).

In Brno University of Technology, Czech Republic, 2007, new researchers work with scalability of RTCP. Dan Komosny, and Vit Novotny, started to study scalability of RTCP and its challenges. They published three papers together, “Tree Structure for Source-Specific Multicast with Feedback Aggregation” 2007, “Optimization of Large-Scale RTCP Feedback Reporting in Fixed and Mobile Networks” 2007, and “Large-Scale RTCP Feedback Optimization” 2008. The researchers find that RTCP in a large session causes delays in sending feedback data from each receiver, and to solve this problem they proposed a hierarchical structure and new protocol called Tree Transmission Protocol (TTP). Their work more to be extended to Julian 2003[2], where they solve some of the hierarchical structure that proposed by Julian 2003. The Fig. 3 is shown the tree structure [14, 15, 16, 17].

Dan Komosny, and Vit Novotny come out with: 1. Solve round trip delay by suggestion tree structure. 2. The problem of the RTCP feedback tree establishment was solved. 3. The method for finding the nearest summarization node in the IP network structure was designed. 4. To manage the tree the new protocol (TTP) was designed and specified. Shaahin Shahbazi comes with two papers about RTCP scalability, “A new design for improvement of scalable-RTCP” 2009, and “Error Resistant Real-Time Transport Control Protocol” 2009. As Elramly 2005, he preferred to deal with ElMarakby protocol (Scalable Real Time Control protocol) SRTCP. Shahbazi explained about the challenges associated with S-RTCP, and proposed different approaches to solve the challenges [18, 19, 4, 8 ,9]. A. The S-RTCP challenges • • • Congestion: If the number of AGs becomes very big of AG-0, congestion may occur at the links connected to AG-0. Overload: because of the same reason overload may happen. Lack of error-tolerance: S-RTCP design is quite vulnerable to any sort of malfunctions within AG-0.

B. Proposed Design for Stability Improvement problems are caused due to the singularity of AG-0 in S-RTCP’s design and also the fact that no precautions have been taken into account in case AG-0 fails [18]. See Fig. 5. • •
Figure 3. Tree topology of the RTCP feedback network [17].

To solve the problem of hierarchical structure organization new protocol has been proposed TTP (Tree Transmission Protocol), this protocol is quite a flexible and robust protocol use to organizing the hierarchical tree overlays. It can be used for any hierarchically organized protocols. It can work for simple hierarchical tree overlays as well as for large-scale overlays with many hierarchical levels. The fig 4 shows TTP position [15, 16].

The number of AG-0 nodes: fix the amount of AG-0s at two. Mirrored tasks versus split tasks: all AG-0s receive the same information. Existence of pre-assigned AG-0: new design will allow two or more AG-0s to operate within the session, in order to provide stability.

Figure 5. The architecture of the modified version of S-RTCP [18] Figure 4. Position of TTP to related protocols [16].

Shahbazi was designed a new proposed scheme ER-RTCP (Error Resistant Real-Time Transport Control Protocol). Modifications included designing the multi-manager scheme,

60

http://sites.google.com/site/ijcsis/ ISSN 1947-5500

(IJCSIS) International Journal of Computer Science and Information Security, Vol. 8, No. 8, November 2010

improving parent-seeking procedures, reducing distribution of request packets, reforming the design to be independent of TTL, adding methods to check on sanity of manager nodes. This study considered packet loss ratio of below 2% as desirable [18, 19]. See Fig. 6.

IV.

COMPARISON BETWEEN RESEARCHERS’ WORK

The comparison can be show in Table 1. V. SUMMARY

RTCP protocol has some problems and many researchers studied to solve it specially the scalability issue, the main problem was with the limitation of bandwidth space that given to RTCP reports, which all the researcher come with tree structure as a solution for it but in different ways.

Figure 6. The architecture of ER-RTCP [19]

TABLE I. Researcher Period of studies 1234561234123456781234512345-

COMPARISON BETWEEN RESEARCHERS’ WORK

Problems that solved The research studied RTCP. Feedback delay. Increasing storage state. Multicasting RRs congestion. Flood (Initial/Bye). Come out with tree structure. The research studied RTCP. Unidirectional and asymmetric broadcast architectures problem. Bandwidth-sharing algorithm. Come out with tree structure. The research studied S-RTCP. Fault tolerance is not guaranteed. Load balancing is not guaranteed. The structure of the model depends on the central processing unit. Overkill the small groups. Election of LAN Aggregator (LAG) is not sufficient. Source Description (SDES) items. Come out with tree structure. The research studied RTCP. Round trip delay. The RTCP feedback tree establishment. Finding the nearest summarization node in the IP network structure. Come out with tree structure. The research studied S-RTCP. Congestion. Overload. Lack of error-tolerance. Come out with tree structure.

New suggested protocol

El-Marakby

1998, 2000, 2003, 2005

S-RTCP

Julian Chesterfield

2003

-

El-Ramly

2005

MS-RTCP

Dan Komosny, & Vit Novotny

2007, 2008

TTP

Shaahin

2009

ER-RTCP

61

http://sites.google.com/site/ijcsis/ ISSN 1947-5500

(IJCSIS) International Journal of Computer Science and Information Security, Vol. 8, No. 8, November 2010

ACKNOWLEDGMENT

I would like to thank National Advanced IPv6 Center (NAv6), Universiti Sains Malaysia for their support that enabled me to complete this work.
REFERENCES
[1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP - A Transport Protocol for Real-time Applications," RFC 3550 (STD 64), July 2003. J. Chesterfield, E. M. Schooler “An extensible RTCP control framework for large multimedia distributions”, 2003. J. Rosenberg, H. Schulzrinne, Timer reconsideration for enhanced RTP scalability, Proceedings of IEEE Infocom’98, San Francisco, CA, 1998, pp. 233–241. R. El-Marakby, D. Hutchison, A scalability scheme for the real-time control protocol, Proceedings of IFIP TC-6 Eighth International Conference on High Performance Networking (HPN’98), Vienna, 1998, pp.153–168. J. Rosenberg, H. Schulzrinne, Timer reconsideration for enhanced RTP scalability, Proceedings of IEEE Infocom’98, San Francisco, CA, 1998, pp. 233–241. T. Friedman, R. Caceres, A. Clark "RTCP Reporting Extensions", RFC 3611, 2003. J. Rosenberg, H. Schulzrinne, New Results in RTP Scalability, IETE, 1997, Internet draft: draft-ietf-avt-byerecon-00.ps R. El-Marakby, Design and performance of a scalable real time control protocol: simulations and evaluations, Proceedings of the Fifth IEEE Symposium on Computers and Communications (ISCC’2000), AntibesJuan Les Pins, France, 2000, pp.119–124. Randa El-Marakby, David Hutchison: Scalability improvement of the real-time control protocol, Computer Communications 28 (2005) 136– 149. B. Aboba, Alternatives of enhancing RTP scalability, IETF, 1996, Internet draft: draftaboba-rtpscale-02.txt. S. Deering. Host extensions for IP multicasting. Request for Comments 1054, Internet Engineering Task Force, Aug. 1989 O. Essa, N. El-Ramly, and H. Harb, "SCALABILITY SOLUTIONS FOR MULTIMEDIA REAL-TIME CONTROL PROTOCOL (PDPTA'06), 2005. N. Elramly, A. Habib, O. Essa, and H. Harb, "Analysis, Design, and Performance Evaluation of MS-RTCP: More Scalable Scheme for the Real-Time Control Protocol," Journal of Universal Computer Science, vol. 11, pp. 874-897, 2005. V. Novotný, D. Komosný, “Optimization of Large-Scale RTCP Feedback Reporting in Fixed and Mobile Networks”. Proceedings of international scientific conference ICWMC2007(the third International Conference on Wireless and Mobile Communications), March 2007, pp. 1 – 6, ISBN: 0-7695-2796-5, Guadeloupe, 2007 D. Komosny and V. Novotny, "Tree structure for source-specific multicast with feedback aggregation," 2007, pp. 0-7695. R. Burget, D. Komosny, and M. Simek, "Transmitting Hierarchical Aggregation Information Using RTCP Protocol," IJCSNS, vol. 7, pp. 11-44, 2007. V. Novotn and D. Komosn, "Large-scale RTCP feedback optimization," Journal of Networks, vol. 3, p. 1, 2008.

[18] S. Shahbazi, K. Jumari, and M. Ismail, "A new design for improvement of scalable-RTCP," 2009, pp. 594-598. [19] S. Shahbazi, K. Jumari, and M. Ismail, "Error Resistant Real-Time Transport Control Protocol," Am. J. Engg. & Applied Sci, vol. 2, pp. 620-627, 2009. AUTHORS PROFILE Adel Nadhem Naeem: He completed his bachelor degree in computer science in 2004 from Shat Al-Arab University College, worked as IT in Iraqna Telecommunications Company from October 2004 until June 2007, started his master's degree in July 2007 in computer science school, USM , and completed it in August 2008, now he is a PhD candidate in National Advance IPv6, USM. He is one of the researchers that help to develop and improve the communications and networking field, working in multimedia conferencing area. Ali Abdulqader Bin Salem: received B.S (computer science) degree from Al-Ahgaff University, Yemen in 2006 and M.S (computer science) from University Science Malaysia (USM), Malaysia in 2009. Currently, he is a PhD student at National Advance IPv6 Center (NAv6), (USM). His current research interests include wireless LAN, multimedia QoS, and video transmission over wireless, distributed system, P2P, and client-server architecture. Mohammed Faiz Aboalmaaly : A PhD candidate, He received his bachelor degree in software engineering from Mansour University College (IRAQ) and a master’s degree in computer science from Univeriti Sains Malaysia (Malaysia). His PhD. research is mainly focused on Overlay Networks. He is interested in several areas of research such as Multimedia Conferencing, Mobile Ad-hoc Network (MANET) and Parallel Computing. Professor Dr. SureswaranRamadass: is a Professor and the Director of the National Advanced IPv6 Centre of Excellence (NAV6) at UniversitiSains Malaysia. Dr. Sureswaran obtained his BsEE/CE (Magna Cum Laude) and Masters in Electrical and Computer Engineering from the University of Miami in 1987 and 1990 respectively. He obtained his PhD from UniversitiSains Malaysia (USM) in 2000 while serving as a full time faculty in the School of Computer Sciences. Dr. Sureswaran's recent achievements include being awarded the AnugerahTokoh Negara (National Academic Leader) for Innovation and Commercialization in 2008 by the Minister of Science and Technology. He was also awarded the Malaysian Innovation Award by the Prime Minister in 2007. Dr. Sureswaran is also the founder and headed the team that successfully took Mlabs Systems Berhad, a high technology video conferencing company to a successful listing on the Malaysian Stock Exchange in 2005. Mlabs is the first, and so far, only university based company to be listed in Malaysia.

[2] [3]

[4]

[5]

[6] [7] [8]

[9]

[10] [11] [12]

[13]

[14]

[15] [16]

[17]

62

http://sites.google.com/site/ijcsis/ ISSN 1947-5500

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->