INTERNET-DRAFT Bernard Aboba Microsoft Corporation Alternatives for Enhancing RTCP Scalability 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). The distribution of this memo is unlimited. It is filed as , and expires August 1, 1997. Please send com- ments to the authors. 2. Abstract This document discusses current issues with RTCP scalability as well as describing the advantages and disadvantages of possible solutions. 3. Requirements In evaluating a solution to the RTCP scaling problem, it is important to have an understanding of the requirements that a proposed solution must meet. This document proposes four requirements: Decrease in convergence time Decrease in forwarding table entries Improvement in receiver reporting information Ability to adjust RTCP bandwidth fraction 3.1. Decrease in convergence time Currently RTCP relies on multicasting of receiver reports to establish a receiver-population estimate. This shared-state is then used by receivers to establish the receiver reporting interval. The RTCP reporting algorithm described in [1], provides for an initial RTCP reporting interval randomized on [1.25,3.75]. While the use of a Aboba [Page 1] INTERNET-DRAFT 28 January 1997 minimum waiting time for the initial report allows a receiver to lis- ten for other reports prior to sending, the reporting algorithm described in [1] does not mandate this. As a result, reporting hosts not implementing reconsideration (in which the reporting interval is readjusted prior to sending receiver reports) will send their reports within the initially calculated interval, resulting in a potential flood of initial reports. 3.2. Decrease in forwarding table entries As defined in [1], RTCP messages are sent on the same group as the original RTP transmission, but on adjacent ports. This is problematic for multicast routing protocols such as sparse mode PIM, which deter- mine whether a given group will be hosted on the shared tree or source tree based on the sending rate. If an RTP group is placed on the source tree, then if RTCP messages are sent to the same group, then each host sending RTCP receiver reports will result in a forwarding table entry. However, it should be noted that even if a shared-tree routing proto- col (such as CBT) is used, a problem will still exist when such a domain is connected to a source-tree domain using a routing protocol such as MOSPF or DVMRP. This is because today there is no mechanism for a multicast area border router to summarize RTCP activity within a multicast routing domain. Therefore if a shared tree domain is con- nected to another domain (such as a DVMRP domain) then packets from each RTCP source within the shared tree domain will need to be for- warded into the source tree domain. This problem is very common given that DVMRP functions today as the MBONE's multicast routing protocol. DVMRP generates forwarding cache entries on demand for each (source network, destination group) pair, and supports source-specific prune messages. The typical forwarding cache expiration time is 200 seconds. Since for a large conference the RTCP reporting interval will typically exceed the forwarding cache expiration time shortly after conference initiation, only a portion of all (source network, destination group) pairs would be cached by a DVMRP implementation at a given time. Nevertheless, the router will expend considerable resources in adding and flushing forwarding cache entries, as well as in responding to source-specific prune requests. While future versions of DVMRP may prove more scalable, it is unlikely that these versions will be widely deployed within the next 18 months. As a result, summarization messages are desirable in multicast routing protocols, as well as a decrease in the number senders on the RTCP group. 3.3. Improvement in receiver reporting information The RTCP receiver report mechanism provides important information on listenership, reception quality, and bandwidth availability. This information is important useful both for engineering and business pur- poses. Engineers use reception quality information to diagnose Aboba [Page 2] INTERNET-DRAFT 28 January 1997 problems with the network. Sending systems can use reception quality and bandwidth availability information to modify transmission parame- ters such as compression ratio and sending rate. Business people use information on listenership to track the size of the audience, and reception quality information to measure the quality of the user expe- rience. Since in large conferences the algorithm described in [1] leads to infrequent receiver reporting, it can be argued that it does not meet the requirements for timely receiver reporting. Therefore any scaling "improvement" should not hamper the ability to collect this informa- tion, and probably should be expected to result in improved reporting. 3.4. Ability to adjust RTCP bandwidth fraction In low or asymmetric bandwidth situations, the fraction of session bandwidth reserved for RTCP may need to be decreased below the five percent specified in [1]. For example, in Cable Internet it is common for downstream bandwidth to be a factor of twenty greater than upstream bandwidth; allowing five percent of downstream bandwidth to be used for receiver reporting upstream would result in congestion of the upstream channel. In such situations it is necessary to allow the bandwidth fraction to be adjusted. 4. Scaling alternatives Several alternatives have been proposed for improving the scalability of RTCP. These include: Turning off RTCP receiver reports Improved convergence algorithms Use of separate multicast groups for RTP and RTCP Use of separate multicast groups for receiver and sender reports Unicasting of receiver reports Selective reporting Use of RTCP BYE messages Use of TTL scoping and summary messages Use of RTP translators These alternatives are discussed in turn. 4.1. Turning off RTCP receiver reports In some applications (such as satellite transmission) there may be no upstream channel for transmission of RTCP receiver reports. As a result, it may be desirable to allow receiver reporting to be turned off. Since there is no receiver reporting, there would be no way to estimate the receiver population. Influence on RTCP receivers could be exercised via the SDP announce- ment mechanism. For example, Mark Handley has proposed that the Aboba [Page 3] INTERNET-DRAFT 28 January 1997 session profile specified in SDP via the "m=" line be used to define the desired RTCP behavior. This would allow for turning off of RTCP receiver reports, or other modifications to reporting behavior. While this proposal would eliminate problems relating to RTCP band- width usage in dialup and asymmetric systems, it would deprive inter- ested parties of information on listenership and reception quality. This will prevent senders from making adjustments to their transmis- sion parameters, and would also prevent RTP monitors from providing listenership estimates needed to justify advertising rates. However, it is not clear that these arguments are persuasive in all cases. RTCP receiver reports serve multiple purposes. One of these is to provide information on listenership; another is to provide informa- tion on reception quality and bandwidth availability. In some Cable Internet systems, it is possible to gain information on listenership via IGMP join and leave messages, since if the upstream and downstream channels are separated receivers do not necessarily hear each other's join or leave messages. Furthermore, it can be argued that the state of multicast diagnostics will eventually reach the point where RTCP receiver reports will no longer needed for diagnostic purposes. Where receiver-based rate adjustment is used, there may not be a need for the sender to adjust their transmission parameters. 4.2. Improved convergence algorithms Just as non-linear equation solvers can benefit from improved algo- rithms, it may be possible to improve RTP receiver population esti- mates via improvements in the population estimation algorithm. Improvements include reconsideration, as well an initial population estimate, and the incorporation of additional information into the calculation. The idea behind reconsideration, first proposed by Van Jacobson, is to improve the convergence time by calculating a new estimate of group size and reporting interval prior to sending the RTCP report. The report is only sent if the updated estimate is less than or equal to the original estimate; otherwise the report is not sent and the reporting interval is adjusted to the new estimate. Use of reconsid- eration greatly reduces the number of initial reports, since a host joining a conference already in progress will be brought to equilib- rium prior to sending its first report. As a result, implementation of reconsideration should be made mandatory in future versions of the RTP specification. In certain circumstances, it may desirable to increase the dampening effect of reconsideration by increasing the initial minimum reporting interval. This will decrease the number of initial reports from sites with long delays, i.e. sites with a satellite downlink and POTS or ISDN uplink, as well as to decrease the effect of sites reporting early merely due to statistical considerations. Aboba [Page 4] INTERNET-DRAFT 28 January 1997 Currently the receiver population estimate has an initial value of 1, but it is possible for an initial population estimate to be supplied in the session announcement. Successive population estimates could then be derived via an averaging of the initial estimate and the receiver's own estimate, so that the effect of the initial estimate would die out over time. However, as in nonlinear equation solving, use of an initial estimate is only helpful if it accurate and the ini- tial estimate is likely to prove less important than the algorithm which drives the system to steady state. While an improved initial population estimate would result in improved convergence times, were the initial estimate to be way off, convergence might be hindered. The rate of convergence may be improved by allowing the receiver to use information on the rate at which receiver reports are being sent. For example, due to bandwidth limitations, receivers on higher band- width connections have greater knowledge of the overall receiver popu- lation. Thus if a receiver were to note a receiver report from a sys- tem with high bandwidth availability, that report could be weighed more heavily in determining the overall population estimate. It is also possible to incorporate the overall receiver reporting rate into the reporting interval calculation. For example, if my current population estimate results in a receiver reporting interval of 3 min- utes, and I am receiving 200 receiver reports/minute, it may be desir- able to incorporate the rate of receiver reports into my calculations, increasing the reporting interval accordingly. However, the utility of taking rate information into account is lim- ited in the case of dialup clients, since they will only be able to receive a modest number of receiver reports/minute, and thus the rate at which receiver reports are flowing in may not be reflective of the overall receiver population. While improved convergence algorithms can result in marked improve- ments in convergence times, and do result in more accurate population estimates, they do not result in a lower number of forwarding table entries or senders to the RTCP receiver report group. They also do not influence the steady state bandwidth usage for RTCP reporting. 4.3. Use of separate multicast groups for RTP and RTCP Use of separate multicast groups for RTP and RTCP results in improved scalability for multicasting routing protocols such as sparse mode PIM, since the RTCP group can be placed on the shared tree due to its low sending rate. While this would markedly decrease the number of forwarding cache entries, the router will nevertheless expend consid- erable resources in adding and flushing forwarding cache entries, and setting up the individual hosts on the shared tree. For this reason, we do not believe that moving RTCP to an adjacent group will be suffi- cient for very large conferences. Note also that using an adjacent group for RTCP does not improve the scalability for DVMRP, the MBONE multicast routing protocol, since this protocol has no notion of a shared tree. Aboba [Page 5] INTERNET-DRAFT 28 January 1997 Use of separate multicast groups for RTP and RTCP does not affect con- vergence times or affect reporting accuracy. It also does not influ- ence the steady state bandwidth usage for RTCP reporting. 4.4. Use of separate multicast groups for receiver and sender reports Currently RTCP sender and receiver reports are sent to the same multi- cast group, and both RTP senders and receivers join this group. Were sender and receiver reports to be multicast on different groups, RTP receivers could be allowed to only join the sender report group, thus allowing them to avoid listening to receiver report traffic. RTP senders would still join both groups in order to receive feedback on listenership and transmission quality, and would need to provide information on the estimated receiver population within the sender reports. While this proposal would lessen the problem for receivers, it would not improve things for senders, and might even make them worse. Since receivers would not longer be able to implement reconsideration as effectively, it would be likely that the senders would be deluged with initial receiver reports. Use of separate groups for receiver and sender reports would not result in a lower number of senders on the RTCP receiver report group, although it would decrease the number of forwarding table entries in protocol such as sparse mode PIM. This proposal would eliminate the bandwidth used by receivers for incoming RTCP reports, but would not address the problem with upstream band- width usage in asymmetric networks. 4.5. Unicasting of receiver reports Instead of multicasting receiver reports, it is possible to unicast them back to the senders. This would allow RTP listeners to avoid receiver report traffic, while RTP senders would still receive feed- back on listenership and transmission quality. In order to control the receiver report transmission rate, senders would need to provide information on the estimated receiver population within sender reports. While this proposal would lessen the problem for receivers, as with the previous proposal, it might make things worse for senders, since receivers would no longer be able to reconsider as effectively. How- ever, it would eliminate multicasting of RTCP receiver reports, which will be of benefit to overtaxed routers. This proposal would eliminate the bandwidth used by receivers for incoming RTCP reports, but would not address the problem with upstream bandwidth usage in asymmetric networks. Aboba [Page 6] INTERNET-DRAFT 28 January 1997 4.6. Selective reporting In selective reporting, RTCP receiver reports are only sent by selected hosts. This method results in a reduction in the number of RTCP senders, with attendant reduction in the forwarding tables. It also is likely to result in lower convergence times. Assuming that the statistical sampling was adequate, the accuracy and timeliness of reporting need not be adversely affected. However, this method does not affect the steady state bandwidth allocated to RTCP. The selection can occur via a polling or random selection mechanism, or it can occur by self-selection. Generally, random selection is pre- ferred since self-selection brings with it the possibility of report- ing implosions. For example, if receiver reports were only generated when packet loss exceeded a given threshold, then congestion and attendant packet loss would result in a large number of reports, mak- ing the situation worse. Polling or random selection methods, while they show considerable promise, need to address security concerns. For example, if it is pos- sible to get receivers to respond via a polling message, then that message should be authenticated to prevent leveraged denial of service attacks. 4.7. Use of RTCP BYE messages Given that receiver reporting intervals will tend to be very long for large conferences, it can be argued that absent an emergency, it makes sense to provide information on listenership, reception quality and bandwidth availability within the RTCP Bye message. Thus on leaving the conference, the receiver would send a message providing informa- tion on the time period in which they joined the conference, the over- all reception quality and other information. Conventional receiver reports would then either not be sent at all, or would be sent with a TTL of 1. While such an approach would lessen the congestion problem at the beginning of a session, it would increase the size of the RTCP BYE message, resulting in a spike in RTCP bandwidth consumption at the end of a session. Given that no receiver population estimate would be available, it appears that this approach could actually worsen conver- gence times, unless it were combined with some kind of summarization mechanism. It would also not reduce the number of RTCP senders, or reduce the steady state RTCP bandwidth fraction. 4.8. Use of TTL scoping and summary messages In this approach, RTCP receiver reports would be sent with a TTL of 1, and a designated summarizer would be elected to provide summary reports with a larger TTL. This approach has the advantage of increas- ing the leverage of those RTCP receiver reports that are sent, and is likely to be particularly effective for conferences in which member- ship is densely distributed. However, in sparsely distributed confer- ences, the effect of summarization will be small unless multiple Aboba [Page 7] INTERNET-DRAFT 28 January 1997 levels of summarization are used. The designated summarizer would not necesarily be a router; it could also be another receiver, although this brings up the possibility of how a new summarizer could be elected if the current summarizer leaves the conference. Since in this scheme receiver reports are not forwarded, non-summariz- ing RTP receivers should use the population estimate gleaned from local scope reports to calculate their reporting interval. Summarizers and RTP senders will then use global estimates gleaned from global scope summary reports to calculate their reporting interval. A recom- mended bandwidth allocation for reporting is 25 percent for sender reports, 25 percent for summary reports, and 50 percent for receiver reports. Since this proposal decreases the scope of RTCP announcements, it would substantially reduce the number of RTCP senders visible to the multicast backbone, and would decrease convergence times, since those messages that were sent would include more information on the receiver population. This proposal would also address the problems of intercon- necting multicast routing domains, since the multicast area border router would be able to summarize RTCP behavior within its domain, rather than passing along all RTCP reports. However, it would also require substantial modifications in RTP client behavior. 4.8.1. Summary reports Via the use of summary reports, privacy can be provided while simulta- neously providing senders with improved listenership and receiver quality reporting. This is possible because in the existing implemen- tation much of the information gained from receiver reports is redun- dant. For example, if congestion results in packets being dropped on a particular link, then all receivers downstream from that link will report the problem. Redundant reporting obscures the information of greatest interest, which is information on global listenership and reception quality. Via introduction of summary reports, it is possible to provide more accurate and timely reporting on listenership and reception quality, as well as to address issues involved in connecting multicast routing domains. Information useful in summary reports would include: Total number of systems being summarized Packets received and lost Histogram of reception quality (fraction lost) Histogram of receiver bandwidth Information on users registering The total systems summarized number is used in order to provide for faster convergence times. Information on packets received and lost will typically be used by network engineers looking to diagnose prob- lems with the MBONE. The histograms of reception quality and receiver bandwidth are propagated in order to allow senders to deduce informa- tion relating to the global user experience. In order to allow for Aboba [Page 8] INTERNET-DRAFT 28 January 1997 location of individuals participating in a conference, the summarizer may wish to relay information on the users in the conference. Alterna- tively, it may register users in a directory service via use of the LDAP extensions defined in [4]. 4.9. Use of RTP translators Through the use of RTP translators, it is possible to divide RTP receivers into areas in much the same way as is accomplished by OSPF. Through the use of summary receiver reports, information on listener- ship and receiver report quality can be propagated between areas while reducing RTCP bandwidth usage and the RTCP sending population on the MBONE. In order to insulate receivers within an area from external receiver reports, the RTP translator must filter external receiver reports, while allowing external summary reports and sender reports to pass through. Similarly, the RTP translator will listen to receiver reports generated from within its area, but will not pass them on to external areas. Instead, it would issue to external areas two types of summary reports. The first will be based on the packets it receives and will be identical to a conventional receiver report, except for the use of the summary report type; the second will be a true summary report based on area receiver reports. It is useful to allow receiver reports from RTP translators to pass through so as to allow diagnosis of internal distribution problems. The RTP translator will allow internal sender reports to pass through unmodified. The introduction of RTP translators has several advantages: Improved convergence of the receiver population estimate Decreased RTCP bandwidth Improved privacy Listenership and reception quality information available to senders While most of the above advantages are also available in the receiver summary approach, one advantage of the translator approach is that it provides for greater control by the network administrator. For exam- ple, since summary reports would be sent by RTP translators rather than by client summarizers, it would be possible for administrators to control the propagation of user information on a site-by-site basis, rather than on a per-session basis. For example, rather than having this sent in the summary report, it could be stored as a temporary attribute in the area directory server. This may be perceived as a substantial advantage by corporations looking to control access to directory information. For those cases where it is desirable to allow external access to area registration information, the IP address of the area directory server may be advertised in the summary report. This allows senders with appropriate privileges to retrieve conference registration data from the area directory server via LDAP. The RTP translator approach also has several major disadvantages. These include: Aboba [Page 9] INTERNET-DRAFT 28 January 1997 Requires modifications to routers Increases loading on routers that now must function as RTP translators 5. Acknowledgements Thanks to Steve Casner of Precept, Mark Handley of ISI, Bob Hinden of Ipsilon and Thomas Pfenning, Peter Ford and Stefan Solomon of Microsoft for useful discussions of this problem space. 6. References [1] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. "RTP: A Transport Protocol for Real-Time Applications." RFC 1889, GMD Fokus, January 1996. [2] H. Schulzrinne. "RTP Profile for Audio and Video Conferences with Minimal Control." RFC 1890, GMD Fokus, January 1996. [3] M. F. Speer, S. McCanne. "RTP Usage with Layered Multimedia Streams." draft-speer-avt-layered-video-01.txt, Sun Microsystems, LBNL, June 1996. [4] Y. Yaacovi, M. Wahl, K. Settle, T. Genovese. "Lightweight Direc- tory Access Protocol: Extensions for Dynamic Directory Services." draft-ietf-asid-ldapv3ext-02.txt, Microsoft, Critical Angle, October, 1996. 7. Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 206-936-6605 EMail: bernarda@microsoft.com Aboba [Page 10]