idnits 2.17.1 draft-ietf-avt-rtpsample-00.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): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 8 longer pages, the longest (page 9) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 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.) ** There are 10 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 370: '...mpling algorithm MUST NOT be applied t...' RFC 2119 keyword, line 373: '...iers for senders MUST always be added ...' RFC 2119 keyword, line 412: '.... A session participant MAY apply SSRC...' RFC 2119 keyword, line 414: '...sion participant MAY use any other alg...' RFC 2119 keyword, line 415: '...at any algorithm considered SHOULD NOT...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- The document date (August 1, 1998) is 9400 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 483 looks like a reference -- Missing reference section? '2' on line 487 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Audio/Video Transport wg 2 Internet Draft J. Rosenberg, H. Schulzrinne 3 draft-ietf-avt-rtpsample-00.txt Bell Laboratories/Columbia U. 4 August 1, 1998 5 Expires: February 1, 1999 7 Issues with RTP Sampling 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft. Internet-Drafts are working docu- 12 ments of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute work- 14 ing documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference mate- 19 rial or to cite them other than as ``work in progress''. 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Distribution of this document is unlimited. 29 1 Abstract 31 In order to control the flow of RTCP packets in large multicast 32 groups, session participants are required to transmit their packets 33 with a period proportional to the group size. Obtaining a group size 34 estimate generally requires a participant to maintain a list of group 35 members. As this can require significant memory, particularly for 36 embedded systems, RTP has been revised to allow for a statistical 37 sampling procedure which allows the memory size to be bounded for all 38 group sizes. However, this sampling algorithm can interact with other 39 aspects of RTP. In particular, we have identified three problems. 40 First, RTP sampling has an adverse affect on the performance of BYE 41 reconsideration. Secondly, it can cause inaccurate estimates with 42 dynamic group sizes that decrease rapidly. Thirdly, the current SSRC 43 sampling algorithm grossly overestimates the group size when there 44 are a few senders. We discuss these problems in detail and present 45 simple solutions. 47 2 Introduction 49 In order to control the flow of RTCP packets in large multicast 50 groups, session participants are required to transmit their packets 51 with a period proportional to the group size. Obtaining a group size 52 estimate generally requires a participant to maintain a list of group 53 members. As this can require significant memory, particularly for 54 embedded systems, RTP [1] has been revised to allow for a statistical 55 sampling procedure which allows the memory size to be bounded for all 56 group sizes. 58 This algorithm operates by applying an SSRC mask with m bits equal to 59 one to each packet received. Initially, m starts at 0. If the bitwise 60 AND of the SSRC of the incoming packet, and the mask, equals the bit- 61 wise AND of some key and the mask, the packet is accepted and the 62 SSRC counted in the group size estimate. When the memory requirements 63 for the list reach some threshold B , m is incremented. Those SSRC in 64 the list which no longer equal the key under the masking operation 65 are discarded. If there are n SSRC in the table, the group size esti- 66 mate is equal to n*(2**m). 68 This sampling algorithm can interact with other aspects of RTP. In 69 particular, we have identified two problems. First, RTP sampling has 70 an adverse affect on the performance of BYE reconsideration, and sec- 71 ondly, it can cause inaccurate estimates with dynamic group sizes 72 that decrease rapidly. We discuss these problems in detail and pre- 73 sent simple solutions. 75 3 Interaction with Reconsideration 77 The impact of the sampling algorithms is to effectively dampen the 78 changes in the membership table. Changes occur less frequently, but 79 with greater amplitudes. Consider the case where at some receiver, 80 the mask is 3 bits, and a surge of 16 new members join the group, all 81 over a 16 second interval. These new members will send RTCP packets, 82 but only one in 8 of them will be seen by the sampling member (2**3=8). 83 If we assume that the 16 members each send their first RTCP packets 84 uniformly over the 16 second interval, it will take the sampling mem- 85 ber 8 seconds, on average, to see one of them. When it does, its 86 group size estimate jumps by 8. For a non-sampling member, its group 87 size estimate increases smoothly by 16 over the 16 second interval. 89 Thus, the sampling algorithms tend to cause members to see group size 90 changes in bursts instead of smoothly. Furthermore, the amount of 91 time it takes to see a change increases. In the previous example, the 92 sampling member had to wait 8 seconds to see a change, whereas the 93 non-sampling member had to wait just 1 second. Its almost as if the 94 network delay for a sampling member increases. It is this increase in 95 delay which is troublesome. The reconsideration algorithms (both for- 96 ward, BYE, and reverse) in the RTP specification operate well in 97 cases where the network delays are small in comparison to the 98 transmission intervals. Since the sampling algorithm increases the 99 effective delay, the performance of the algorithms may be worse. We 100 therefore consider each in turn. 102 3.1 Forward Reconsideration 104 Fortunately, forward reconsideration is not generally affected by the 105 sampling algorithms. This is because forward reconsideration is 106 effective in cases where a large number of users simultaneously join 107 a multicast group. When these members join, each of them has an ini- 108 tial group size estimate of 1. As a result, each of them should have 109 sampling off initially (m=0). By the time enough of a group size 110 estimate has been obtained to require sampling, the impact of recon- 111 sideration has already worn off. 113 We can demonstrate this analytically as follows. We have postulated 114 that the impact of reconsideration is small when the ratio of the 115 tranmission interval at a sender, and the network delays, is large 116 [2]. After the initial spike of packets in forward reconsideration, 117 packets are sent at a rate of 1/(1-alpha)C, where alpha is .5, and C 118 represents the average RTCP packet size divided by 5 percent of the 119 session bandwidth. With sampling enabled, this flow of packets will 120 appear as if 2**m packets arrive instantaneously every 2**m(1-alpha)C 121 seconds (same average rate, but different burstiness). Thus, the 122 effective network delay for sampling members is 2**m(1-alpha)C. The 123 period of packet transmissions from a group member is, on average, 124 n*(2**m)*C. Thus, the quotient of these represents the interval/delay 125 value. This quotient is n/(1-alpha). Here, n represents the number of 126 entries in the sampled SSRC table. In the worst case, this quantity 127 should be half the size of the memory available. This is because the 128 sample mask is increased when the memory fills, resulting in a dis- 129 card of half the contents of the table. If the table filled the mem- 130 ory before the sample increase, it will occupy half of the memory 131 afterwards. As the specification recommends that B (the mimimum mem- 132 ory size) should be 100 SSRC values, the mimimum value of the quo- 133 tient is 100. This is sufficient to have no impact on forward recon- 134 sideration. 136 These results are verified by simulation in Figures 1 and 2 (present 137 in postscript version only). Figure 1 depicts the group size estimate 138 as seen by a single member in a session where 10,000 users simultane- 139 ously join the group at time 0. All session members implement uncon- 140 ditional reconsideration. The figure depicts two curves, one where 141 the all users sample, and another where they do not. Note that the 142 sampling algorithm performs relatively well. Figure 2 depicts the 143 cumulative number of RTCP packets sent to the multicast group across 144 all users. Also note that the sampling algorithm has little impact on 145 the RTCP traffic. 147 3.2 Reverse Reconsideration 149 Reverse reconsideration is a minor optimization that allows a session 150 participant to more rapidly decrease its transmission interval when 151 the group size decreases. It does this by moving in the transmission 152 time of the next packet when a BYE or timeout occurs. 154 When used in conjunction with SSRC sampling, the net effect is as if 155 BYE's were delayed and occurred in greater bursts. The impact on per- 156 formance of reverse reconsideration is the same as with forward. So 157 long as the delay increases are small compared with the transmission 158 period, little performance degradation should occur. The previous 159 section has demonstrated that this is the case. 161 3.3 BYE Reconsideration 163 Unfortunately, SSRC sampling can have a serious impact on BYE recon- 164 sideration, depending on how the algorithm in RTP is interpreted. 165 When a large number of users leave the group, they initialize a vari- 166 able called members to 0. As BYE packets are received, the members 167 count is incremented. A user sends a BYE packet according to the 168 standard forward reconsideration algorithm, but using the variable 169 members as a group size estimate. 171 If the SSRC sampling algorithm is applied against the incrementing of 172 the members variable (in other words, the variable is increased by 2**m 173 when a BYE matching the mask is received), BYE reconsideration can 174 fail. Consider the case where a large number of users simultaneously 175 leave the group at t=0. All initialize their members variables to 0. 176 Assume further that all are applying an SSRC sampling algorithm with 177 a mask of m bits. The implication is that none of them will increase 178 their members counter until, on average, 2**m packets are received. At 179 that point, the member counter jumps rapidly to 2**m, pushing off fur- 180 ther BYE packet transmissions substantially. However, until this hap- 181 pens, a large number of BYE packets may have already been transmit- 182 ted. 184 An analytical treatment of the impact of the problem is quite com- 185 plex. However, the effect is demonstrated via simulations. Figure 3 186 depicts the cumulative number of packets sent when 10,000 users 187 simultaneously join at t=0, and all but one leave at t=10,000. Note 188 that when sampling is in use, there is a spike of BYE packets, even 189 with BYE reconsideration, when the users all leave. The spike is not 190 present under normal operation. 192 The fix to this problem is fairly simple. The SSRC sampling mask must 193 not be applied to counting BYE packets after a user leaves. For every 194 BYE packet received, the counter is incremented, no matter what kind 195 of sampling is in use. 197 This means that when a BYE packet is received, it should be counted 198 even if it doesn't appear in the membership table. As long as each 199 user that leaves sends at most one BYE packet, there are no problems. 200 However, the implication is that a malicious user sending multiple BYE 201 packets can cause other users to see an abnormally high number of users 202 leaving. The result is that correctly behaving users will take longer to 203 send their BYE. Fortunately, this will cause a reduction in the vol- 204 ume of BYE traffic, not an increase. This overestimation of the leav- 205 ing user count is therefore safe as far as network traffic is con- 206 cerned. 208 A user who is not implementing sampling can check if a user is in the 209 membership list before accepting their BYE packet and incrementing 210 the counter. 212 Once this fix is applied, the BYE spike problem disappears. This is 213 demonstrated in Figure 4. The figure depicts the cumulative number of 214 packets sent when 10,000 users simultaneously join at t=0, and all 215 but one leave at t=10,000s. Notice that there are no spikes when the 216 sampling is not applied to BYE packets. 218 We therefore propose that the text in section 6.3.7 be modified, so 219 that the second bullet item reads: 221 Every time a BYE packet from another user is received, members is 222 incremented by 1. members is NOT incremented when other RTCP packets 223 or RTP packets are received, but only for BYE packets. The variable 224 members is incremented by 1 even if SSRC sampling is in use, and the 225 SSRC does not match the SSRC of any current group member in the sub- 226 sampled list. 228 4 Dynamic Group Sampling 230 With dynamic groups, it is possible for a large number of users to 231 join the group, and then for a sizeable portion to later leave. Those 232 members which remain throughout may make use of SSRC sampling. In 233 this case, as the other group members leave, the number of entries in 234 the sampled membership table may become small. The result is that the 235 group size estimate may become extremely inaccurate. To combat this 236 problem, it is desirable to compensate by decreasing the number of 237 bits in the sample table when the memory usage falls below some 238 threshold. 240 When the number of bits in the mask increases, the user compensates 241 by removing those SSRC which no longer match. When the number of bits 242 decreases, the user should theoretically add back those users whose 243 SSRC now match. However, these SSRC are not known, since the whole 244 point of sampling was to not have to remember them. Therefore, if the 245 number of bits in the mask is just reduced without any changes in the 246 membership table, the group estimate will instantly drop by exactly 247 half. 249 To compensate for this, some kind of algorithm compensation is 250 needed. Initially, the use of corrective fudge factors was proposed - 251 both an additive and a multiplicative. We have also devised a binning 252 based mechanism which performs better than the corrective factors. 254 4.1 Corrective Factors 256 The idea with the corrective factors is to add in or multiply the 257 group size estimate by some corrective factor to compensate for the 258 change in sample mask. The corrective factors should decay as the 259 fudged members are eventually learned about and actually placed in 260 the membership list. 262 The multiplicative factor starts at 2, and gradually decays to one. 263 The additive factor starts at the difference between the group size 264 estimate before and after the number of bits in the mask is reduced, 265 and decays to 0 (this is not always half the group size estimate, as 266 the corrective factors can be compounded, see below). Both factors 267 decay over a time of c*L(ts), where c is the average RTCP packet size 268 divided by 5% of the session bandwidth, and L(ts) is the group size 269 estimate just before the change in the number of bits in the mask at 270 time ts. The reason for this constant is as follows. In the case 271 where the actual group membership has not changed, those members 272 which were forgotten will still be sending RTCP packets. The amount 273 of time it will take to hear an RTCP packet from each of them is the 274 average RTCP interval, which is cL(ts). Therefore, by cL(ts) seconds 275 after the change in the mask, those users who were fudged by the 276 corrective factor should have sent a packet and thus appear in the 277 table. We chose to decay both functions linearly. This is because the 278 rate of arrival of RTCP packets is linear. 280 What happens if the number of bits in the mask is reduced once again 281 before the previous corrective factor has expired? In that case, we 282 compound the factors by using yet another one. Let fi() represent the 283 ith correction function. If ts is the time when the number of bits in 284 the mask is reduced, we can describe the additive correction factor 285 as: 287 0 t < ts 288 fi(t) = (L(ts-)-L(ts+))(ts+cL(ts-)-t)/(cL(ts-)) ts < t < ts + cL(ts-) 289 0 t > ts + cL(ts-) 291 and the multiplicative factor as: 293 1 t < ts 294 fi(t) = (ts+2cL(ts-)-t)/(cL(ts-)) ts < t < ts + c L(ts-) 295 1 t > ts + cL(ts-) 297 Note that in these equations, L(t) denotes the group size estimate 298 obtained including the corrective factors except for the new factor. 300 Finally, the actual group size estimate L(t) is given by: 302 L(t) = (SUM over i of fi(t)) + N 2**m 304 for the additive factor, and: 306 L(t) = (PRODUCT over i of fi(t)) N 2**m 308 for the multiplicative factor. 310 Our simulations showed that both algorithms performed equally well, 311 but both tended to seriously underestimate the group size when the 312 group membership was rapidly declining. This is demonstrated in the 313 performance curves below. 315 4.2 Binning Algorithm 317 In order to more correctly estimate the group size even when it was 318 rapidly decreasing, we developed a binning based algorithm. The algo- 319 rithm works as follows. There are 32 bins, same as the number of 320 bits in the sample mask. When an RTCP packet from a new user arrives 321 whose SSRC matches the key under the masking opera- 322 tion, it is placed in the bin with the current value of the mask. 324 When the number of bits in the mask is to be increased, those members 325 in the bin who still match after the new mask are moved into the next 326 higher bin. Those who don't match are discarded. When the number of 327 bits in the mask is to be decreased, nothing is done. Users in the 328 various bins stay where they are. However, when an RTCP packet for a 329 user shows up, and the user is in a bin with a higher value than 330 the current number of bits in the mask, it is moved into the bin cor- 331 responding to the current number of bits in the mask. Finally, the 332 group size estimate L(t) is obtained by: 334 L(t) = SUM from i=0 to i=31 of (B(i) 2**i) 336 Where B(i) are the number of users in the ith bin. 338 The algorithm works by basically keeping the old estimate when the 339 number of bits in the mask drops. As users arrive, they are gradually 340 moved into the lower bin, reducing the amount that the higher bin 341 contributes to the total estimate. However, the old estimate is still 342 updated in the sense that users which timeout are removed from the 343 higher bin, and users who send BYE packets are also removed from the 344 higher bin. This allows the older estimate to still adapt, while 345 gradually phasing it out. It is this adaptation which makes it per- 346 form much better than the corrective algorithms. The algorithm is 347 also extremely simple. 349 4.3 Comparison 351 The algorithms are all compared via simulation in Figure 5. In the 352 simulation, 10,001 users join a group at t=0. At t=10,000, 5000 of 353 them leave. At t=20,000, another 5000 leave. All implement an SSRC 354 sampling algorithm, unconditional forward and BYE reconsideration. 355 The graph depicts the group size estimate as seen by the single user 356 present throughout the entire session. In the simulation, a memory 357 size of 1000 SSRC was assumed. The performance without sampling, and 358 with sampling with the additive, corrective, and bin-based correction 359 are depicted. 361 As the graph shows, the bin based algorithm performs particularly 362 well at capturing the group size estimate towards the tail end of the 363 simulation. 365 4.4 Sender Sampling 367 The current text mandates that senders always be kept in the list, 368 even when their SSRC do not match: 370 "Note that this sampling algorithm MUST NOT be applied to SSRC identi- 371 fiers that correspond to senders because otherwise the calculation of 372 the RTCP bandwidth when we_sent is true would be inaccurate. The SSRC 373 identifiers for senders MUST always be added to the table when first 374 received and not removed from the table when the mask is extended." 376 We have observed that this can cause overstimations in the group 377 estimate when the number of senders is even a small percentage of the 378 total group size. This is easily demonstrated analytically. Let Ns be 379 the number of senders, and Nr be the number of receivers. The member- 380 ship table will contain all Ns senders and 1/2**m of the receivers. The 381 total group size estimate in the current draft is obtained by 2**m 382 times the number of entries in the table. Therefore, the group size 383 estimate becomes: 385 L(t) = 2**m Ns + Nr 387 which exponentially weights the senders. 389 This is easily compensated for in the binning algorithm. A sender is 390 always placed in the 0th bin. When a sender becomes a receiver, it is 391 moved into the bin corresponding to the current value of m, if its 392 SSRC matches the key under the masked comparison operation, and 393 otherwise is discarded. 395 4.5 Proposed Text 397 Based on these results, we propose that the following text be used in 398 place of paragraph 6 and 7 of section 6.3.3: 400 The group size estimate is then computed according to Annex A.9 402 Paragraph 2 of Section 6.3.4 should be stricken. 404 Paragraph 3 of Section 6.3.5 should be stricken. 406 We also propose that Annex A.9 be added: 408 Annex A.9 SSRC Sampling Mechanisms 410 When the group memberships for large sessions becomes substantial, a 411 group member may find that the storage requirements for storing the 412 SSRC listing may be excessive. A session participant MAY apply SSRC 413 sampling, as described here, to reduce the storage requirements. A 414 session participant MAY use any other algorithm with similar perfor- 415 mance. A key requirement is that any algorithm considered SHOULD NOT 416 substantially underestimate the group size, although the MAY 417 overestimate. 419 The algorithm operates by applying a mask with m bits to the SSRC of 420 each member. If the SSRC matches the SSRC of the sampling user under 421 the masking operation, the member is added to the table, otherwise 422 they are ignored. Initially, the mask starts with m=0, so that every 423 SSRC is accepted and placed into the table. When the storage require- 424 ments reach some threshold, B, the member increases m by 1 bit, and 425 discards all SSRC in the table which no longer match under the mask. 426 This will reduce the table size by roughly half. As the group size 427 continues to increase, the user MAY further increase the mask size by 428 an additional bit when the table size once again approaches the 429 threshold. A client MUST maintain a table which can accomodate at 430 least B=100 users, for reasonable statistical accuracy. Members who 431 are senders MUST be maintained in the table, even when their SSRC 432 does not match under the masking operation. 434 Each user also maintains a set of 32 bins, numbered 0 through 31. 435 When a new user shows up whose SSRC matches the key under the current 436 mask (with m bits), the user is placed in bin m. Additionally, when a 437 the mask is increased from m to m+1 bits, all users who still match 438 under the m+1 bit mask are moved from bin m to bin m+1. Note, how- 439 ever, that users who are senders are always placed in the 0th bin. 440 When a sender stops sending, it is placed in the bin corresponding to the 441 current mask length m if its SSRC matches the key under the masking 442 operation, otherwise its discarded. 444 Just as the group size may grow, the group size may decrease. In 445 these cases, the number of entries in the table may become too small 446 to provide a reasonable statistical estimate. At such times, it may 447 become necessary to decrease the number of bits in the mask. If the 448 group size estimate is L, and there are m bits in the mask, and the 449 total amount of storage available for the table is B, it is recom- 450 mended that the mask be decreased by one when: 452 L / 2**m < B/4 454 When the mask is reduced from m to m-1, any users in bins m or higher 455 are NOT MOVED into the lower bins. They stay in their current bin. 457 When a packet arrives from a user who is currently in some bin x, and 458 the number of bits in the mask is currently m, for some m < x, the 459 user is then moved from bin x to bin m. When a user times out, or a 460 BYE packet is received for it, and it exists in the membership table, 461 it is removed from its bin. Note that senders are always in bin 0 and 462 never move as the SSRC mask changes. 464 Finally, to obtain a group size estimate, the following formula is 465 used: 467 L = SUM from i=0 to i=31 of B(i) * (2**i) 469 Where B(i) is the number of users in the ith bin. 471 5 Conclusion 473 We have presented some issues related to the SSRC sampling algorithms 474 present in the latest RTP draft. We have identified and fixed one 475 problem related to the interaction of BYE reconsideration and sam- 476 pling. We have also identified the need for corrective factors in the 477 sampling algorithms, and presented and compared three algorithms for 478 it. Based on performance and simplicity, we recommended that one of 479 them, the bin sampling algorithm, be recommended. 481 6 Bibliography 483 [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, RTP: a 484 transport protocol for real-time applications, Request for Comments 485 (Proposed Standard) 1889, Internet Engineering Task Force, Jan. 1996. 487 [2] J. Rosenberg and H. Schulzrinne, Timer reconsideration for 488 enhanced RTP scalability, (San Francisco, California), March/April 489 1998. 491 7 Full Copyright Statement 493 Copyright (C) The Internet Society (1998). All Rights Reserved. 495 This document and translations of it may be copied and furnished to 496 others, and derivative works that comment on or otherwise explain it 497 or assist in its implmentation may be prepared, copied, published and 498 distributed, in whole or in part, without restriction of any kind, 499 provided that the above copyright notice and this paragraph are 500 included on all such copies and derivative works. 502 However, this document itself may not be modified in any way, such as 503 by removing the copyright notice or references to the Internet Soci- 504 ety or other Internet organizations, except as needed for the purpose 505 of developing Internet standards in which case the procedures for 506 copyrights defined in the Internet Standards process must be fol- 507 lowed, or as required to translate it into languages other than 508 English. 510 The limited permissions granted above are perpetual and will not be 511 revoked by the Internet Society or its successors or assigns. 513 This document and the information contained herein is provided on an 514 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 515 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 516 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 517 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 518 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 520 8 Authors' Addresses 522 Jonathan Rosenberg 523 Bell Laboratories, Lucent Technologies 524 101 Crawfords Corner Rd. 525 Holmdel, NJ 07733 526 Rm. 4C-526 527 email: jdrosen@bell-labs.com 529 Henning Schulzrinne 530 Columbia University 531 M/S 0401 532 1214 Amsterdam Ave. 533 New York, NY 10027-7003 534 email: schulzrinne@cs.columbia.edu