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 "