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