idnits 2.17.1 draft-saintandre-xmpp-presence-analysis-01.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 818. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 829. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 836. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 842. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 (October 2, 2007) is 6051 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-simple-interdomain-scaling-analysis-01 -- 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 (~~), 2 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 XMPP Standards Foundation 4 Intended status: Informational October 2, 2007 5 Expires: April 4, 2008 7 Interdomain Presence Scaling Analysis for the Extensible Messaging and 8 Presence Protocol (XMPP) 9 draft-saintandre-xmpp-presence-analysis-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 4, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document analyzes the scalability of presence sharing between 43 domains that federate using the Extensible Messaging and Presence 44 Protocol (XMPP). This analysis is provided as a source of comparison 45 with a similar analysis being performed regarding the presence 46 extensions to the Session Initiation Protocol (SIP). 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . . 5 53 4. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 4.1. Constants . . . . . . . . . . . . . . . . . . . . . . . . 7 55 4.2. Initial Messages . . . . . . . . . . . . . . . . . . . . . 7 56 4.3. Steady State Messages . . . . . . . . . . . . . . . . . . 8 57 4.4. Termination Messages . . . . . . . . . . . . . . . . . . . 8 58 4.5. Bottom Line . . . . . . . . . . . . . . . . . . . . . . . 9 59 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 5.1. Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 5.2. Widely Distributed Inter-Domain Presence . . . . . . . . . 11 62 5.3. Very Large Network Peering . . . . . . . . . . . . . . . . 13 63 5.4. Intra-Domain Peering . . . . . . . . . . . . . . . . . . . 15 64 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 16 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 66 8. Informative References . . . . . . . . . . . . . . . . . . . . 17 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 68 Intellectual Property and Copyright Statements . . . . . . . . . . 19 70 1. Introduction 72 Presence is information about the network availability of an 73 individual (or, more precisely, of a presence address of the kind 74 that is often but not necessarily associated with an individual). As 75 typically designed and deployed, presence is shared only with 76 authorized entities, where the authorization takes the form of a 77 subscription. (In this document, we employ the term "user" to 78 signify an account that generates presence information and the term 79 "contact" to signify an annount that is subscribed to the user's 80 presence.) 82 The sharing of presence information can result in a large volume of 83 traffic as users log on or off throughout the life of a presence 84 session, especially for users with large numbers of contacts (e.g., 85 the author of this document has over 1,500 contacts in his list of 86 presence subscribers). The volume is increased by communication of 87 information beyond basic on-off network availability, such as 88 availability substates (e.g., "away" and "do not disturb"). The 89 volume is further increased if the presence "transport" is used to 90 communicate information such as geolocation, mood, activity, even the 91 music to which an individual is listening. Such traffic may be a 92 concern even in a standalone presence domain. However, when presence 93 is shared across domain boundaries then such traffic may introduce a 94 more significant impact on the functioning of the Internet as a 95 whole. Therefore it is important to analyze the traffic generated 96 during interdomain communication of presence information. 98 There are several standardized technologies for sharing presence 99 information. One is a set of extensions (commonly called "SIMPLE") 100 to the Session Initiation Protocol (SIP), where the base protocol is 101 defined in [SIP] and the extensions are defined in [SIP-EVENT] and 102 [SIP-PRES]. Another is the Extensible Messaging and Presence 103 Protocol (XMPP) as defined in [XMPP-CORE] and [XMPP-IM]. 105 [PROBLEM] analyzes several factors regarding the scalability of 106 interdomain communication of presence information using SIP/SIMPLE 107 technologies. For the sake of comparison, this document aims to 108 provide a similar analysis regarding XMPP technologies. In 109 particular, this document focuses on traffic load exclusively since 110 bandwidth usage has the greatest potential impact on the Internet. 111 By contrast, issues such as state management and server processing of 112 presence information are implementation-specific. This document also 113 briefly mentions existing methods for improving the scalability of 114 XMPP presence (and presence-like) communications. 116 2. Assumptions 118 The model for XMPP presence subscriptions is different from that of 119 SIP. In particular, XMPP presence subscriptions are long-lived, and 120 once established last until cancelled. Thus XMPP does not have 121 subscription timeouts and refresh periods as SIP presence does. In 122 addition, this document does not include presence subscriptions in 123 its protocol flows since in XMPP they are preconditions for the 124 exchange of presence notifications (in any case, the number of XML 125 stanzas exchanged in the process of establishing a presence 126 subscription is negligible compared to the volume of presence 127 notifications). 129 XMPP presence subscriptions are typically bidirectional (i.e., the 130 contact has a subscription to the user's presence and the user has a 131 subscription to the contact's presence). However, because [PROBLEM] 132 assumes that subscriptions are uni-directional (i.e., the contact has 133 a subscription to the user's presence but not vice-versa), the same 134 assumption is made herein. 136 Although an XMPP user or contact may have multiple connected 137 "resources" (e.g., client or device) at any one time, for the sake of 138 simplification this document assumes that each entity has only one 139 simultaneous resource. 141 Note that, unlike in SIP, XMPP packets are not typically acknowledged 142 with the equivalent of a 200/OK message. 144 [PROBLEM] assumes that presence notification packets will typically 145 be on the order of 3.5 kilobytes in size (not including TCP or UDP 146 overhead). XMPP presence notification packets tend to be much 147 smaller than SIP presence notification packets; in this document we 148 assume (based on deployment experience) that they are typically 200 149 bytes in size for basic on-off presence. However, some XMPP 150 applications may include additional information in a presence 151 notification packet, such as entity capabilities as described in 152 [XEP-0115]. 154 Both [XMPP-CORE] and [XMPP-IM] strongly recommend that XMPP presence 155 notifications should include only information that is relevant to a 156 user's willingness or ability to communicate using real-time methods 157 such as instant messaging. However, some XMPP applications include 158 information that is not communications-relevant, such as the hash of 159 a user's avatar icon (see [XEP-0153] and even metadata about the 160 music to which a user is listening (see [XEP-0118]). Although it is 161 recommended to communicate such information using the XMPP publish- 162 subscribe extension (see [XEP-0060]) and appropriate profiles thereof 163 (e.g., [XEP-0163]), some existing XMPP clients send non- 164 communications-relevant information using presence notifications 165 instead of dedicated publish-subscribe nodes. Such behavior 166 marginally increases notification size but can drastically increase 167 the number of notifications sent (e.g., one notification every 3 or 4 168 minutes when the user begins listening to a new music track). This 169 document does not discuss such usage, since it is actively 170 discouraged and borders on abusive. 172 This document does not discuss various optimizations for SIMPLE (for 173 which see [PROBLEM]) or XMPP. The primary deployed optimization for 174 XMPP is stream compression, implemented either at the TLS level via 175 native TLS compression or at the XMPP level where TLS compression is 176 not available (see [XEP-0138]). Because XMPP communications occur 177 over long-lived TCP connections and associated long-lived XML 178 streams, such compression has been found to yield significant 179 bandwidth savings, up to 90% or even 95%. Stream compression is 180 therefore the recommended method for reducing bandwidth consumption 181 in XMPP systems. 183 3. Protocol Flows 185 When a contact (in these examples romeo@example.net) becomes 186 available, the contact's server sends an XMPP presence stanza of type 187 "probe" to the user (in these examples juliet@example.com) on behalf 188 of the contact, as shown in the following example (this can be seen 189 as similar to the initial SUBSCRIBE in SIP presence): 191 Contact's server sends presence probe to user (82 bytes): 193 198 If the user's server determines that the contact is authorized to see 199 the user's presence, the user's server return's the user's current 200 presence state to the contact (this is equivalent to the "Initial 201 NOTIFY" in SIP presence). 203 User's server sends presence to contact (170 bytes): 205 209 away 210 be right back 211 0 212 214 If the user subsequently changes her presence, the user's server 215 sends an updated presence notification to the contact. 217 User's server sends updated presence to contact (160 bytes): 219 223 xa 224 bbiab 225 0 226 228 A presence session can include any number of presence changes. 230 When the user goes offline, the user's server sends a presence stanza 231 of type "unavailable" to the contact. 233 User's server sends unavailable presence to contact (96 bytes): 235 240 Naturally, similar protocol flows are generated by the contact during 241 the life of his presence session. 243 4. Analysis 245 To enable valid comparison between SIMPLE and XMPP with regard to 246 interdomain presence scaling, this document adheres as closely as 247 possible to the analysis presented in [PROBLEM], with appropriate 248 modifications given differences between the two technologies. In 249 particular, traffic calculations are based on the following inputs 250 and formulae, where the numbering follows that in [PROBLEM] and the 251 terminology is adjusted to conform to XMPP. 253 4.1. Constants 255 o (C01) Presence session lifetime in hours -- assumed to be 8 hours. 256 o (C02) Presence state changes per hour -- assumed to be 3 times per 257 hour. 258 o (C03) Subscription refresh interval per hour -- does not apply 259 since XMPP presence subscriptions are long-lived. 260 o (C04) Total federated contacts per user -- varies based on the 261 scenario under discussion. 262 o (C05) Number of dialogs to maintain per watcher -- does not apply 263 to XMPP since XMPP presence subscriptions are long-lived, for 264 purposes of calculation treated as equal to C04. 265 o (C06) Number of federated users -- varies based on the scenario 266 under discussion. 267 o (C07) Subscription request size in bytes -- 100 bytes. 268 o (C08) Subscription approval size in bytes -- 100 bytes. 269 o (C09) Presence notification size in bytes -- 200 bytes. 270 o (C10) Presence notification ack size in bytes -- does not apply 271 since XMPP presence notifications are not acked. 272 o (C11) Presence document size in bytes -- does not apply since XMPP 273 presence notifications do not include presence documents. 275 4.2. Initial Messages 277 o (I01) Number of initial subscribe requests per presence session -- 278 the XMPP equivalent is a presence probe, of which there is 1 per 279 contact ( = C04 ), equal in size to a presence subscription 280 request or approval (100 bytes). 281 o (I02) Number of initial subscription approvals per presence 282 session -- does not apply since XMPP presence probes are not 283 acked. 284 o (I03) Number of initial presence notifications -- 1 per contact ( 285 = C04 ). 286 o (I04) Number of initial presence acks -- does not apply since XMPP 287 presence notifications are not acked. 288 o (I05) Total number and bytes of initial subscribe messages -- 289 Number = (I01*C06) and Bytes = (I01*C06*C07). 290 o (I06) Total number and bytes of initial subscribe acks -- Number = 291 (I02*C06) and Bytes = (I02*C06*C07), both equal to zero since I02 292 equals zero for XMPP. 293 o (I07) Total number and bytes of initial notifications -- Number = 294 (I03*C06) and Bytes = (I03*C06*C09), note that this formula does 295 not take into account optimizations of the kind discussed in 296 [PROBLEM]. 298 o (I08) Total number and bytes of initial notification acks -- 299 Number = (I04*C10) and Bytes = (I04*C06*C10), both equal to zero 300 since I02 equals zero for XMPP. 301 o (I09) Total number and bytes of initial messages per presence 302 session -- Number = (numbers in I05+I06+I07+I08) and Bytes = 303 (bytes in I05+I06+I07+I08). 305 4.3. Steady State Messages 307 o (S01) Presence notifications caused by state changes -- (C02*(C01 308 - 2)). 309 o (S02) Notification acks for state change notifications -- zero 310 since XMPP presence notifications are not acked. 311 o (S03) Number and size of presence notifications caused by state 312 changes -- Number = (S01*C06*C04), Bytes = (S01*C06*C04)*(C09+C10+ 313 C11). 314 o (S04) Subscription refreshes -- zero since XMPP presence 315 subscriptions are long-lived. 316 o (S05) Acks for subscription refreshes -- zero since there are no 317 subscription refreshes in XMPP. 318 o (S06) Notify messages caused by subscription refreshes -- zero 319 since there are no subscription refreshes in XMPP. 320 o (S07) Acks for notify messages caused by subscription refreshes -- 321 zero since there are no subscription refreshes in XMPP. 322 o (S08) Number and size of messages caused by subscription refreshes 323 -- zero since there are no subscription refreshes in XMPP. 324 o (S09) Total number and bytes of steady-state messages per session 325 -- Number = (numbers in S03+S08), Bytes = (bytes in S03+S08). 327 4.4. Termination Messages 329 o (T01) Number of terminating subscribe messages -- zero since XMPP 330 presence subscriptions are long-lived. 331 o (T02) Number of acks for terminating subscribe messages -- zero 332 since there are no terminating subscribe messages in XMPP. 333 o (T03) Number of terminating notifications -- in XMPP this is 334 unavailable presence sent when user goes offline = C05. 335 o (T04) Number of acks for terminating notifications -- zero since 336 XMPP presence notifications are not acked. 337 o (T05) Total number and size of terminating subscribe messages -- 338 zero since there are no terminating subscribe messages in XMPP. 339 o (T06) Total number and size of acks for terminating subscribe 340 messages -- zero since there are no terminating subscribe messages 341 in XMPP. 342 o (T07) Total number and size of terminating notifications -- Number 343 = (numbers in T03*C06), Bytes = (T03*C06*(C09+C11)). 345 o (T08) Total number and size of acks for terminating notifications 346 -- zero since XMPP presence notifications are not acked. 347 o (T09) Total number and size of terminating messages per session -- 348 Number = (numbers in T05+T06+T07+T08), Bytes = (bytes in T05+T06+ 349 T07+T08). 351 4.5. Bottom Line 353 o (B01) Total number and bytes per presence session = (I09+S09+T09). 354 o (B02) Total number and bytes per second = (B01/(C01*3600)). 356 5. Scenarios 358 5.1. Basic 360 This scenario assumes two domains, each with 20,000 users, where each 361 user has 4 contacts in the other domain and changes presence 3 times 362 per hour during an 8-hour presence session. The calculations are as 363 follows. 365 CONSTANTS 366 (C01) Presence session lifetime (hours) ....................... 8 367 (C02) Presence state changes per hour ......................... 3 368 (C03) Subscription refresh interval per hour ................ N/A 369 (C04) Total federated contacts per user ....................... 4 370 (C05) Number of dialogs to maintain per watcher ............... 4 371 (C06) Number of federated users .......................... 40,000 372 (C07) Subscription request size in bytes .................... 100 373 (C08) Subscription approval size in bytes ................... 100 374 (C09) Presence notification size in bytes ................... 200 375 (C10) Presence notification ack size in bytes ............... N/A 376 (C11) Presence document size in bytes ....................... N/A 378 INITIAL MESSAGES 379 (I01) Initial subscribe requests per presence session ......... 4 380 (I02) Initial subscription approvals per presence session ..... 0 381 (I03) Number of initial presence notifications ................ 4 382 (I04) Number of initial presence acks ......................... 0 383 (I05) Total number and bytes of initial subscribe messages 384 Number ...................................... 160,000 385 Bytes ................................... 16,000,000 386 (I06) Total number and bytes of initial subscribe acks 387 Number ............................................ 0 388 Bytes ............................................. 0 389 (I07) Total number and bytes of initial notifications 390 Number ...................................... 160,000 391 Bytes ................................... 32,000,000 393 (I08) Total number and bytes of initial notification acks 394 Number ............................................ 0 395 Bytes ............................................. 0 396 (I09) Total number and bytes of initial messages 397 Number ...................................... 320,000 398 Bytes ................................... 48,000,000 400 STEADY STATE MESSAGES 401 (S01) Presence notifications caused by state changes ......... 18 402 (S02) Notification acks for state change notifications ........ 0 403 (S03) Number and size of steady-state presence notifications 404 Number .................................... 2,880,000 405 Bytes ................................... 576,000,000 406 (S04) Subscription refreshes .................................. 0 407 (S05) Acks for subscription refreshes ......................... 0 408 (S06) Notify messages caused by refreshes ..................... 0 409 (S07) Acks for notify messages caused by refreshes ............ 0 410 (S08) Number and size of messages caused by refreshes ......... 0 411 (S09) Total number and bytes of steady-state messages 412 Number .................................... 2,880,000 413 Bytes ................................... 576,000,000 415 TERMINATION MESSAGES 416 (T01) Number of terminating subscribe messages ................ 0 417 (T02) Number of acks for terminating subscribe messages ....... 0 418 (T03) Number of terminating notifications ..................... 4 419 (T04) Number of acks for terminating notifications ............ 0 420 (T05) Total number and size of terminates 421 Number ............................................ 0 422 Bytes ............................................. 0 423 (T06) Total number and size of acks for terminates 424 Number ............................................ 0 425 Bytes ............................................. 0 426 (T07) Total number and size of terminating notifications 427 Number ...................................... 160,000 428 Bytes ................................... 16,000,000 429 (T08) Total number and size of acks for terminating notifications 430 Number ............................................ 0 431 Bytes ............................................. 0 432 (T09) Total number and size of terminating messages per session 433 Number ...................................... 160,000 434 Bytes ................................... 16,000,000 436 BOTTOM LINE 437 (B01) Total number and bytes per presence session 438 Number .................................... 3,360,000 439 Bytes .................................. 640,000,000 440 (B02) Total number and bytes per second 441 Number .......................................... 116 442 Bytes ....................................... 22,222 444 For the bottom-line figures, the comparable numbers for SIMPLE in a 445 non-optimized state (see [PROBLEM]) are 12,800,000 total messages, 446 49,756,800,000 bytes, 444 messages per second, and 1,727,667 bytes 447 per second; thus for this scenario XMPP uses 26% of the messages and 448 1.3% of the bytes used by SIMPLE. 450 5.2. Widely Distributed Inter-Domain Presence 452 This scenario assumes two domains, each with 20,000 users, where each 453 user has 20 contacts in the other domain and changes presence 3 times 454 per hour during an 8-hour presence session. The calculations are as 455 follows. 457 CONSTANTS 458 (C01) Presence session lifetime (hours) ....................... 8 459 (C02) Presence state changes per hour ......................... 3 460 (C03) Subscription refresh interval per hour ................ N/A 461 (C04) Total federated contacts per user ...................... 20 462 (C05) Number of dialogs to maintain per watcher .............. 20 463 (C06) Number of federated users .......................... 40,000 464 (C07) Subscription request size in bytes .................... 100 465 (C08) Subscription approval size in bytes ................... 100 466 (C09) Presence notification size in bytes ................... 200 467 (C09) Presence notification ack size in bytes ............... N/A 468 (C11) Presence document size in bytes ....................... N/A 470 INITIAL MESSAGES 471 (I01) Initial subscribe requests per presence session ........ 20 472 (I02) Initial subscription approvals per presence session ..... 0 473 (I03) Number of initial presence notifications ............... 20 474 (I04) Number of initial presence acks ......................... 0 475 (I05) Total number and bytes of initial subscribe messages 476 Number ...................................... 800,000 477 Bytes ................................... 80,000,000 478 (I06) Total number and bytes of initial subscribe acks 479 Number ............................................ 0 480 Bytes ............................................. 0 481 (I07) Total number and bytes of initial notifications 482 Number ...................................... 800,000 483 Bytes .................................. 160,000,000 484 (I08) Total number and bytes of initial notification acks 485 Number ............................................ 0 486 Bytes ............................................. 0 487 (I09) Total number and bytes of initial messages 488 Number .................................... 1,600,000 489 Bytes .................................. 240,000,000 491 STEADY STATE MESSAGES 492 (S01) Presence notifications caused by state changes ......... 18 493 (S02) Notification acks for state change notifications ........ 0 494 (S03) Number and size of steady-state presence notifications 495 Number ................................... 14,400,000 496 Bytes ................................. 2,880,000,000 497 (S04) Subscription refreshes .................................. 0 498 (S05) Acks for subscription refreshes ......................... 0 499 (S06) Notify messages caused by refreshes ..................... 0 500 (S07) Acks for notify messages caused by refreshes ............ 0 501 (S08) Number and size of messages caused by refreshes ......... 0 502 (S09) Total number and bytes of steady-state messages 503 Number ................................... 14,400,000 504 Bytes ................................. 2,880,000,000 506 TERMINATION MESSAGES 507 (T01) Number of terminating subscribe messages ................ 0 508 (T02) Number of acks for terminating subscribe messages ....... 0 509 (T03) Number of terminating notifications .................... 20 510 (T04) Number of acks for terminating notifications ............ 0 511 (T05) Total number and size of terminates 512 Number ............................................ 0 513 Bytes ............................................. 0 514 (T06) Total number and size of acks for terminates 515 Number ............................................ 0 516 Bytes ............................................. 0 517 (T07) Total number and size of terminating notifications 518 Number ...................................... 800,000 519 Bytes .................................. 160,000,000 520 (T08) Total number and size of acks for terminating notifications 521 Number ............................................ 0 522 Bytes ............................................. 0 523 (T09) Total number and size of terminating messages per session 524 Number ...................................... 800,000 525 Bytes .................................. 160,000,000 527 BOTTOM LINE 528 (B01) Total number and bytes per presence session 529 Number ................................... 16,800,000 530 Bytes ................................ 3,280,000,000 531 (B02) Total number and bytes per second 532 Number .......................................... 583 533 Bytes ...................................... 113,889 535 For the bottom-line figures, the comparable numbers for SIMPLE in a 536 non-optimized state (see [PROBLEM]) are 65,000,000 total messages, 537 248,784,000,000 bytes, 2,222 messages per second, and 8,638,333 bytes 538 per second; thus for this scenario XMPP uses 26% of the messages and 539 1.3% of the bytes used by SIMPLE. 541 5.3. Very Large Network Peering 543 This scenario assumes two domains, each with 10,000,000 users, where 544 each user has 10 contacts in the other domain and changes presence 6 545 times per hour during an 8-hour presence session. The calculations 546 are as follows. 548 CONSTANTS 549 (C01) Presence session lifetime (hours) ....................... 8 550 (C02) Presence state changes per hour ......................... 3 551 (C03) Subscription refresh interval per hour ................ N/A 552 (C04) Total federated contacts per user ...................... 10 553 (C05) Number of dialogs to maintain per watcher .............. 10 554 (C06) Number of federated users ...................... 20,000,000 555 (C07) Subscription request size in bytes .................... 100 556 (C08) Subscription approval size in bytes ................... 100 557 (C09) Presence notification size in bytes ................... 200 558 (C09) Presence notification ack size in bytes ............... N/A 559 (C11) Presence document size in bytes ....................... N/A 561 INITIAL MESSAGES 562 (I01) Initial subscribe requests per presence session ........ 10 563 (I02) Initial subscription approvals per presence session ..... 0 564 (I03) Number of initial presence notifications ............... 10 565 (I04) Number of initial presence acks ......................... 0 566 (I05) Total number and bytes of initial subscribe messages 567 Number .................................. 200,000,000 568 Bytes ............................... 20,000,000,000 569 (I06) Total number and bytes of initial subscribe acks 570 Number ............................................ 0 571 Bytes ............................................. 0 572 (I07) Total number and bytes of initial notifications 573 Number .................................. 200,000,000 574 Bytes ............................... 40,000,000,000 575 (I08) Total number and bytes of initial notification acks 576 Number ............................................ 0 577 Bytes ............................................. 0 578 (I09) Total number and bytes of initial messages 579 Number .................................. 400,000,000 580 Bytes ............................... 60,000,000,000 582 STEADY STATE MESSAGES 583 (S01) Presence notifications caused by state changes ......... 18 584 (S02) Notification acks for state change notifications ........ 0 585 (S03) Number and size of steady-state presence notifications 586 Number ................................ 3,600,000,000 587 Bytes ............................... 720,000,000,000 588 (S04) Subscription refreshes .................................. 0 589 (S05) Acks for subscription refreshes ......................... 0 590 (S06) Notify messages caused by refreshes ..................... 0 591 (S07) Acks for notify messages caused by refreshes ............ 0 592 (S08) Number and size of messages caused by refreshes ......... 0 593 (S09) Total number and bytes of steady-state messages 594 Number ................................ 3,600,000,000 595 Bytes ............................... 720,000,000,000 597 TERMINATION MESSAGES 598 (T01) Number of terminating subscribe messages ................ 0 599 (T02) Number of acks for terminating subscribe messages ....... 0 600 (T03) Number of terminating notifications .................... 10 601 (T04) Number of acks for terminating notifications ............ 0 602 (T05) Total number and size of terminates 603 Number ............................................ 0 604 Bytes ............................................. 0 605 (T06) Total number and size of acks for terminates 606 Number ............................................ 0 607 Bytes ............................................. 0 608 (T07) Total number and size of terminating notifications 609 Number .................................. 200,000,000 610 Bytes ............................... 20,000,000,000 611 (T08) Total number and size of acks for terminating notifications 612 Number ............................................ 0 613 Bytes ............................................. 0 614 (T09) Total number and size of terminating messages per session 615 Number .................................. 200,000,000 616 Bytes ............................... 20,000,000,000 618 BOTTOM LINE 619 (B01) Total number and bytes per presence session 620 Number ................................ 4,200,000,000 621 Bytes ............................... 800,000,000,000 622 (B02) Total number and bytes per second 623 Number ...................................... 145,833 624 Bytes ................................... 27,777,777 626 For the bottom-line figures, the comparable numbers for SIMPLE in a 627 non-optimized state (see [PROBLEM]) are 25,600,000,000 total 628 messages, 99,348,000,000,000 bytes, 888,889 messages per second, and 629 3,449,583,333 bytes per second; thus for this scenario XMPP uses 16% 630 of the messages and 0.8% of the bytes used by SIMPLE. 632 5.4. Intra-Domain Peering 634 This scenario assumes two domains, each with 60,000 users, where each 635 user has 10 contacts in the other domain and changes presence 3 times 636 per hour during an 8-hour presence session. The calculations are as 637 follows. 639 CONSTANTS 640 (C01) Presence session lifetime (hours) ....................... 8 641 (C02) Presence state changes per hour ......................... 3 642 (C03) Subscription refresh interval per hour ................ N/A 643 (C04) Total federated contacts per user ...................... 10 644 (C05) Number of dialogs to maintain per watcher .............. 10 645 (C06) Number of federated users ......................... 120,000 646 (C07) Subscription request size in bytes .................... 100 647 (C08) Subscription approval size in bytes ................... 100 648 (C09) Presence notification size in bytes ................... 200 649 (C09) Presence notification ack size in bytes ............... N/A 650 (C11) Presence document size in bytes ....................... N/A 652 INITIAL MESSAGES 653 (I01) Initial subscribe requests per presence session ........ 10 654 (I02) Initial subscription approvals per presence session ..... 0 655 (I03) Number of initial presence notifications ............... 10 656 (I04) Number of initial presence acks ......................... 0 657 (I05) Total number and bytes of initial subscribe messages 658 Number .................................... 1,200,000 659 Bytes .................................. 120,000,000 660 (I06) Total number and bytes of initial subscribe acks 661 Number ............................................ 0 662 Bytes ............................................. 0 663 (I07) Total number and bytes of initial notifications 664 Number .................................... 1,200,000 665 Bytes .................................. 240,000,000 666 (I08) Total number and bytes of initial notification acks 667 Number ............................................ 0 668 Bytes ............................................. 0 669 (I09) Total number and bytes of initial messages 670 Number .................................... 2,400,000 671 Bytes .................................. 360,000,000 673 STEADY STATE MESSAGES 674 (S01) Presence notifications caused by state changes ......... 18 675 (S02) Notification acks for state change notifications ........ 0 676 (S03) Number and size of steady-state presence notifications 677 Number ................................... 21,600,000 678 Bytes ................................. 4,320,000,000 679 (S04) Subscription refreshes .................................. 0 680 (S05) Acks for subscription refreshes ......................... 0 681 (S06) Notify messages caused by refreshes ..................... 0 682 (S07) Acks for notify messages caused by refreshes ............ 0 683 (S08) Number and size of messages caused by refreshes ......... 0 684 (S09) Total number and bytes of steady-state messages 685 Number ................................... 21,600,000 686 Bytes ................................. 4,320,000,000 688 TERMINATION MESSAGES 689 (T01) Number of terminating subscribe messages ................ 0 690 (T02) Number of acks for terminating subscribe messages ....... 0 691 (T03) Number of terminating notifications .................... 10 692 (T04) Number of acks for terminating notifications ............ 0 693 (T05) Total number and size of terminates 694 Number ............................................ 0 695 Bytes ............................................. 0 696 (T06) Total number and size of acks for terminates 697 Number ............................................ 0 698 Bytes ............................................. 0 699 (T07) Total number and size of terminating notifications 700 Number .................................... 1,200,000 701 Bytes .................................. 240,000,000 702 (T08) Total number and size of acks for terminating notifications 703 Number ............................................ 0 704 Bytes ............................................. 0 705 (T09) Total number and size of terminating messages per session 706 Number .................................... 1,200,000 707 Bytes .................................. 240,000,000 709 BOTTOM LINE 710 (B01) Total number and bytes per presence session 711 Number ................................... 25,200,000 712 Bytes ................................. 4,920,000,000 713 (B02) Total number and bytes per second 714 Number .......................................... 875 715 Bytes ...................................... 170,833 717 For the bottom-line figures, the comparable numbers for SIMPLE in a 718 non-optimized state (see [PROBLEM]) are 96,000,000 total messages, 719 373,176,000,000 bytes, 3,333 messages per second, and 12,957,500 720 bytes per second; thus for this scenario XMPP uses 26% of the 721 messages and 1.3% of the bytes used by SIMPLE. 723 6. Conclusion 725 With respect to presence scaling, the differences between XMPP 726 systems and SIP-based systems are startling. In particular, this 727 analysis indicates that XMPP requires only about 1.5% of the 728 bandwidth required by SIMPLE. There are two primary causes for this 729 disparity: (1) XMPP requires only about 25% of the packets required 730 by SIMPLE and (2) XMPP packets are about 5% of the size of SIMPLE 731 packets for presence notifications and 20% of the size for subscribe 732 packets. Together, these two factors appear to result in a 733 significant disparity with respect to the scalability of presence 734 technologies. Naturally, real-world studies of deployed systems will 735 be necessary to determine if these theorized differences occur in 736 reality. 738 7. Security Considerations 740 This document introduces and addresses no security concerns above and 741 beyond those already defined in [XMPP-CORE] and [XMPP-IM]. 743 8. Informative References 745 [PROBLEM] Houri, A., "Presence Interdomain Scaling Analysis for SIP/ 746 SIMPLE", draft-ietf-simple-interdomain-scaling-analysis-01 747 (work in progress), July 2007. 749 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 750 A., Peterson, J., Sparks, R., Handley, M., and E. 751 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 752 June 2002. 754 [SIP-EVENT] 755 Roach, A., "Session Initiation Protocol (SIP)-Specific 756 Event Notification", RFC 3265, June 2002. 758 [SIP-PRES] 759 Rosenberg, J., "A Presence Event Package for the Session 760 Initiation Protocol (SIP)", RFC 3856, August 2004. 762 [XEP-0060] 763 Millard, P., Saint-Andre, P., and R. Meijer, "Publish- 764 Subscribe", XSF XEP 0060, September 2007. 766 [XEP-0115] 767 Hildebrand, J., Saint-Andre, P., and R. Troncon, "Entity 768 Capabilities", XSF XEP 0115, August 2007. 770 [XEP-0118] 771 Saint-Andre, P., "User Tune", XSF XEP 0118, June 2007. 773 [XEP-0138] 774 Hildebrand, J. and P. Saint-Andre, "Stream Compression", 775 XSF XEP 0138, September 2007. 777 [XEP-0153] 778 Saint-Andre, P., "vCard-Based Avatars", XSF XEP 0153, 779 August 2006. 781 [XEP-0163] 782 Saint-Andre, P. and K. Smith, "Personal Eventing via 783 Pubsub", XSF XEP 0163, September 2007. 785 [XMPP-CORE] 786 Saint-Andre, P., "Extensible Messaging and Presence 787 Protocol (XMPP): Core", RFC 3920, October 2004. 789 [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence 790 Protocol (XMPP): Instant Messaging and Presence", 791 RFC 3921, October 2004. 793 Author's Address 795 Peter Saint-Andre 796 XMPP Standards Foundation 797 P.O. Box 1641 798 Denver, CO 80201 799 USA 801 Email: stpeter@jabber.org 802 URI: https://stpeter.im/ 804 Full Copyright Statement 806 Copyright (C) The IETF Trust (2007). 808 This document is subject to the rights, licenses and restrictions 809 contained in BCP 78, and except as set forth therein, the authors 810 retain all their rights. 812 This document and the information contained herein are provided on an 813 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 814 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 815 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 816 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 817 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 818 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 820 Intellectual Property 822 The IETF takes no position regarding the validity or scope of any 823 Intellectual Property Rights or other rights that might be claimed to 824 pertain to the implementation or use of the technology described in 825 this document or the extent to which any license under such rights 826 might or might not be available; nor does it represent that it has 827 made any independent effort to identify any such rights. Information 828 on the procedures with respect to rights in RFC documents can be 829 found in BCP 78 and BCP 79. 831 Copies of IPR disclosures made to the IETF Secretariat and any 832 assurances of licenses to be made available, or the result of an 833 attempt made to obtain a general license or permission for the use of 834 such proprietary rights by implementers or users of this 835 specification can be obtained from the IETF on-line IPR repository at 836 http://www.ietf.org/ipr. 838 The IETF invites any interested party to bring to its attention any 839 copyrights, patents or patent applications, or other proprietary 840 rights that may cover technology that may be required to implement 841 this standard. Please address the information to the IETF at 842 ietf-ipr@ietf.org. 844 Acknowledgment 846 Funding for the RFC Editor function is provided by the IETF 847 Administrative Support Activity (IASA).