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).