idnits 2.17.1 draft-saintandre-xmpp-presence-analysis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 423. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 434. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 441. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 447. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (April 11, 2007) is 6225 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) == Outdated reference: A later version (-08) exists of draft-ietf-simple-interdomain-scaling-analysis-00 -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. 'SIP-EVENT') (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 3920 (ref. 'XMPP-CORE') (Obsoleted by RFC 6120) -- Obsolete informational reference (is this intentional?): RFC 3921 (ref. 'XMPP-IM') (Obsoleted by RFC 6121) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre 3 Internet-Draft XSF 4 Expires: October 13, 2007 April 11, 2007 6 Interdomain Presence Scaling Analysis for the Extensible Messaging and 7 Presence Protocol (XMPP) 8 draft-saintandre-xmpp-presence-analysis-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on October 13, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document analyzes the traffic that is generated as a result of 42 presence subscriptions between users of federated domains that 43 support the Extensible Messaging and Presence Protocol (XMPP). This 44 analysis is provided as a source of comparison with a similar 45 analysis being performed regarding domains that support federated 46 presence using Session Initiation Protocol (SIP) for Instant 47 Messaging and Presence Leveraging Extensions (SIMPLE). 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Traffic Load . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.2. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . 4 55 2.3. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 2.4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 6 57 2.4.1. Basic . . . . . . . . . . . . . . . . . . . . . . . . 7 58 2.4.2. Widely Distributed Inter-Domain Presence . . . . . . . 7 59 2.4.3. Very Large Network Peering . . . . . . . . . . . . . . 8 60 2.4.4. Intra-Domain Peering . . . . . . . . . . . . . . . . . 8 61 3. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 4. Informative References . . . . . . . . . . . . . . . . . . . . 9 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 Intellectual Property and Copyright Statements . . . . . . . . . . 11 66 1. Introduction 68 Presence is information about the network availability of an 69 individual (or, more precisely, of a presence address of the kind 70 that is often but not necessarily associated with an individual). As 71 typically designed and deployed, presence is shared only with 72 authorized entities, where the authorization takes the form of a 73 subscription. (In this document, we employ the term "user" to 74 signify an account that generates presence information and the term 75 "contact" to signify an annount that is subscribed to the user's 76 presence.) 78 The sharing of presence information can result in a large volume of 79 traffic as users log on or off throughout the life of a presence 80 session, especially for users with large numbers of contacts (e.g., 81 the author of this document has approximately 1,500 contacts in his 82 list of presence subscribers). The volume is increased by 83 communication of information beyond boolean network availability, 84 such as availability substates (e.g., "away" and "do not disturb"). 85 The volume is further increased if the presence "transport" is used 86 to communicate information such as geolocation, mood, activity, even 87 the music to which an individual is listening. While such traffic 88 may not be a concern in a standalone presence domain, interdomain 89 communications may introduce a more significant impact on the 90 functioning of the Internet as a whole. 92 There are several standardized technologies for sharing presence 93 information. One is a set of extensions to the Session Initiation 94 Protocol (SIP), where the base protocol is defined in [SIP] and the 95 extensions are defined in [SIP-EVENT] and [SIP-PRES]. Another is the 96 Extensible Messaging and Presence Protocol (XMPP) as defined in 97 [XMPP-CORE] and [XMPP-IM]. 99 [PROBLEM] analyzes several factors regarding the scalability of 100 interdomain communication of presence information using SIP/SIMPLE 101 technologies. For the sake of comparison, this document aims to 102 provide a similar analysis regarding XMPP technologies; in its first 103 iteration, it discusses traffic load exclusively since bandwidth 104 usage has the greatest potential impact on the Internet (whereas 105 issues such as state management and server processing of presence 106 information are implementation-specific). 108 2. Traffic Load 109 2.1. Assumptions 111 The model for XMPP presence subscriptions is different from that of 112 SIP. In particular, XMPP presence subscriptions are long-lived, and 113 once established last until cancelled. Thus XMPP does not have 114 subscription timeouts and refresh periods as SIP presence does. In 115 addition, this document does not include presence subscriptions in 116 its protocol flows since in XMPP they are preconditions for the 117 exchange of presence notifications (in any case, the number of XML 118 stanzas exchanged in the process of establishing a presence 119 subscription is negligible compared to the volume of presence 120 notifications). 122 XMPP presence subscriptions are typically bidirectional (i.e., the 123 contact has a subscription to the user's presence and the user has a 124 subscription to the contact's presence). However, because [PROBLEM] 125 assumes that subscriptions are uni-directional (i.e., the contact has 126 a subscription to the user's presence but not vice-versa), the same 127 assumption is made herein. 129 Although an XMPP user or contact may have multiple connected 130 "resources" (e.g., client or device) at any one time, for the sake of 131 simplification this document assumes that each entity has only one 132 simultaneous resource. 134 Note that, unlike in SIP, XMPP packets are not typically acknowledged 135 with the equivalent of a 200/OK message. 137 [PROBLEM] assumes that presence notification packets will typically 138 be on the order of 4 kilobytes in size (not including TCP or UDP 139 overhead). XMPP presence notification packets tend to be much 140 smaller than SIP presence notification packets; in this document we 141 assume (based on deployment experience) that they are typically 200 142 bytes in size. 144 2.2. Protocol Flows 146 When a contact (in these examples romeo@example.net) becomes 147 available, the contact's server sends an XMPP presence stanza of type 148 "probe" to the user (in these examples juliet@example.com) on behalf 149 of the contact, as shown in the following example (this can be seen 150 as similar to the initial SUBSCRIBE in SIP presence): 152 Contact's server sends presence probe to user: 154 159 If the user's server determines that the contact is authorized to see 160 the user's presence, the user's server return's the user's current 161 presence state to the contact (this is equivalent to the "Initial 162 NOTIFY" in SIP presence). 164 User's server sends presence to contact: 166 170 away 171 be right back 172 0 173 175 If the user subsequently changes her presence, the user's server 176 sends an updated presence notification to the contact. 178 User's server sends updated presence to contact: 180 184 0 185 187 A presence session can include any number of presence changes. 189 When the user goes offline, the user's server sends a presence stanza 190 of type "unavailable" to the contact. 192 User's server sends unavailable presence to contact: 194 200 Naturally, similar protocol flows are generated by the contact during 201 the life of his presence session. 203 2.3. Analysis 205 To enable valid comparison between SIMPLE and XMPP with regard to 206 interdomain presence scaling, this document adheres as closely as 207 possible to the analysis presented in [PROBLEM], witih appropriate 208 modifications given differences between the two technologies. In 209 particular, traffic calculations are based on the following inputs 210 and formulae, where the numbering follows that in [PROBLEM] and the 211 terminology is adjusted to conform to XMPP: 213 o (A01) Presence session lifetime in hours -- assumed to be 8 hours. 214 o (A02) Presence state changes per hour -- assumed to be 3 times per 215 hour. 216 o (A03) Subscription refresh interval per hour -- does not apply to 217 XMPP. 218 o (A04) Total federated contacts per user -- varies based on the 219 scenario under discussion. 220 o (A05) Number of dialogs to maintain per watcher -- does not apply 221 to XMPP. 222 o (A06) Number of contacts in a federated presence domain -- varies 223 based on the scenario under discussion. 224 o (A07) Initial presence subscription exchange -- deemed out of 225 scope here since XMPP presence subscriptions are long-lived. 226 o (A08) Initial presence notification -- on the model of SIP NOTIFY 227 plus 200, this is XMPP presence probe plus initial notification, 228 thus 2 per contact. 229 o (A09) Total initial messages -- (A08*A06). 230 o (A10) Presence notifications per user = (A02*A01*A04). 231 o (A11) Subscription refreshes -- does not apply to XMPP. 232 o (A12) NOTIFY/200 due to subscribe refresh -- does not apply to 233 XMPP. 234 o (A13) Number of steady state messages = (A10*A06). 235 o (A14) SUBSCRIBE termination -- does not apply to XMPP. 236 o (A15) Unavailable presence -- sent when user goes offline 237 (equivalent to NOTIFY terminated), 1 per contact. 238 o (A16) Number of sign-out messages = (A15*A06). 239 o (A17) Total number of messages between domains = ((A09+A13+ 240 A16)*2). 241 o (A18) Total number of messages per second = (A17/A01/3600). 242 o (A19) Total number of kilobytes per second = (A18*.2). 244 2.4. Scenarios 245 2.4.1. Basic 247 This scenario assumes two domains, each with 20,000 users, where each 248 user has 4 contacts in the other domain and changes presence 3 times 249 per hour. The calculations are as follows: 251 o (A01) = 8. 252 o (A02) = 3. 253 o (A03) N/A. 254 o (A04) = 4. 255 o (A05) N/A. 256 o (A06) = 20,000. 257 o (A07) N/A. 258 o (A08) = 8. 259 o (A09) = (A08*A06) = 160,000. 260 o (A10) = (A02*A01*A04) = 96. 261 o (A11) N/A. 262 o (A12) N/A. 263 o (A13) = (A10*A06) = 1,920,000. 264 o (A14) N/A. 265 o (A15) = 4. 266 o (A16) = (A15*A06) = 80,000. 267 o (A17) = ((A09+A13+A16)*2) = 4,320,000 total messages. 268 o (A18) = (A17/A01/3600) = 150 messages per second. 269 o (A19) = (A18*.2) = 30 kilobtyes per second. 271 For the last three factors, the comparable numbers for SIMPLE (from 272 [PROBLEM]) are 14,080,000 total messages, 489 messages per second, 273 and 830 kilobytes per second. 275 2.4.2. Widely Distributed Inter-Domain Presence 277 This scenario assumes two domains, each with 20,000 users, where each 278 user has 20 contacts in the other domain and changes presence 3 times 279 per hour. The calculations are as follows: 281 o (A01) = 8. 282 o (A02) = 3. 283 o (A03) N/A. 284 o (A04) = 20. 285 o (A05) N/A. 286 o (A06) = 20,000. 287 o (A07) N/A. 288 o (A08) = 40. 289 o (A09) = (A08*A06) = 800,000. 290 o (A10) = (A02*A01*A04) = 480. 292 o (A11) N/A. 293 o (A12) N/A. 294 o (A13) = (A10*A06) = 9,600,000. 295 o (A14) N/A. 296 o (A15) = 20. 297 o (A16) = (A15*A06) = 400,000. 298 o (A17) = ((A09+A13+A16)*2) = 21,600,000 total messages. 299 o (A18) = (A17/A01/3600) = 750 messages per second. 300 o (A19) = (A18*.2) = 150 kilobtyes per second. 302 For the last three factors, the comparable numbers for SIMPLE (from 303 [PROBLEM]) are 70,400,000 total messages, 2,444 messages per second, 304 and 1,968 kilobytes per second. 306 2.4.3. Very Large Network Peering 308 This scenario assumes two domains, each with 10,000,000 users, where 309 each user has 10 contacts in the other domain and changes presence 6 310 times per hour. The calculations are as follows: 312 o (A01) = 8. 313 o (A02) = 6. 314 o (A03) N/A. 315 o (A04) = 10. 316 o (A05) N/A. 317 o (A06) = 10,000,000. 318 o (A07) N/A. 319 o (A08) = 20. 320 o (A09) = (A08*A06) = 200,000,000. 321 o (A10) = (A02*A01*A04) = 480. 322 o (A11) N/A. 323 o (A12) N/A. 324 o (A13) = (A10*A06) = 4,800,000,000. 325 o (A14) N/A. 326 o (A15) = 10. 327 o (A16) = (A15*A06) = 100,000,000. 328 o (A17) = ((A09+A13+A16)*2) = 10,200,000,000 total messages. 329 o (A18) = (A17/A01/3600) = 354,166 messages per second. 330 o (A19) = (A18*.2) = 70,833 kilobtyes per second. 332 For the last three factors, the comparable numbers for SIMPLE (from 333 [PROBLEM]) are 27,200,000,000 total messages, 944,444 messages per 334 second, and 880,555 kilobytes per second. 336 2.4.4. Intra-Domain Peering 338 This scenario assumes two domains, each with 60,000 users, where each 339 user has 10 contacts in the other domain and changes presence 3 times 340 per hour. The calculations are as follows: 342 o (A01) = 8. 343 o (A02) = 3. 344 o (A03) N/A. 345 o (A04) = 10. 346 o (A05) N/A. 347 o (A06) = 60,000. 348 o (A07) N/A. 349 o (A08) = 20. 350 o (A09) = (A08*A06) = 1,200,000. 351 o (A10) = (A02*A01*A04) = 240. 352 o (A11) N/A. 353 o (A12) N/A. 354 o (A13) = (A10*A06) = 14,400,000. 355 o (A14) N/A. 356 o (A15) = 10. 357 o (A16) = (A15*A06) = 600,000. 358 o (A17) = ((A09+A13+A16)*2) = 32,400,000 total messages. 359 o (A18) = (A17/A01/3600) = 1125 messages per second. 360 o (A19) = (A18*.2) = 225 kilobtyes per second. 362 For the last three factors, the comparable numbers for SIMPLE (from 363 [PROBLEM]) are 105,600,000 total messages, 3,667 messages per second, 364 and 3,683 kilobytes per second. 366 3. Security Considerations 368 This document introduces and addresses no security concerns above and 369 beyond those already defined in [XMPP-CORE] and [XMPP-IM]. 371 4. Informative References 373 [PROBLEM] Houri, A., "Problem Statement for SIP/SIMPLE", 374 draft-ietf-simple-interdomain-scaling-analysis-00 (work in 375 progress), February 2007. 377 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 378 A., Peterson, J., Sparks, R., Handley, M., and E. 379 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 380 June 2002. 382 [SIP-EVENT] 383 Roach, A., "Session Initiation Protocol (SIP)-Specific 384 Event Notification", RFC 3265, June 2002. 386 [SIP-PRES] 387 Rosenberg, J., "A Presence Event Package for the Session 388 Initiation Protocol (SIP)", RFC 3856, August 2004. 390 [XMPP-CORE] 391 Saint-Andre, P., "Extensible Messaging and Presence 392 Protocol (XMPP): Core", RFC 3920, October 2004. 394 [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence 395 Protocol (XMPP): Instant Messaging and Presence", 396 RFC 3921, October 2004. 398 Author's Address 400 Peter Saint-Andre 401 XMPP Standards Foundation 402 P.O. Box 1641 403 Denver, CO 80201 404 USA 406 Email: stpeter@jabber.org 407 URI: xmpp:stpeter@jabber.org 409 Full Copyright Statement 411 Copyright (C) The IETF Trust (2007). 413 This document is subject to the rights, licenses and restrictions 414 contained in BCP 78, and except as set forth therein, the authors 415 retain all their rights. 417 This document and the information contained herein are provided on an 418 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 419 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 420 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 421 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 422 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 423 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 425 Intellectual Property 427 The IETF takes no position regarding the validity or scope of any 428 Intellectual Property Rights or other rights that might be claimed to 429 pertain to the implementation or use of the technology described in 430 this document or the extent to which any license under such rights 431 might or might not be available; nor does it represent that it has 432 made any independent effort to identify any such rights. Information 433 on the procedures with respect to rights in RFC documents can be 434 found in BCP 78 and BCP 79. 436 Copies of IPR disclosures made to the IETF Secretariat and any 437 assurances of licenses to be made available, or the result of an 438 attempt made to obtain a general license or permission for the use of 439 such proprietary rights by implementers or users of this 440 specification can be obtained from the IETF on-line IPR repository at 441 http://www.ietf.org/ipr. 443 The IETF invites any interested party to bring to its attention any 444 copyrights, patents or patent applications, or other proprietary 445 rights that may cover technology that may be required to implement 446 this standard. Please address the information to the IETF at 447 ietf-ipr@ietf.org. 449 Acknowledgment 451 Funding for the RFC Editor function is provided by the IETF 452 Administrative Support Activity (IASA).