(IJCSIS) International Journal of Computer Science and Information Security,Vol. 8, No. 8, November 2010
S
URVEY
:
RTCP
F
EEDBACK IN A
L
ARGE
S
TREAMING
S
ESSIONS
Adel Nadhem Naeem
1
, Ali Abdulqader Bin Salem
2
Mohammed Faiz Aboalmaaly
3
and
Sureswaran Ramadass
4
National Advanced IPv6 CentreUniversiti Sains MalaysiaPinang, Malaysia
Abstract
—RTCP has limitation with scalability for largestreaming sessions; because of the limitation of the bandwidthspace that given to RTCP reports. Many researchers studied andstill studying how to solve this limitation, and most of theresearchers come out with tree structure as a solution but in adifferent ways.
Keywords- RTCP/RTP; Scalability; Large Streaming Sessions
I.
I
NTRODUCTION
Communication is everywhere in our life and as a part of itis multimedia communication like, VoIP, multimediaconferencing, teleconferencing, video surveillance, satellitecommunication, etc. Multimedia communication is mainlyusing Real time protocol (RTP) that works together with Realtime control protocol (RTCP) to do transfer data that depend onreal time like video or audio over networks. RTCP is used tomonitor RTP-Packets and reports feedback [1]. The mainfunction of RTCP is to transmit periodically the sender andreceiver reports to all members in RTP/RTCP. These reportsallow a host to know if a problem exists or not and if theproblem is local or global [2]. RTCP like other protocols andtechniques facing a lot of problems, one of the importantproblems is RTCP scalability. [3] Increasing the number of hosts in RTP/RTCP sessions caused some problems under thename of the scalability problems; the problems can be thefeedback delay, storage problem, flood of initial/bye RTCPreports, etc.II.
S
CALABILITY OF
RTCPRTP 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 orderpackets, Time stamping so that data is played out at the rightspeeds [5]. RTCP is the attached protocol to RTP, and itsworking by sending/receiving reports, and it has several kindsof reports the main reports in RTCP are the sender
report (SR)and receiver report (RR). Both include performance statisticson the total number of packets lost since the beginning of transmission, the fraction of packet loss in the interval betweensending this feedback report and sending the previous one, thehighest sequence number received, jitter, and other delaymeasurements to calculate the round-trip feedback delay time.The SR provides more statistics summarizing data transmissionfrom 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 adaptiveapplications (The packet loss parameter in the RRs hasbeen used as an indicator of congestion in thenetwork).
•
The SR is useful in lip-synchronization (inter-mediasynchronization) and in calculating transmission bitrates.What does scalability mean when it uses with RTCP term,increase the number of hosts in one session then increase thenumber of RTCP report, which means RTCP scalability. RTCPis kind of reports' protocol that sends/receive reports from/tohosts in one session. These reports limited to bandwidth size,RTCP given 5% from the whole session bandwidth size. RTCPhas two types of the report: Sender report and Receiver report.Sender report uses 75% of RTCP bandwidth size whileReceiver report uses 25%. The limitation of bandwidth size of RTCP makes it control the interval of sending receivingreports, increasing the number of hosts caused to increase theinterval of sending receiving time and that makes the reportsuseless [6].III.
C
HALLENGES OF
RTCP
S
CALABILITY
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. Thescalability in RTCP faces many problems when it comes to agroup of thousands of users. Some of these problems areaddressed in [2 ... 11]. The first serious study done by El-Merakby, with three main researches 1998 “A ScalabilityScheme for the Real-time Control Protocol”, 2000 “Design andPerformance of a Scalable Real Time Control Protocol:Simulations and Evaluations”, and 2005 “Scalabilityimprovement of the real time control protocol” where shestudied RTCP problems with scalability and suggested asolution by divide the large session group to small sessiongroups [4, 8, 9].
57http://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 andcaused by increasing the group size, because of the limitationof the bandwidth size the RTCP reporting interval increasedwhich decreases the significance and value of the feedback, andthen 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 acount of distinct for every member it heard during the sessionusing 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 thatcauses a load at every member processing and Congestion willhappen 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, aflood of join/Bye packets will happen and congestion in thenetwork may occur, especially at members who have lowbandwidth links [3, 4, 5, 8, 9].El-Merakby tried to explain that the normal case for RTCPfeedback reports are multicast mainly for receivers to calculatethe group size and thus compute their RTCP reporting interval,and the suggested solution is saying that the members do notneed to compute the whole size of the multicast group and RRsare 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-levelhierarchy of local regions.
Figure 1. Structure of El-Merakby scheme [9].
Each region has an aggregator (AG). Each member sendsthe RR feedback to its AG which gathers and aggregatesstatistics from these reports which is passed to a manager or toanother AG level. Additional statistics are computing by themanager to evaluate the transmission quality and to estimatethe regions which suffer from congestion. Time-to-Live (TTL)field in the IP header is used by the scheme to build the multi-level hierarchy with locally scoped regions [4, 8, 9].The following are the advantages of using the scheme inlarge RTCP groups [4, 8, 9]:
•
Resolving the storage scalability problem: Members donot need to store the state of the distinct member in thegroup because they are in a different small group size.
•
Timely reporting of feedback reports: Feedback reportsbecome more useful because the number of membersbecame less.
•
Effective use of the bandwidth: the formation of localregions where RRs are not multicast but are sent withlimited scope and not global scope decrease the numberof RRs.
•
Decrease in the number of redundant reports: the totalnumber of redundant RRs, which used to be multicast,is decreased, because the measurements in RRs areaggregated into AGRs summarizing the quality of thereceived data.In the other side, another researcher was interesting in thesame area, Julian from University of Cambridge. He publishedan article with title “An Extensible RTCP Control Framework for Large Multimedia Distributions” in 2003. Julian thoughtthat is two serious challenges with RTCP and they are: thegrowing of using unidirectional and asymmetric broadcastarchitectures, and the second challenge: per-receiver RTCPreporting frequency diminishes prohibitively due to thebandwidth-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-manycommunication channel, such as that provided by IP multicast[11]. The unidirectional and asymmetric broadcastarchitectures have problems with these issues; instead thechannel allows not only the bidirectional flow of communication from sources to receivers and vice-versa, butalso direct receiver-to-receiver communication over a singlechannel [2, 11].
B.
Per-receiver RTCP reporting frequency diminishes prohibitively due to the bandwidth-sharing algorithm
RTCP is keeping the frequency of reports inverselyproportional to the number of members. And because of thatRTCP institutes a bandwidth-sharing algorithm that divides theresources of the control channel among members’ group. Thestandard bandwidth-sharing algorithm used by RTCP expectsthat as groups grow in size, the frequency of individualfeedback reports will decrease [2]. This problem is the samechallenge that introduced by El-Merakby, 1998 with achallenge title Feedback delay challenge [4].To solve these challenges, two new schemes are devisedthat are complementary to the existing RTCP feedback algorithm and influence the unique characteristics of summaries to efficiently scale the feedback of the unicastbackchannel for large groups. The two schemes that influencesummarization to scale the backchannel: biasing andhierarchical aggregation [2].
58http://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 treatmentto the feedback of one or more groups of receivers.
•
The technique of hierarchical aggregation supports theexistence of multiple summarization nodes throughout acollection topology, which distributes the load andbandwidth usage of summarization, and in turn lendsmuch-needed support to heterogeneous topologies aswell as to frequency-driven applications.In 2005, another researcher was interesting in scalability of RTCP, but instead of studying the main RTCP protocol. Hedecided to study S-RTCP (Scalable Real Time Protocol) thatinvented by El-Marakby [4, 8,9], Elramly published two papers“Scalability Solutions For Multimedia Real-Time ControlProtocol (PDPTA'06)” 2005, and “Analysis, Design, andPerformance Evaluation of MS-RTCP: More Scalable Schemefor the Real-Time Control Protocol” 2005. Elramly introduceda new protocol MS-RTCP (More Scalable Real Time ControlProtocol). MS-RTCP scheme is based on a hierarchicalstructure, distributed management, and EL-Marakby scheme.The idea of El-Marakby scheme is depending on a tree-basedhierarchy of report summarizers. The tree leafs (nodes) in thesession send RRs to some node that acting as AG (aggregator),collects and summarizes these reports. The summaries resultthen passed up to the next highest level in the tree, until finallythey reach the sender or some other appropriate feedback point.The summarization scheme is most useful when the nodes atone level of a sub-tree see similar network performance. El-Marakby uses network hop counts to a summarizer, measuredthrough Time To Live (TTL), to group hosts together in thetree. She also proposed a dynamic scheme for building the tree[4, 8, 9, 12, 13]. The most important introduced problems byElramly to El-marakby scheme (S-RTCP):1.
Fault tolerance is not guaranteed: When any AG iscrashed or has left the RTP session, all the children in itsregion search for other AG. This will affect theconvergence time during this interval, and will make anold child to a new one.2.
Load balancing is not guaranteed: The load balancingdepends on the maximum number of children with whichthe AGs deals. This is not sufficient, because if wesuppose that the maximum number of each AG is 100children, we may find AG has 90 children and another has10 children.3.
The structure of the model depends on the centralprocessing unit (manager). Hence, if the manager iscrashed there is no other unit that
can take place. The
model in this case will become unstable (failed in worstcase).4.
Overkill the small groups, which the IP telephone ismainly dealing with. This is due to the condition of lowchildren number per AG that was put after the modelevaluation [8].5.
Election of LAN Aggregator (LAG) is not sufficient.Source Description (SDES) items [1] about any multicastgroup member will take a long time to access it.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 controlledby a manager. Each child should know its region before sharingthe RTP session. The Load Balancing Manager (LBM)accomplishes this target by testing the real position of eachchild and the real number of children per region. The schemestructure is shown in Fig. 2.
Figure 2. General view of Elramly schem [13].
The suggested solution and the proposed protocol MS-RTCP:1.
Fault tolerance guarantee: any control component in theMS-RTCP has a spare one. If one or more schemecomponents fail, can replace the failed one with its spareone by the decision from the GM (or FTM) until the failedone is fixed and the normal situation is re-established.2.
Load balancing guarantee: the decision for receiving anew child in the RTP session depends on the real numberof children per scheme manager. Consequently, if anynew child joins a session, it is told with the best managertaking in consideration the manager load (real childrennumber) and the new child position.3.
The basic idea of the MS-RTCP is based on themanagement distribution. So, the central managementprocessing is eliminated, as the scheme has one managerfor each management process.4.
The maximum number of children per manager reachesthe upper limit at which the RTP session is working safely(some hundreds or more). Hence, if a small group joinsthe RTP session, the MS-RTCP will be transformed to thesimple RTCP view with one manager and it’s spare. Theother MS-RTCP managers will be found, but withminimal overhead (neglected values).
59http://sites.google.com/site/ijcsis/ISSN 1947-5500
Search History:
Result 00 of 00
00 results for result for
p.
Survey: RTCP Feedback In A Large Streaming Sessions
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.
420
Reads
0
Readcasts
0
Embed Views
Get Scribd Mobile
To get Scribd mobile enter your number and we'll send you a link to the Scribd app for iPhone & Android.We've sent a link to the Scribd app. If you didn't receive it, try again.
We'll never share your phone number.
More From This User
Notes
Load more
