idnits 2.17.1 draft-saintandre-xmpp-presence-analysis-03.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 692. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 703. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 710. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 716. 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 (January 16, 2008) is 5943 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-03 -- 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 (==), 9 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 January 16, 2008 5 Expires: July 19, 2008 7 Interdomain Presence Scaling Analysis for the Extensible Messaging and 8 Presence Protocol (XMPP) 9 draft-saintandre-xmpp-presence-analysis-03 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 July 19, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document analyzes the network impact of presence sharing between 43 domains that federate using the Extensible Messaging and Presence 44 Protocol (XMPP). 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . . 4 51 4. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 52 4.1. Constants . . . . . . . . . . . . . . . . . . . . . . . . 6 53 4.2. Initial Stanzas . . . . . . . . . . . . . . . . . . . . . 7 54 4.3. State-Change Stanzas . . . . . . . . . . . . . . . . . . . 7 55 4.4. Termination Stanzas . . . . . . . . . . . . . . . . . . . 7 56 4.5. Bottom Line . . . . . . . . . . . . . . . . . . . . . . . 7 57 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 5.1. Enterprises in Different Industries . . . . . . . . . . . 8 59 5.2. Enterprises in the Same Industry . . . . . . . . . . . . . 9 60 5.3. Medium-Sized Service Providers . . . . . . . . . . . . . . 10 61 5.4. Large Service Providers . . . . . . . . . . . . . . . . . 12 62 5.5. Very Large Service Providers . . . . . . . . . . . . . . . 13 63 6. Optimizations . . . . . . . . . . . . . . . . . . . . . . . . 14 64 7. Comparison With Other Presence Technologies . . . . . . . . . 14 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 66 9. Informative References . . . . . . . . . . . . . . . . . . . . 14 67 Appendix A. Copying Conditions . . . . . . . . . . . . . . . . . 15 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 69 Intellectual Property and Copyright Statements . . . . . . . . . . 17 71 1. Introduction 73 Presence is information about the network availability of an 74 individual (or, more precisely, of a presence address of the kind 75 that is often but not necessarily associated with an individual). As 76 typically designed and deployed, presence is shared only with 77 authorized entities, where the authorization takes the form of a 78 subscription. (In this document, we employ the term "user" to 79 signify an account that generates presence information and the term 80 "contact" to signify an annount that is subscribed to the user's 81 presence.) 83 The sharing of basic presence information can result in a large 84 volume of traffic as users log on or off throughout the life of a 85 presence session, especially for users with large numbers of contacts 86 (e.g., the author of this document has over 1,700 contacts in his 87 presence-enabled contact list). The volume is increased by 88 communication of information beyond basic on-off network 89 availability, such as availability substates (e.g., "away" and "do 90 not disturb"). The volume is further increased if the presence 91 "transport" is used to communicate information such as device 92 capabilities, geolocation, mood, activity, even the music to which a 93 user is listening. 95 Such traffic may be a concern even in a standalone presence domain. 96 However, when presence is shared across domain boundaries through 97 presence "federation", then such traffic may introduce a more 98 significant impact on the functioning of the Internet as a whole. 99 Therefore it is important to analyze the traffic generated during 100 interdomain communication of presence information. This document 101 provides such an analysis regarding the Extensible Messaging and 102 Presence Protocol (XMPP) as defined in [XMPP-CORE] and [XMPP-IM]. 104 2. Assumptions 106 The XMPP presence model is based on the following assumptions: 108 1. A user shares presence only with a contact whom the user has 109 explicitly authorized via a presence subscription. 110 2. Presence subscriptions are long-lived: they last across presence 111 sessions and indeed as long as the user and contact maintain 112 their XMPP accounts (until and unless the subscription is 113 cancelled by one of the parties). 114 3. The typical subscription state is a bidirectional subscription 115 from the contact to the user and from the user to the contact 116 (so that both entities can view each other's presence). 118 4. Users have presence sessions, i.e., times in which they 119 advertise their network availability to their contacts. 120 5. Not all registered users have an active presence session at any 121 one time. In typical usage patterns, the number of online users 122 is some percentage of the number of registered users. Within an 123 organization, the precentage might be as high as 50%. At a 124 consumer-oriented provider of presence-enabled communication 125 services, the percentage might be 10% or less. 126 6. A presence session is initiated when a user's client sends an 127 initial presence notification to its server, expressing network 128 availability. 129 7. Upon receiving the initial presence notification, a user's 130 server broadcasts that presence notification to all of the 131 user's contacts and also sends a presence probe to all of the 132 user's contacts. 133 8. Upon receiving a presence probe, a contact's server checks the 134 contact's authorization policies and, if the user is authorized 135 and the contact is online, sends a presence notification to the 136 probing user. 137 9. During the life of the user's presence session, any subsequent 138 changes to the user's presence information are broadcasted via 139 presence notifications sent by the user's server to the user's 140 online contacts. 141 10. Presence notifications are not acknowledged by the recipient. 142 11. Presence notifications are generated by a user's client only to 143 advertise on-off network availability, availability sub-states 144 (e.g., "away" or "do not disturb") as defined in [XMPP-IM], or 145 information related to the communication capabilities of the 146 user's XMPP client (see [CAPS]). Any other real-time 147 notifications (a user's activity or mood, the music to which a 148 user is listening, the games a user is playing, etc.) are not 149 sent via the XMPP presence "transport" but instead are published 150 using non-presence technologies such as the XMPP Publish- 151 Subscribe extension [PUBSUB], in particular the Personal 152 Eventing profile thereof (see [PEP]). 153 12. A presence session is terminated when a user's client sends an 154 unavailable presence notification to its server or the server 155 detects that the client is no longer online; in either case the 156 user's server broadcasts an unavailable presence notification to 157 all of the user's online contacts. 159 3. Protocol Flows 161 A user (in these examples romeo@example.net) initiates a presence 162 session by sending an initial presence notification. To provide a 163 realistic example, this presence notification includes entity 164 capabilities information as defined in [CAPS]. 166 User sends initial presence notification (200 bytes): 168 169 5 170 174 176 Upon receiving the initial presence notification, the user's server 177 sends an XMPP presence stanza of type "probe" to the contact (in 178 these examples juliet@example.com). 180 User's server sends presence probe to contact (82 bytes): 182 187 If the contact's server determines that the user is authorized to see 188 the contact's presence, the contact's server returns the contact's 189 current presence state to the user. Here again the presence 190 notification includes entity capabilities information. 192 Contact's server sends presence notification to user (311 bytes): 194 198 away 199 be right back 200 0 201 206 208 If the contact subsequently changes her presence, the contact's 209 server sends an updated presence notification to the user. 211 Contact's server sends updated presence to user (301 bytes): 213 217 xa 218 bbiab 219 0 220 225 227 A presence session can include any number of subsequent presence 228 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 her presence session. 243 4. Analysis 245 Traffic calculations are based on the following inputs and formulae. 247 4.1. Constants 249 o (C1) Presence session lifetime in hours -- assumed to be 8 hours 250 in all scenarios. 251 o (C2) Presence state changes per hour -- assumed to be 3 times per 252 hour in most scenarios. 253 o (C3) Total federated contacts per user -- varies according to the 254 scenario. 255 o (C4) Number of online contacts -- varies according to the 256 scenario. 258 o (C5) Number of federated users -- varies according to the 259 scenario. 260 o (C6) Number of online users -- varies according to the scenario. 261 o (C7) Size of presence probe sent by user's server upon receipt of 262 initial outbound presence notification -- 100 bytes. 263 o (C8) Size of presence notifications sent by users and contacts -- 264 300 bytes. 265 o (C9) Size of unavailable presence notifications -- 100 bytes. 267 4.2. Initial Stanzas 269 When a user initiates a presence session, the following presence 270 stanzas are exchanged. 272 o (I1) Number of outbound presence notifications = 1 per federated 273 contact (C3). 274 o (I2) Size of outbound presence notifications = (C3*C8). 275 o (I3) Number of presence probes = one per federated contact (C3). 276 o (I4) Size of presence probes = (C3*C7). 277 o (I5) Number of inbound presence notifications = 1 per online 278 contact (C4). 279 o (I6) Size of inbound presence notifications = (C4*C8). 280 o (I7) Total number of initial stanzas = (I1+I3+I5). 281 o (I8) Total size of initial stanzas = (I2+I4+I6). 283 4.3. State-Change Stanzas 285 During the life of a user's presence session, the following presence 286 stanzas are exchanged as a result of changes in the user's 287 availability. 289 o (S1) Number of presence state changes per user = (C1*C2)-2). 290 o (S2) Number of outbound presence notifications = (S1*C4). 291 o (S3) Size of presence notifications = (S2*C8). 293 4.4. Termination Stanzas 295 When a user terminates a presence session, the following presence 296 stanzas are exchanged. 298 o (T1) Number of unavailable presence notifications = 1 per online 299 contact (C4). 300 o (T2) Size of unavailable presence notifications = (C4*C9). 302 4.5. Bottom Line 304 The foregoing assumptions result in the following number and size of 305 stanzas exchanged per user per presence session. 307 o (B1) Number of stanzas exchanged per presence session = 308 (I7+S2+T1). 309 o (B2) Size of stanzas exchanged per presence session = (I8+S3+T2). 311 Therefore the total number and size of stanzas exchanged between two 312 federated domains is as follows (i.e., summed for all online users). 314 o (B3) Total number of stanzas exchanged = (B1*C6). 315 o (B4) Total size of stanzas exchanged = (B2*C6). 316 o (B5) Total stanzas exchanged per second = (B3/(C1*3600)). 317 o (B6) Total bytes exchanged per second = (B4/(C1*3600)). 319 5. Scenarios 321 5.1. Enterprises in Different Industries 323 This scenario assumes two domains, each with 20,000 users, where each 324 user has 4 contacts in the other domain, each user changes presence 3 325 times per hour during an 8-hour presence session, and 50% of the 326 users are online at any one time. Such a scenario might be 327 applicable to presence federation between two medium-sized 328 enterprises in different industries. 330 CONSTANTS 331 (C1) Presence session lifetime (hours) ....................... 8 332 (C2) Presence state changes per hour ......................... 3 333 (C3) Total federated contacts per user ....................... 4 334 (C4) Number of online contacts per user ...................... 2 335 (C5) Number of federated users .......................... 40,000 336 (C6) Number of online users ............................. 20,000 337 (C7) Size of presence probes ............................... 100 338 (C8) Size of presence notifications ........................ 300 339 (C9) Size of unavailable presence notification ............. 100 341 INITIAL STANZAS 342 (I1) Number of outbound presence notifications ............... 4 343 (I2) Size of outbound presence notifications ............. 1,200 344 (I3) Number of presence probes per user ...................... 4 345 (I4) Size of presence probes per user ...................... 400 346 (I5) Number of inbound presence notifications ................ 2 347 (I6) Size of inbound presence notifications ................ 600 348 (I7) Total number of initial stanzas ........................ 10 349 (I8) Total size of initial stanzas ....................... 2,200 351 STATE CHANGE STANZAS 352 (S1) Number of state changes per user ....................... 22 353 (S2) Number of outbound presence notifications .............. 44 354 (S3) Size of outbound presence notifications ............ 13,200 356 TERMINATION MESSAGES 357 (T1) Number of unavailable presence notifications ............ 2 358 (T2) Size of unavailable presence notifications ............ 200 360 BOTTOM LINE 361 (B1) Number of stanzas per presence session ................. 56 362 (B2) Size of stanzas per presence session ............... 15,600 363 (B3) Total number of stanzas exchanged ............... 1,120,000 364 (B4) Total size of stanzas exchanged ............... 312,000,000 365 (B5) Total stanzas exchanged per second ..................... 39 366 (B6) Total bytes exchanged per second ................... 10,833 368 With compression as described under Section 6, the bytes per second 369 might be as low as 1,083. 371 5.2. Enterprises in the Same Industry 373 This scenario assumes two domains, each with 20,000 users, where each 374 user has 20 contacts in the other domain, each user changes presence 375 3 times per hour during an 8-hour presence session, and 50% of the 376 users are online at any one time. Such a scenario might be 377 applicable to presence federation between two medium-sized 378 enterprises in the same industry. 380 CONSTANTS 381 (C1) Presence session lifetime (hours) ....................... 8 382 (C2) Presence state changes per hour ......................... 3 383 (C3) Total federated contacts per user ...................... 20 384 (C4) Number of online contacts per user ..................... 10 385 (C5) Number of federated users .......................... 40,000 386 (C6) Number of online users ............................. 20,000 387 (C7) Size of presence probes ............................... 100 388 (C8) Size of presence notifications ........................ 300 389 (C9) Size of unavailable presence notification ............. 100 391 INITIAL STANZAS 392 (I1) Number of outbound presence notifications .............. 20 393 (I2) Size of outbound presence notifications ............. 6,000 394 (I3) Number of presence probes per user ..................... 20 395 (I4) Size of presence probes per user .................... 2,000 396 (I5) Number of inbound presence notifications ............... 10 397 (I6) Size of inbound presence notifications .............. 3,000 398 (I7) Total number of initial stanzas ........................ 50 399 (I8) Total size of initial stanzas ...................... 11,000 401 STATE CHANGE STANZAS 402 (S1) Number of state changes per user ....................... 22 403 (S2) Number of outbound presence notifications ............. 220 404 (S3) Size of outbound presence notifications ............ 66,000 406 TERMINATION MESSAGES 407 (T1) Number of unavailable presence notifications ........... 10 408 (T2) Size of unavailable presence notifications .......... 1,000 410 BOTTOM LINE 411 (B1) Number of stanzas per presence session ................ 280 412 (B2) Size of stanzas per presence session ............... 78,000 413 (B3) Total number of stanzas exchanged ............... 5,600,000 414 (B4) Total size of stanzas exchanged ............. 1,560,000,000 415 (B5) Total stanzas exchanged per second .................... 194 416 (B6) Total bytes exchanged per second ................... 54,167 418 With compression as described under Section 6, the bytes per second 419 might be as low as 5,417. 421 5.3. Medium-Sized Service Providers 423 This scenario assumes two domains, each with 60,000 users, where each 424 user has 10 contacts in the other domain, each user changes presence 425 3 times per hour during an 8-hour presence session, and 10% of the 426 users are online at any one time. Such a scenario might be 427 applicable to presence federation between two medium-sized service 428 providers. 430 CONSTANTS 431 (C1) Presence session lifetime (hours) ....................... 8 432 (C2) Presence state changes per hour ......................... 3 433 (C3) Total federated contacts per user ...................... 10 434 (C4) Number of online contacts per user ...................... 1 435 (C5) Number of federated users ......................... 120,000 436 (C6) Number of online users ............................. 60,000 437 (C7) Size of presence probes ............................... 100 438 (C8) Size of presence notifications ........................ 300 439 (C9) Size of unavailable presence notification ............. 100 441 INITIAL STANZAS 442 (I1) Number of outbound presence notifications .............. 10 443 (I2) Size of outbound presence notifications ............. 3,000 444 (I3) Number of presence probes per user ..................... 10 445 (I4) Size of presence probes per user .................... 1,000 446 (I5) Number of inbound presence notifications ................ 1 447 (I6) Size of inbound presence notifications ................ 300 448 (I7) Total number of initial stanzas ........................ 21 449 (I8) Total size of initial stanzas ....................... 4,300 451 STATE CHANGE STANZAS 452 (S1) Number of state changes per user ....................... 22 453 (S2) Number of outbound presence notifications .............. 22 454 (S3) Size of outbound presence notifications ............. 6,600 456 TERMINATION MESSAGES 457 (T1) Number of unavailable presence notifications ............ 1 458 (T2) Size of unavailable presence notifications ............ 100 460 BOTTOM LINE 461 (B1) Number of stanzas per presence session ................. 44 462 (B2) Size of stanzas per presence session ............... 11,000 463 (B3) Total number of stanzas exchanged ............... 2,640,000 464 (B4) Total size of stanzas exchanged ............... 660,000,000 465 (B5) Total stanzas exchanged per second ..................... 92 466 (B6) Total bytes exchanged per second ................... 22,917 468 With compression as described under Section 6, the bytes per second 469 might be as low as 2,292. 471 5.4. Large Service Providers 473 This scenario assumes two domains, each with 300,000 users, where 474 each user has 20 contacts in the other domain, each user changes 475 presence 3 times per hour during an 8-hour presence session, and 10% 476 of the users are online at any one time. Such a scenario might be 477 applicable to presence federation between two large service 478 providers. 480 CONSTANTS 481 (C1) Presence session lifetime (hours) ....................... 8 482 (C2) Presence state changes per hour ......................... 3 483 (C3) Total federated contacts per user ...................... 20 484 (C4) Number of online contacts per user ...................... 2 485 (C5) Number of federated users ......................... 600,000 486 (C6) Number of online users ............................ 300,000 487 (C7) Size of presence probes ............................... 100 488 (C8) Size of presence notifications ........................ 300 489 (C9) Size of unavailable presence notification ............. 100 491 INITIAL STANZAS 492 (I1) Number of outbound presence notifications .............. 20 493 (I2) Size of outbound presence notifications ............. 6,000 494 (I3) Number of presence probes per user ..................... 20 495 (I4) Size of presence probes per user .................... 2,000 496 (I5) Number of inbound presence notifications ................ 2 497 (I6) Size of inbound presence notifications ................ 600 498 (I7) Total number of initial stanzas ........................ 42 499 (I8) Total size of initial stanzas ....................... 8,600 501 STATE CHANGE STANZAS 502 (S1) Number of state changes per user ....................... 22 503 (S2) Number of outbound presence notifications .............. 44 504 (S3) Size of outbound presence notifications ............ 13,200 506 TERMINATION MESSAGES 507 (T1) Number of unavailable presence notifications ............ 2 508 (T2) Size of unavailable presence notifications ............ 200 510 BOTTOM LINE 511 (B1) Number of stanzas per presence session ................. 88 512 (B2) Size of stanzas per presence session ............... 22,000 513 (B3) Total number of stanzas exchanged .............. 26,400,000 514 (B4) Total size of stanzas exchanged ............. 6,600,000,000 515 (B5) Total stanzas exchanged per second .................... 917 516 (B6) Total bytes exchanged per second .................. 229,167 518 With compression as described under Section 6, the bytes per second 519 might be as low as 22,917. 521 5.5. Very Large Service Providers 523 This scenario assumes two domains, each with 10,000,000 users, where 524 each user has 100 contacts in the other domain, each user changes 525 presence 6 times per hour during an 8-hour presence session, and 20% 526 of the users are online at any one time. Such a scenario might be 527 applicable to presence federation between two very large service 528 providers. 530 CONSTANTS 531 (C1) Presence session lifetime (hours) ....................... 8 532 (C2) Presence state changes per hour ......................... 6 533 (C3) Total federated contacts per user ..................... 100 534 (C4) Number of online contacts per user ..................... 20 535 (C5) Number of federated users ...................... 20,000,000 536 (C6) Number of online users .......................... 4,000,000 537 (C7) Size of presence probes ............................... 100 538 (C8) Size of presence notifications ........................ 300 539 (C9) Size of unavailable presence notification ............. 100 541 INITIAL STANZAS 542 (I1) Number of outbound presence notifications ............. 100 543 (I2) Size of outbound presence notifications ............ 30,000 544 (I3) Number of presence probes per user .................... 100 545 (I4) Size of presence probes per user ................... 10,000 546 (I5) Number of inbound presence notifications ............... 20 547 (I6) Size of inbound presence notifications .............. 6,000 548 (I7) Total number of initial stanzas ....................... 220 549 (I8) Total size of initial stanzas ...................... 46,000 551 STATE CHANGE STANZAS 552 (S1) Number of state changes per user ....................... 46 553 (S2) Number of outbound presence notifications ............. 920 554 (S3) Size of outbound presence notifications ........... 276,000 556 TERMINATION MESSAGES 557 (T1) Number of unavailable presence notifications ........... 20 558 (T2) Size of unavailable presence notifications .......... 2,000 560 BOTTOM LINE 561 (B1) Number of stanzas per presence session .............. 1,160 562 (B2) Size of stanzas per presence session .............. 324,000 563 (B3) Total number of stanzas exchanged ........... 4,640,000,000 564 (B4) Total size of stanzas exchanged ......... 1,296,000,000,000 565 (B5) Total stanzas exchanged per second ................ 161,111 566 (B6) Total bytes exchanged per second ............... 45,000,000 567 With compression as described under Section 6, the bytes per second 568 might be as low as 4,500,000. 570 6. Optimizations 572 This document does not focus on optimizations that can be applied to 573 XMPP traffic. The main such optimization is compression of XML 574 streams. There are several reasons why stream compression can yield 575 significant reductions in the network impact of XMPP traffic, 576 especially in the case of interdomain federation: 578 1. XMPP uses long-lived TCP connections in which (typically) a 579 single XML parser instance is used to parse the incoming and 580 outgoing XML stanzas. 581 2. The fact that XMPP stanzas are XML means that the same strings 582 are repeatedly communicated over the stream (e.g., the string 583 "