Network Working Group P. Saint-Andre
Internet-Draft XMPP Standards Foundation
Intended status: Informational January 16, 2008
Expires: July 19, 2008
Interdomain Presence Scaling Analysis for the Extensible Messaging and
Presence Protocol (XMPP)
draft-saintandre-xmpp-presence-analysis-03
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 19, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document analyzes the network impact of presence sharing between
domains that federate using the Extensible Messaging and Presence
Protocol (XMPP).
Saint-Andre Expires July 19, 2008 [Page 1]
Internet-Draft XMPP Presence Analysis January 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Constants . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Initial Stanzas . . . . . . . . . . . . . . . . . . . . . 7
4.3. State-Change Stanzas . . . . . . . . . . . . . . . . . . . 7
4.4. Termination Stanzas . . . . . . . . . . . . . . . . . . . 7
4.5. Bottom Line . . . . . . . . . . . . . . . . . . . . . . . 7
5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Enterprises in Different Industries . . . . . . . . . . . 8
5.2. Enterprises in the Same Industry . . . . . . . . . . . . . 9
5.3. Medium-Sized Service Providers . . . . . . . . . . . . . . 10
5.4. Large Service Providers . . . . . . . . . . . . . . . . . 12
5.5. Very Large Service Providers . . . . . . . . . . . . . . . 13
6. Optimizations . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Comparison With Other Presence Technologies . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Informative References . . . . . . . . . . . . . . . . . . . . 14
Appendix A. Copying Conditions . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Saint-Andre Expires July 19, 2008 [Page 2]
Internet-Draft XMPP Presence Analysis January 2008
1. Introduction
Presence is information about the network availability of an
individual (or, more precisely, of a presence address of the kind
that is often but not necessarily associated with an individual). As
typically designed and deployed, presence is shared only with
authorized entities, where the authorization takes the form of a
subscription. (In this document, we employ the term "user" to
signify an account that generates presence information and the term
"contact" to signify an annount that is subscribed to the user's
presence.)
The sharing of basic presence information can result in a large
volume of traffic as users log on or off throughout the life of a
presence session, especially for users with large numbers of contacts
(e.g., the author of this document has over 1,700 contacts in his
presence-enabled contact list). The volume is increased by
communication of information beyond basic on-off network
availability, such as availability substates (e.g., "away" and "do
not disturb"). The volume is further increased if the presence
"transport" is used to communicate information such as device
capabilities, geolocation, mood, activity, even the music to which a
user is listening.
Such traffic may be a concern even in a standalone presence domain.
However, when presence is shared across domain boundaries through
presence "federation", then such traffic may introduce a more
significant impact on the functioning of the Internet as a whole.
Therefore it is important to analyze the traffic generated during
interdomain communication of presence information. This document
provides such an analysis regarding the Extensible Messaging and
Presence Protocol (XMPP) as defined in [XMPP-CORE] and [XMPP-IM].
2. Assumptions
The XMPP presence model is based on the following assumptions:
1. A user shares presence only with a contact whom the user has
explicitly authorized via a presence subscription.
2. Presence subscriptions are long-lived: they last across presence
sessions and indeed as long as the user and contact maintain
their XMPP accounts (until and unless the subscription is
cancelled by one of the parties).
3. The typical subscription state is a bidirectional subscription
from the contact to the user and from the user to the contact
(so that both entities can view each other's presence).
Saint-Andre Expires July 19, 2008 [Page 3]
Internet-Draft XMPP Presence Analysis January 2008
4. Users have presence sessions, i.e., times in which they
advertise their network availability to their contacts.
5. Not all registered users have an active presence session at any
one time. In typical usage patterns, the number of online users
is some percentage of the number of registered users. Within an
organization, the precentage might be as high as 50%. At a
consumer-oriented provider of presence-enabled communication
services, the percentage might be 10% or less.
6. A presence session is initiated when a user's client sends an
initial presence notification to its server, expressing network
availability.
7. Upon receiving the initial presence notification, a user's
server broadcasts that presence notification to all of the
user's contacts and also sends a presence probe to all of the
user's contacts.
8. Upon receiving a presence probe, a contact's server checks the
contact's authorization policies and, if the user is authorized
and the contact is online, sends a presence notification to the
probing user.
9. During the life of the user's presence session, any subsequent
changes to the user's presence information are broadcasted via
presence notifications sent by the user's server to the user's
online contacts.
10. Presence notifications are not acknowledged by the recipient.
11. Presence notifications are generated by a user's client only to
advertise on-off network availability, availability sub-states
(e.g., "away" or "do not disturb") as defined in [XMPP-IM], or
information related to the communication capabilities of the
user's XMPP client (see [CAPS]). Any other real-time
notifications (a user's activity or mood, the music to which a
user is listening, the games a user is playing, etc.) are not
sent via the XMPP presence "transport" but instead are published
using non-presence technologies such as the XMPP Publish-
Subscribe extension [PUBSUB], in particular the Personal
Eventing profile thereof (see [PEP]).
12. A presence session is terminated when a user's client sends an
unavailable presence notification to its server or the server
detects that the client is no longer online; in either case the
user's server broadcasts an unavailable presence notification to
all of the user's online contacts.
3. Protocol Flows
A user (in these examples romeo@example.net) initiates a presence
session by sending an initial presence notification. To provide a
realistic example, this presence notification includes entity
capabilities information as defined in [CAPS].
Saint-Andre Expires July 19, 2008 [Page 4]
Internet-Draft XMPP Presence Analysis January 2008
User sends initial presence notification (200 bytes):
5
Upon receiving the initial presence notification, the user's server
sends an XMPP presence stanza of type "probe" to the contact (in
these examples juliet@example.com).
User's server sends presence probe to contact (82 bytes):
If the contact's server determines that the user is authorized to see
the contact's presence, the contact's server returns the contact's
current presence state to the user. Here again the presence
notification includes entity capabilities information.
Contact's server sends presence notification to user (311 bytes):
away
be right back
0
If the contact subsequently changes her presence, the contact's
server sends an updated presence notification to the user.
Saint-Andre Expires July 19, 2008 [Page 5]
Internet-Draft XMPP Presence Analysis January 2008
Contact's server sends updated presence to user (301 bytes):
xa
bbiab
0
A presence session can include any number of subsequent presence
changes.
When the user goes offline, the user's server sends a presence stanza
of type "unavailable" to the contact.
User's server sends unavailable presence to contact (96 bytes):
Naturally, similar protocol flows are generated by the contact during
her presence session.
4. Analysis
Traffic calculations are based on the following inputs and formulae.
4.1. Constants
o (C1) Presence session lifetime in hours -- assumed to be 8 hours
in all scenarios.
o (C2) Presence state changes per hour -- assumed to be 3 times per
hour in most scenarios.
o (C3) Total federated contacts per user -- varies according to the
scenario.
o (C4) Number of online contacts -- varies according to the
scenario.
Saint-Andre Expires July 19, 2008 [Page 6]
Internet-Draft XMPP Presence Analysis January 2008
o (C5) Number of federated users -- varies according to the
scenario.
o (C6) Number of online users -- varies according to the scenario.
o (C7) Size of presence probe sent by user's server upon receipt of
initial outbound presence notification -- 100 bytes.
o (C8) Size of presence notifications sent by users and contacts --
300 bytes.
o (C9) Size of unavailable presence notifications -- 100 bytes.
4.2. Initial Stanzas
When a user initiates a presence session, the following presence
stanzas are exchanged.
o (I1) Number of outbound presence notifications = 1 per federated
contact (C3).
o (I2) Size of outbound presence notifications = (C3*C8).
o (I3) Number of presence probes = one per federated contact (C3).
o (I4) Size of presence probes = (C3*C7).
o (I5) Number of inbound presence notifications = 1 per online
contact (C4).
o (I6) Size of inbound presence notifications = (C4*C8).
o (I7) Total number of initial stanzas = (I1+I3+I5).
o (I8) Total size of initial stanzas = (I2+I4+I6).
4.3. State-Change Stanzas
During the life of a user's presence session, the following presence
stanzas are exchanged as a result of changes in the user's
availability.
o (S1) Number of presence state changes per user = (C1*C2)-2).
o (S2) Number of outbound presence notifications = (S1*C4).
o (S3) Size of presence notifications = (S2*C8).
4.4. Termination Stanzas
When a user terminates a presence session, the following presence
stanzas are exchanged.
o (T1) Number of unavailable presence notifications = 1 per online
contact (C4).
o (T2) Size of unavailable presence notifications = (C4*C9).
4.5. Bottom Line
The foregoing assumptions result in the following number and size of
stanzas exchanged per user per presence session.
Saint-Andre Expires July 19, 2008 [Page 7]
Internet-Draft XMPP Presence Analysis January 2008
o (B1) Number of stanzas exchanged per presence session =
(I7+S2+T1).
o (B2) Size of stanzas exchanged per presence session = (I8+S3+T2).
Therefore the total number and size of stanzas exchanged between two
federated domains is as follows (i.e., summed for all online users).
o (B3) Total number of stanzas exchanged = (B1*C6).
o (B4) Total size of stanzas exchanged = (B2*C6).
o (B5) Total stanzas exchanged per second = (B3/(C1*3600)).
o (B6) Total bytes exchanged per second = (B4/(C1*3600)).
5. Scenarios
5.1. Enterprises in Different Industries
This scenario assumes two domains, each with 20,000 users, where each
user has 4 contacts in the other domain, each user changes presence 3
times per hour during an 8-hour presence session, and 50% of the
users are online at any one time. Such a scenario might be
applicable to presence federation between two medium-sized
enterprises in different industries.
Saint-Andre Expires July 19, 2008 [Page 8]
Internet-Draft XMPP Presence Analysis January 2008
CONSTANTS
(C1) Presence session lifetime (hours) ....................... 8
(C2) Presence state changes per hour ......................... 3
(C3) Total federated contacts per user ....................... 4
(C4) Number of online contacts per user ...................... 2
(C5) Number of federated users .......................... 40,000
(C6) Number of online users ............................. 20,000
(C7) Size of presence probes ............................... 100
(C8) Size of presence notifications ........................ 300
(C9) Size of unavailable presence notification ............. 100
INITIAL STANZAS
(I1) Number of outbound presence notifications ............... 4
(I2) Size of outbound presence notifications ............. 1,200
(I3) Number of presence probes per user ...................... 4
(I4) Size of presence probes per user ...................... 400
(I5) Number of inbound presence notifications ................ 2
(I6) Size of inbound presence notifications ................ 600
(I7) Total number of initial stanzas ........................ 10
(I8) Total size of initial stanzas ....................... 2,200
STATE CHANGE STANZAS
(S1) Number of state changes per user ....................... 22
(S2) Number of outbound presence notifications .............. 44
(S3) Size of outbound presence notifications ............ 13,200
TERMINATION MESSAGES
(T1) Number of unavailable presence notifications ............ 2
(T2) Size of unavailable presence notifications ............ 200
BOTTOM LINE
(B1) Number of stanzas per presence session ................. 56
(B2) Size of stanzas per presence session ............... 15,600
(B3) Total number of stanzas exchanged ............... 1,120,000
(B4) Total size of stanzas exchanged ............... 312,000,000
(B5) Total stanzas exchanged per second ..................... 39
(B6) Total bytes exchanged per second ................... 10,833
With compression as described under Section 6, the bytes per second
might be as low as 1,083.
5.2. Enterprises in the Same Industry
This scenario assumes two domains, each with 20,000 users, where each
user has 20 contacts in the other domain, each user changes presence
3 times per hour during an 8-hour presence session, and 50% of the
users are online at any one time. Such a scenario might be
applicable to presence federation between two medium-sized
Saint-Andre Expires July 19, 2008 [Page 9]
Internet-Draft XMPP Presence Analysis January 2008
enterprises in the same industry.
CONSTANTS
(C1) Presence session lifetime (hours) ....................... 8
(C2) Presence state changes per hour ......................... 3
(C3) Total federated contacts per user ...................... 20
(C4) Number of online contacts per user ..................... 10
(C5) Number of federated users .......................... 40,000
(C6) Number of online users ............................. 20,000
(C7) Size of presence probes ............................... 100
(C8) Size of presence notifications ........................ 300
(C9) Size of unavailable presence notification ............. 100
INITIAL STANZAS
(I1) Number of outbound presence notifications .............. 20
(I2) Size of outbound presence notifications ............. 6,000
(I3) Number of presence probes per user ..................... 20
(I4) Size of presence probes per user .................... 2,000
(I5) Number of inbound presence notifications ............... 10
(I6) Size of inbound presence notifications .............. 3,000
(I7) Total number of initial stanzas ........................ 50
(I8) Total size of initial stanzas ...................... 11,000
STATE CHANGE STANZAS
(S1) Number of state changes per user ....................... 22
(S2) Number of outbound presence notifications ............. 220
(S3) Size of outbound presence notifications ............ 66,000
TERMINATION MESSAGES
(T1) Number of unavailable presence notifications ........... 10
(T2) Size of unavailable presence notifications .......... 1,000
BOTTOM LINE
(B1) Number of stanzas per presence session ................ 280
(B2) Size of stanzas per presence session ............... 78,000
(B3) Total number of stanzas exchanged ............... 5,600,000
(B4) Total size of stanzas exchanged ............. 1,560,000,000
(B5) Total stanzas exchanged per second .................... 194
(B6) Total bytes exchanged per second ................... 54,167
With compression as described under Section 6, the bytes per second
might be as low as 5,417.
5.3. Medium-Sized Service Providers
This scenario assumes two domains, each with 60,000 users, where each
user has 10 contacts in the other domain, each user changes presence
3 times per hour during an 8-hour presence session, and 10% of the
Saint-Andre Expires July 19, 2008 [Page 10]
Internet-Draft XMPP Presence Analysis January 2008
users are online at any one time. Such a scenario might be
applicable to presence federation between two medium-sized service
providers.
CONSTANTS
(C1) Presence session lifetime (hours) ....................... 8
(C2) Presence state changes per hour ......................... 3
(C3) Total federated contacts per user ...................... 10
(C4) Number of online contacts per user ...................... 1
(C5) Number of federated users ......................... 120,000
(C6) Number of online users ............................. 60,000
(C7) Size of presence probes ............................... 100
(C8) Size of presence notifications ........................ 300
(C9) Size of unavailable presence notification ............. 100
INITIAL STANZAS
(I1) Number of outbound presence notifications .............. 10
(I2) Size of outbound presence notifications ............. 3,000
(I3) Number of presence probes per user ..................... 10
(I4) Size of presence probes per user .................... 1,000
(I5) Number of inbound presence notifications ................ 1
(I6) Size of inbound presence notifications ................ 300
(I7) Total number of initial stanzas ........................ 21
(I8) Total size of initial stanzas ....................... 4,300
STATE CHANGE STANZAS
(S1) Number of state changes per user ....................... 22
(S2) Number of outbound presence notifications .............. 22
(S3) Size of outbound presence notifications ............. 6,600
TERMINATION MESSAGES
(T1) Number of unavailable presence notifications ............ 1
(T2) Size of unavailable presence notifications ............ 100
BOTTOM LINE
(B1) Number of stanzas per presence session ................. 44
(B2) Size of stanzas per presence session ............... 11,000
(B3) Total number of stanzas exchanged ............... 2,640,000
(B4) Total size of stanzas exchanged ............... 660,000,000
(B5) Total stanzas exchanged per second ..................... 92
(B6) Total bytes exchanged per second ................... 22,917
With compression as described under Section 6, the bytes per second
might be as low as 2,292.
Saint-Andre Expires July 19, 2008 [Page 11]
Internet-Draft XMPP Presence Analysis January 2008
5.4. Large Service Providers
This scenario assumes two domains, each with 300,000 users, where
each user has 20 contacts in the other domain, each user changes
presence 3 times per hour during an 8-hour presence session, and 10%
of the users are online at any one time. Such a scenario might be
applicable to presence federation between two large service
providers.
CONSTANTS
(C1) Presence session lifetime (hours) ....................... 8
(C2) Presence state changes per hour ......................... 3
(C3) Total federated contacts per user ...................... 20
(C4) Number of online contacts per user ...................... 2
(C5) Number of federated users ......................... 600,000
(C6) Number of online users ............................ 300,000
(C7) Size of presence probes ............................... 100
(C8) Size of presence notifications ........................ 300
(C9) Size of unavailable presence notification ............. 100
INITIAL STANZAS
(I1) Number of outbound presence notifications .............. 20
(I2) Size of outbound presence notifications ............. 6,000
(I3) Number of presence probes per user ..................... 20
(I4) Size of presence probes per user .................... 2,000
(I5) Number of inbound presence notifications ................ 2
(I6) Size of inbound presence notifications ................ 600
(I7) Total number of initial stanzas ........................ 42
(I8) Total size of initial stanzas ....................... 8,600
STATE CHANGE STANZAS
(S1) Number of state changes per user ....................... 22
(S2) Number of outbound presence notifications .............. 44
(S3) Size of outbound presence notifications ............ 13,200
TERMINATION MESSAGES
(T1) Number of unavailable presence notifications ............ 2
(T2) Size of unavailable presence notifications ............ 200
BOTTOM LINE
(B1) Number of stanzas per presence session ................. 88
(B2) Size of stanzas per presence session ............... 22,000
(B3) Total number of stanzas exchanged .............. 26,400,000
(B4) Total size of stanzas exchanged ............. 6,600,000,000
(B5) Total stanzas exchanged per second .................... 917
(B6) Total bytes exchanged per second .................. 229,167
With compression as described under Section 6, the bytes per second
Saint-Andre Expires July 19, 2008 [Page 12]
Internet-Draft XMPP Presence Analysis January 2008
might be as low as 22,917.
5.5. Very Large Service Providers
This scenario assumes two domains, each with 10,000,000 users, where
each user has 100 contacts in the other domain, each user changes
presence 6 times per hour during an 8-hour presence session, and 20%
of the users are online at any one time. Such a scenario might be
applicable to presence federation between two very large service
providers.
CONSTANTS
(C1) Presence session lifetime (hours) ....................... 8
(C2) Presence state changes per hour ......................... 6
(C3) Total federated contacts per user ..................... 100
(C4) Number of online contacts per user ..................... 20
(C5) Number of federated users ...................... 20,000,000
(C6) Number of online users .......................... 4,000,000
(C7) Size of presence probes ............................... 100
(C8) Size of presence notifications ........................ 300
(C9) Size of unavailable presence notification ............. 100
INITIAL STANZAS
(I1) Number of outbound presence notifications ............. 100
(I2) Size of outbound presence notifications ............ 30,000
(I3) Number of presence probes per user .................... 100
(I4) Size of presence probes per user ................... 10,000
(I5) Number of inbound presence notifications ............... 20
(I6) Size of inbound presence notifications .............. 6,000
(I7) Total number of initial stanzas ....................... 220
(I8) Total size of initial stanzas ...................... 46,000
STATE CHANGE STANZAS
(S1) Number of state changes per user ....................... 46
(S2) Number of outbound presence notifications ............. 920
(S3) Size of outbound presence notifications ........... 276,000
TERMINATION MESSAGES
(T1) Number of unavailable presence notifications ........... 20
(T2) Size of unavailable presence notifications .......... 2,000
BOTTOM LINE
(B1) Number of stanzas per presence session .............. 1,160
(B2) Size of stanzas per presence session .............. 324,000
(B3) Total number of stanzas exchanged ........... 4,640,000,000
(B4) Total size of stanzas exchanged ......... 1,296,000,000,000
(B5) Total stanzas exchanged per second ................ 161,111
(B6) Total bytes exchanged per second ............... 45,000,000
Saint-Andre Expires July 19, 2008 [Page 13]
Internet-Draft XMPP Presence Analysis January 2008
With compression as described under Section 6, the bytes per second
might be as low as 4,500,000.
6. Optimizations
This document does not focus on optimizations that can be applied to
XMPP traffic. The main such optimization is compression of XML
streams. There are several reasons why stream compression can yield
significant reductions in the network impact of XMPP traffic,
especially in the case of interdomain federation:
1. XMPP uses long-lived TCP connections in which (typically) a
single XML parser instance is used to parse the incoming and
outgoing XML stanzas.
2. The fact that XMPP stanzas are XML means that the same strings
are repeatedly communicated over the stream (e.g., the string
"