idnits 2.17.1 draft-aboba-rtpscale-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 236 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 320 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 10 has weird spacing: '...), its areas...' == Line 11 has weird spacing: '... its worki...' == Line 15 has weird spacing: '... and may ...' == Line 19 has weird spacing: '... To learn...' == Line 21 has weird spacing: '...ctories on ...' == (231 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 481, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 484, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1889 (ref. '1') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 1890 (ref. '2') (Obsoleted by RFC 3551) == Outdated reference: A later version (-05) exists of draft-speer-avt-layered-video-01 -- Possible downref: Normative reference to a draft: ref. '3' -- No information found for draft-ietf-asid-ldapv3ext - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' Summary: 14 errors (**), 0 flaws (~~), 12 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Bernard Aboba 3 Microsoft Corporation 5 Alternatives for Enhancing RTCP Scalability 7 1. Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working docu- 10 ments of the Internet Engineering Task Force (IETF), its areas, and 11 its working groups. Note that other groups may also distribute work- 12 ing documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months 15 and may be updated, replaced, or obsoleted by other documents at any 16 time. It is inappropriate to use Internet-Drafts as reference material 17 or to cite them other than as ``work in progress.'' 19 To learn the current status of any Internet-Draft, please check the 20 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 21 Directories on ds.internic.net (US East Coast), nic.nordu.net 22 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 24 The distribution of this memo is unlimited. It is filed as , and expires August 1, 1997. Please send com- 26 ments to the authors. 28 2. Abstract 30 This document discusses current issues with RTCP scalability as well 31 as describing the advantages and disadvantages of possible solutions. 33 3. Requirements 35 In evaluating a solution to the RTCP scaling problem, it is important 36 to have an understanding of the requirements that a proposed solution 37 must meet. This document proposes four requirements: 39 Decrease in convergence time 40 Decrease in forwarding table entries 41 Improvement in receiver reporting information 42 Ability to adjust RTCP bandwidth fraction 44 3.1. Decrease in convergence time 46 Currently RTCP relies on multicasting of receiver reports to establish 47 a receiver-population estimate. This shared-state is then used by 48 receivers to establish the receiver reporting interval. The RTCP 49 reporting algorithm described in [1], provides for an initial RTCP 50 reporting interval randomized on [1.25,3.75]. While the use of a 51 minimum waiting time for the initial report allows a receiver to lis- 52 ten for other reports prior to sending, the reporting algorithm 53 described in [1] does not mandate this. As a result, reporting hosts 54 not implementing reconsideration (in which the reporting interval is 55 readjusted prior to sending receiver reports) will send their reports 56 within the initially calculated interval, resulting in a potential 57 flood of initial reports. 59 3.2. Decrease in forwarding table entries 61 As defined in [1], RTCP messages are sent on the same group as the 62 original RTP transmission, but on adjacent ports. This is problematic 63 for multicast routing protocols such as sparse mode PIM, which deter- 64 mine whether a given group will be hosted on the shared tree or source 65 tree based on the sending rate. If an RTP group is placed on the 66 source tree, then if RTCP messages are sent to the same group, then 67 each host sending RTCP receiver reports will result in a forwarding 68 table entry. 70 However, it should be noted that even if a shared-tree routing proto- 71 col (such as CBT) is used, a problem will still exist when such a 72 domain is connected to a source-tree domain using a routing protocol 73 such as MOSPF or DVMRP. This is because today there is no mechanism 74 for a multicast area border router to summarize RTCP activity within a 75 multicast routing domain. Therefore if a shared tree domain is con- 76 nected to another domain (such as a DVMRP domain) then packets from 77 each RTCP source within the shared tree domain will need to be for- 78 warded into the source tree domain. 80 This problem is very common given that DVMRP functions today as the 81 MBONE's multicast routing protocol. DVMRP generates forwarding cache 82 entries on demand for each (source network, destination group) pair, 83 and supports source-specific prune messages. The typical forwarding 84 cache expiration time is 200 seconds. Since for a large conference the 85 RTCP reporting interval will typically exceed the forwarding cache 86 expiration time shortly after conference initiation, only a portion of 87 all (source network, destination group) pairs would be cached by a 88 DVMRP implementation at a given time. Nevertheless, the router will 89 expend considerable resources in adding and flushing forwarding cache 90 entries, as well as in responding to source-specific prune requests. 91 While future versions of DVMRP may prove more scalable, it is unlikely 92 that these versions will be widely deployed within the next 18 months. 93 As a result, summarization messages are desirable in multicast routing 94 protocols, as well as a decrease in the number senders on the RTCP 95 group. 97 3.3. Improvement in receiver reporting information 99 The RTCP receiver report mechanism provides important information on 100 listenership, reception quality, and bandwidth availability. This 101 information is important useful both for engineering and business pur- 102 poses. Engineers use reception quality information to diagnose 103 problems with the network. Sending systems can use reception quality 104 and bandwidth availability information to modify transmission parame- 105 ters such as compression ratio and sending rate. Business people use 106 information on listenership to track the size of the audience, and 107 reception quality information to measure the quality of the user expe- 108 rience. 110 Since in large conferences the algorithm described in [1] leads to 111 infrequent receiver reporting, it can be argued that it does not meet 112 the requirements for timely receiver reporting. Therefore any scaling 113 "improvement" should not hamper the ability to collect this informa- 114 tion, and probably should be expected to result in improved reporting. 116 3.4. Ability to adjust RTCP bandwidth fraction 118 In low or asymmetric bandwidth situations, the fraction of session 119 bandwidth reserved for RTCP may need to be decreased below the five 120 percent specified in [1]. For example, in Cable Internet it is common 121 for downstream bandwidth to be a factor of twenty greater than 122 upstream bandwidth; allowing five percent of downstream bandwidth to 123 be used for receiver reporting upstream would result in congestion of 124 the upstream channel. In such situations it is necessary to allow the 125 bandwidth fraction to be adjusted. 127 4. Scaling alternatives 129 Several alternatives have been proposed for improving the scalability 130 of RTCP. These include: 132 Turning off RTCP receiver reports 133 Improved convergence algorithms 134 Use of separate multicast groups for RTP and RTCP 135 Use of separate multicast groups for receiver and sender reports 136 Unicasting of receiver reports 137 Selective reporting 138 Use of RTCP BYE messages 139 Use of TTL scoping and summary messages 140 Use of RTP translators 142 These alternatives are discussed in turn. 144 4.1. Turning off RTCP receiver reports 146 In some applications (such as satellite transmission) there may be no 147 upstream channel for transmission of RTCP receiver reports. As a 148 result, it may be desirable to allow receiver reporting to be turned 149 off. Since there is no receiver reporting, there would be no way to 150 estimate the receiver population. 152 Influence on RTCP receivers could be exercised via the SDP announce- 153 ment mechanism. For example, Mark Handley has proposed that the 154 session profile specified in SDP via the "m=" line be used to define 155 the desired RTCP behavior. This would allow for turning off of RTCP 156 receiver reports, or other modifications to reporting behavior. 158 While this proposal would eliminate problems relating to RTCP band- 159 width usage in dialup and asymmetric systems, it would deprive inter- 160 ested parties of information on listenership and reception quality. 161 This will prevent senders from making adjustments to their transmis- 162 sion parameters, and would also prevent RTP monitors from providing 163 listenership estimates needed to justify advertising rates. 165 However, it is not clear that these arguments are persuasive in all 166 cases. RTCP receiver reports serve multiple purposes. One of these is 167 to provide information on listenership; another is to provide informa- 168 tion on reception quality and bandwidth availability. In some Cable 169 Internet systems, it is possible to gain information on listenership 170 via IGMP join and leave messages, since if the upstream and downstream 171 channels are separated receivers do not necessarily hear each other's 172 join or leave messages. Furthermore, it can be argued that the state 173 of multicast diagnostics will eventually reach the point where RTCP 174 receiver reports will no longer needed for diagnostic purposes. Where 175 receiver-based rate adjustment is used, there may not be a need for 176 the sender to adjust their transmission parameters. 178 4.2. Improved convergence algorithms 180 Just as non-linear equation solvers can benefit from improved algo- 181 rithms, it may be possible to improve RTP receiver population esti- 182 mates via improvements in the population estimation algorithm. 183 Improvements include reconsideration, as well an initial population 184 estimate, and the incorporation of additional information into the 185 calculation. 187 The idea behind reconsideration, first proposed by Van Jacobson, is to 188 improve the convergence time by calculating a new estimate of group 189 size and reporting interval prior to sending the RTCP report. The 190 report is only sent if the updated estimate is less than or equal to 191 the original estimate; otherwise the report is not sent and the 192 reporting interval is adjusted to the new estimate. Use of reconsid- 193 eration greatly reduces the number of initial reports, since a host 194 joining a conference already in progress will be brought to equilib- 195 rium prior to sending its first report. As a result, implementation of 196 reconsideration should be made mandatory in future versions of the RTP 197 specification. 199 In certain circumstances, it may desirable to increase the dampening 200 effect of reconsideration by increasing the initial minimum reporting 201 interval. This will decrease the number of initial reports from sites 202 with long delays, i.e. sites with a satellite downlink and POTS or 203 ISDN uplink, as well as to decrease the effect of sites reporting 204 early merely due to statistical considerations. 206 Currently the receiver population estimate has an initial value of 1, 207 but it is possible for an initial population estimate to be supplied 208 in the session announcement. Successive population estimates could 209 then be derived via an averaging of the initial estimate and the 210 receiver's own estimate, so that the effect of the initial estimate 211 would die out over time. However, as in nonlinear equation solving, 212 use of an initial estimate is only helpful if it accurate and the ini- 213 tial estimate is likely to prove less important than the algorithm 214 which drives the system to steady state. While an improved initial 215 population estimate would result in improved convergence times, were 216 the initial estimate to be way off, convergence might be hindered. 218 The rate of convergence may be improved by allowing the receiver to 219 use information on the rate at which receiver reports are being sent. 220 For example, due to bandwidth limitations, receivers on higher band- 221 width connections have greater knowledge of the overall receiver popu- 222 lation. Thus if a receiver were to note a receiver report from a sys- 223 tem with high bandwidth availability, that report could be weighed 224 more heavily in determining the overall population estimate. 226 It is also possible to incorporate the overall receiver reporting rate 227 into the reporting interval calculation. For example, if my current 228 population estimate results in a receiver reporting interval of 3 min- 229 utes, and I am receiving 200 receiver reports/minute, it may be desir- 230 able to incorporate the rate of receiver reports into my calculations, 231 increasing the reporting interval accordingly. 233 However, the utility of taking rate information into account is lim- 234 ited in the case of dialup clients, since they will only be able to 235 receive a modest number of receiver reports/minute, and thus the rate 236 at which receiver reports are flowing in may not be reflective of the 237 overall receiver population. 239 While improved convergence algorithms can result in marked improve- 240 ments in convergence times, and do result in more accurate population 241 estimates, they do not result in a lower number of forwarding table 242 entries or senders to the RTCP receiver report group. They also do not 243 influence the steady state bandwidth usage for RTCP reporting. 245 4.3. Use of separate multicast groups for RTP and RTCP 247 Use of separate multicast groups for RTP and RTCP results in improved 248 scalability for multicasting routing protocols such as sparse mode 249 PIM, since the RTCP group can be placed on the shared tree due to its 250 low sending rate. While this would markedly decrease the number of 251 forwarding cache entries, the router will nevertheless expend consid- 252 erable resources in adding and flushing forwarding cache entries, and 253 setting up the individual hosts on the shared tree. For this reason, 254 we do not believe that moving RTCP to an adjacent group will be suffi- 255 cient for very large conferences. Note also that using an adjacent 256 group for RTCP does not improve the scalability for DVMRP, the MBONE 257 multicast routing protocol, since this protocol has no notion of a 258 shared tree. 260 Use of separate multicast groups for RTP and RTCP does not affect con- 261 vergence times or affect reporting accuracy. It also does not influ- 262 ence the steady state bandwidth usage for RTCP reporting. 264 4.4. Use of separate multicast groups for receiver and sender reports 266 Currently RTCP sender and receiver reports are sent to the same multi- 267 cast group, and both RTP senders and receivers join this group. Were 268 sender and receiver reports to be multicast on different groups, RTP 269 receivers could be allowed to only join the sender report group, thus 270 allowing them to avoid listening to receiver report traffic. RTP 271 senders would still join both groups in order to receive feedback on 272 listenership and transmission quality, and would need to provide 273 information on the estimated receiver population within the sender 274 reports. 276 While this proposal would lessen the problem for receivers, it would 277 not improve things for senders, and might even make them worse. Since 278 receivers would not longer be able to implement reconsideration as 279 effectively, it would be likely that the senders would be deluged with 280 initial receiver reports. Use of separate groups for receiver and 281 sender reports would not result in a lower number of senders on the 282 RTCP receiver report group, although it would decrease the number of 283 forwarding table entries in protocol such as sparse mode PIM. This 284 proposal would eliminate the bandwidth used by receivers for incoming 285 RTCP reports, but would not address the problem with upstream band- 286 width usage in asymmetric networks. 288 4.5. Unicasting of receiver reports 290 Instead of multicasting receiver reports, it is possible to unicast 291 them back to the senders. This would allow RTP listeners to avoid 292 receiver report traffic, while RTP senders would still receive feed- 293 back on listenership and transmission quality. In order to control the 294 receiver report transmission rate, senders would need to provide 295 information on the estimated receiver population within sender 296 reports. 298 While this proposal would lessen the problem for receivers, as with 299 the previous proposal, it might make things worse for senders, since 300 receivers would no longer be able to reconsider as effectively. How- 301 ever, it would eliminate multicasting of RTCP receiver reports, which 302 will be of benefit to overtaxed routers. This proposal would eliminate 303 the bandwidth used by receivers for incoming RTCP reports, but would 304 not address the problem with upstream bandwidth usage in asymmetric 305 networks. 307 4.6. Selective reporting 309 In selective reporting, RTCP receiver reports are only sent by 310 selected hosts. This method results in a reduction in the number of 311 RTCP senders, with attendant reduction in the forwarding tables. It 312 also is likely to result in lower convergence times. Assuming that the 313 statistical sampling was adequate, the accuracy and timeliness of 314 reporting need not be adversely affected. However, this method does 315 not affect the steady state bandwidth allocated to RTCP. 317 The selection can occur via a polling or random selection mechanism, 318 or it can occur by self-selection. Generally, random selection is pre- 319 ferred since self-selection brings with it the possibility of report- 320 ing implosions. For example, if receiver reports were only generated 321 when packet loss exceeded a given threshold, then congestion and 322 attendant packet loss would result in a large number of reports, mak- 323 ing the situation worse. 325 Polling or random selection methods, while they show considerable 326 promise, need to address security concerns. For example, if it is pos- 327 sible to get receivers to respond via a polling message, then that 328 message should be authenticated to prevent leveraged denial of service 329 attacks. 331 4.7. Use of RTCP BYE messages 333 Given that receiver reporting intervals will tend to be very long for 334 large conferences, it can be argued that absent an emergency, it makes 335 sense to provide information on listenership, reception quality and 336 bandwidth availability within the RTCP Bye message. Thus on leaving 337 the conference, the receiver would send a message providing informa- 338 tion on the time period in which they joined the conference, the over- 339 all reception quality and other information. Conventional receiver 340 reports would then either not be sent at all, or would be sent with a 341 TTL of 1. While such an approach would lessen the congestion problem 342 at the beginning of a session, it would increase the size of the RTCP 343 BYE message, resulting in a spike in RTCP bandwidth consumption at the 344 end of a session. Given that no receiver population estimate would be 345 available, it appears that this approach could actually worsen conver- 346 gence times, unless it were combined with some kind of summarization 347 mechanism. It would also not reduce the number of RTCP senders, or 348 reduce the steady state RTCP bandwidth fraction. 350 4.8. Use of TTL scoping and summary messages 352 In this approach, RTCP receiver reports would be sent with a TTL of 1, 353 and a designated summarizer would be elected to provide summary 354 reports with a larger TTL. This approach has the advantage of increas- 355 ing the leverage of those RTCP receiver reports that are sent, and is 356 likely to be particularly effective for conferences in which member- 357 ship is densely distributed. However, in sparsely distributed confer- 358 ences, the effect of summarization will be small unless multiple 359 levels of summarization are used. The designated summarizer would not 360 necesarily be a router; it could also be another receiver, although 361 this brings up the possibility of how a new summarizer could be 362 elected if the current summarizer leaves the conference. 364 Since in this scheme receiver reports are not forwarded, non-summariz- 365 ing RTP receivers should use the population estimate gleaned from 366 local scope reports to calculate their reporting interval. Summarizers 367 and RTP senders will then use global estimates gleaned from global 368 scope summary reports to calculate their reporting interval. A recom- 369 mended bandwidth allocation for reporting is 25 percent for sender 370 reports, 25 percent for summary reports, and 50 percent for receiver 371 reports. 373 Since this proposal decreases the scope of RTCP announcements, it 374 would substantially reduce the number of RTCP senders visible to the 375 multicast backbone, and would decrease convergence times, since those 376 messages that were sent would include more information on the receiver 377 population. This proposal would also address the problems of intercon- 378 necting multicast routing domains, since the multicast area border 379 router would be able to summarize RTCP behavior within its domain, 380 rather than passing along all RTCP reports. However, it would also 381 require substantial modifications in RTP client behavior. 383 4.8.1. Summary reports 385 Via the use of summary reports, privacy can be provided while simulta- 386 neously providing senders with improved listenership and receiver 387 quality reporting. This is possible because in the existing implemen- 388 tation much of the information gained from receiver reports is redun- 389 dant. For example, if congestion results in packets being dropped on a 390 particular link, then all receivers downstream from that link will 391 report the problem. Redundant reporting obscures the information of 392 greatest interest, which is information on global listenership and 393 reception quality. Via introduction of summary reports, it is possible 394 to provide more accurate and timely reporting on listenership and 395 reception quality, as well as to address issues involved in connecting 396 multicast routing domains. 398 Information useful in summary reports would include: 400 Total number of systems being summarized 401 Packets received and lost 402 Histogram of reception quality (fraction lost) 403 Histogram of receiver bandwidth 404 Information on users registering 406 The total systems summarized number is used in order to provide for 407 faster convergence times. Information on packets received and lost 408 will typically be used by network engineers looking to diagnose prob- 409 lems with the MBONE. The histograms of reception quality and receiver 410 bandwidth are propagated in order to allow senders to deduce informa- 411 tion relating to the global user experience. In order to allow for 412 location of individuals participating in a conference, the summarizer 413 may wish to relay information on the users in the conference. Alterna- 414 tively, it may register users in a directory service via use of the 415 LDAP extensions defined in [4]. 417 4.9. Use of RTP translators 419 Through the use of RTP translators, it is possible to divide RTP 420 receivers into areas in much the same way as is accomplished by OSPF. 421 Through the use of summary receiver reports, information on listener- 422 ship and receiver report quality can be propagated between areas while 423 reducing RTCP bandwidth usage and the RTCP sending population on the 424 MBONE. 426 In order to insulate receivers within an area from external receiver 427 reports, the RTP translator must filter external receiver reports, 428 while allowing external summary reports and sender reports to pass 429 through. Similarly, the RTP translator will listen to receiver 430 reports generated from within its area, but will not pass them on to 431 external areas. Instead, it would issue to external areas two types of 432 summary reports. The first will be based on the packets it receives 433 and will be identical to a conventional receiver report, except for 434 the use of the summary report type; the second will be a true summary 435 report based on area receiver reports. It is useful to allow receiver 436 reports from RTP translators to pass through so as to allow diagnosis 437 of internal distribution problems. The RTP translator will allow 438 internal sender reports to pass through unmodified. 440 The introduction of RTP translators has several advantages: 442 Improved convergence of the receiver population estimate 443 Decreased RTCP bandwidth 444 Improved privacy 445 Listenership and reception quality information available to senders 447 While most of the above advantages are also available in the receiver 448 summary approach, one advantage of the translator approach is that it 449 provides for greater control by the network administrator. For exam- 450 ple, since summary reports would be sent by RTP translators rather 451 than by client summarizers, it would be possible for administrators to 452 control the propagation of user information on a site-by-site basis, 453 rather than on a per-session basis. For example, rather than having 454 this sent in the summary report, it could be stored as a temporary 455 attribute in the area directory server. This may be perceived as a 456 substantial advantage by corporations looking to control access to 457 directory information. For those cases where it is desirable to allow 458 external access to area registration information, the IP address of 459 the area directory server may be advertised in the summary report. 460 This allows senders with appropriate privileges to retrieve conference 461 registration data from the area directory server via LDAP. 463 The RTP translator approach also has several major disadvantages. 464 These include: 466 Requires modifications to routers 467 Increases loading on routers that now must function as RTP translators 469 5. Acknowledgements 471 Thanks to Steve Casner of Precept, Mark Handley of ISI, Bob Hinden of 472 Ipsilon and Thomas Pfenning, Peter Ford and Stefan Solomon of 473 Microsoft for useful discussions of this problem space. 475 6. References 477 [1] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. "RTP: A 478 Transport Protocol for Real-Time Applications." RFC 1889, GMD Fokus, 479 January 1996. 481 [2] H. Schulzrinne. "RTP Profile for Audio and Video Conferences 482 with Minimal Control." RFC 1890, GMD Fokus, January 1996. 484 [3] M. F. Speer, S. McCanne. "RTP Usage with Layered Multimedia 485 Streams." draft-speer-avt-layered-video-01.txt, Sun Microsystems, 486 LBNL, June 1996. 488 [4] Y. Yaacovi, M. Wahl, K. Settle, T. Genovese. "Lightweight Direc- 489 tory Access Protocol: Extensions for Dynamic Directory Services." 490 draft-ietf-asid-ldapv3ext-02.txt, Microsoft, Critical Angle, October, 491 1996. 493 7. Authors' Addresses 495 Bernard Aboba 496 Microsoft Corporation 497 One Microsoft Way 498 Redmond, WA 98052 500 Phone: 206-936-6605 501 EMail: bernarda@microsoft.com