SIMPLE WG A. Houri
Internet-Draft IBM
Intended status: Informational T. Rang
Expires: January 25, 2008 Microsoft Corporation
E. Aoki
AOL LLC
V. Singh
H. Schulzrinne
Columbia U.
October 29, 2007
Presence Interdomain Scaling Analysis for SIP/SIMPLE
draft-ietf-simple-interdomain-scaling-analysis-02.txt
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 January 25, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The document analyses the traffic that is generated due to presence
subscriptions between domains. It is shown that the amount of
Houri, et al. Expires January 25, 2008 [Page 1]
Internet-Draft Presence Scaling Analysis July 2007
traffic can be extremely big. In addition to the very large traffic
the document also analyses the affects of a large presence system on
the memory footprint and the CPU load. Current approved and in work
optimizations to the SIMPLE protocol are analysed with the possible
impact on the load. Separate documents contain the requirements for
optimizations and suggestions for new optimizations.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Message Load . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Known Optimizations . . . . . . . . . . . . . . . . . . . 5
2.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1. Constants . . . . . . . . . . . . . . . . . . . . . . 7
2.3.2. Initial Messages . . . . . . . . . . . . . . . . . . . 8
2.3.3. Steady State Messages . . . . . . . . . . . . . . . . 9
2.3.4. Termination Messages . . . . . . . . . . . . . . . . . 10
2.3.5. Bottom Line . . . . . . . . . . . . . . . . . . . . . 10
2.3.6. Rush Hour Calculations . . . . . . . . . . . . . . . . 10
2.4. SIMPLE with no optimizations . . . . . . . . . . . . . . . 11
2.5. SIMPLE with dialog optimization . . . . . . . . . . . . . 13
2.6. SIMPLE with NOTIFY optimization . . . . . . . . . . . . . 15
2.7. SIMPLE with Dialog & NOTIFY optimizations . . . . . . . . 17
2.8. Presence Federations . . . . . . . . . . . . . . . . . . . 19
2.8.1. Widely distributed inter-domain presence . . . . . . . 19
2.8.2. Associated inter-domain presence . . . . . . . . . . . 23
2.8.3. Very large network peering . . . . . . . . . . . . . . 24
2.8.4. Intra-domain peering . . . . . . . . . . . . . . . . . 28
2.9. Partial Notifications Optimization . . . . . . . . . . . . 32
2.10. Other Protocols . . . . . . . . . . . . . . . . . . . . . 34
3. State Management . . . . . . . . . . . . . . . . . . . . . . . 37
3.1. State Size Calculations . . . . . . . . . . . . . . . . . 38
3.1.1. Tiny System . . . . . . . . . . . . . . . . . . . . . 38
3.1.2. Medium System . . . . . . . . . . . . . . . . . . . . 38
3.1.3. Large System . . . . . . . . . . . . . . . . . . . . . 38
3.1.4. Very Large System . . . . . . . . . . . . . . . . . . 38
4. Processing complexities . . . . . . . . . . . . . . . . . . . 39
4.1. Aggregation . . . . . . . . . . . . . . . . . . . . . . . 40
4.2. Partial Publish and Notify . . . . . . . . . . . . . . . . 40
4.3. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 41
4.5. Resource List Service . . . . . . . . . . . . . . . . . . 41
5. Current Optimizations . . . . . . . . . . . . . . . . . . . . 42
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 43
7. Security Considerations . . . . . . . . . . . . . . . . . . . 44
8. Changes from Previous Versions . . . . . . . . . . . . . . . . 45
Houri, et al. Expires January 25, 2008 [Page 2]
Internet-Draft Presence Scaling Analysis July 2007
8.1. Changes in version 02 . . . . . . . . . . . . . . . . . . 45
8.2. Changes in version 01 . . . . . . . . . . . . . . . . . . 45
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
10.1. Normative References . . . . . . . . . . . . . . . . . . . 45
10.2. Informational References . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
Intellectual Property and Copyright Statements . . . . . . . . . . 49
Houri, et al. Expires January 25, 2008 [Page 3]
Internet-Draft Presence Scaling Analysis July 2007
1. Introduction
The document analyses the traffic that is generated due to presence
subscriptions between domains. It is shown that the amount of
traffic can be extremely big. In addition to the very large traffic
the document also analyses the affects of a large presence system on
the memory footprint and the CPU load. Current approved and in work
optimizations to the SIMPLE protocol are analysed with the possible
impact on the load. Separate documents contain the requirements for
optimizations [17] and suggestions for new optimizations [18].
This document is intended to be used by the SIMPLE WG in order to
work on possible solutions that will make the deployment of a
presence server more reasonable task. Note that the document does
not try to compare the SIP based presence server to other types of
presence servers but only analyses the SIP based presence server. It
is very likely that similar scalability issues are inherent to the
deployment of presence systems and not to a certain protocol.
The document discusses the following areas. In each area we try to
show the complexity and the load that the presence server has to
handle in order to provide its service.
o Messages load - By computing the number of messages that are
required for connecting presence systems the document shows that
the number of messages is very big and it is quite obvious that
some optimizations are needed. In addition we also show that the
bandwidth required is also very big.
o State management - Due to the nature of the service that the
presence server provides, the presence server has to manage a
relatively big and complex state and some computations are
provided in the document.
o Processing complexities - The presence server maintains many small
objects and has to do frequent operations on these objects. We
show that these operations and especially the optimizations that
are intended to save on the amount of data that is being sent
between watchers and presence servers, are not so simple and may
create a very heavy processing load on the presence server.
o Groups - Resource List Servers [10] optimize the number of
sessions that are created between the watchers and the presence
server. On the other hand, this optimization may create an
exponential size of subscription due to the unbearable ease of
subscribing to large groups.
The term presence domain or presence system appears in the document
several time. By this term we refer to a presence server that
provides presence subscription and notification services to its
users. The system can be a system that is deployed in a small
Houri, et al. Expires January 25, 2008 [Page 4]
Internet-Draft Presence Scaling Analysis July 2007
enterprise or in a very large consumer network.
2. Message Load
Even though some optimizations are approved or are being defined, we
show in this section that a very large number of messages & large
bandwidth are needed in order to establish federation between
presence systems of large communities. Further thinking is needed in
order to make large deployment of presence systems less resource
demanding.
Note that even though this document talks about inter domain traffic,
the introduction of resource list servers (RLSs) [10] introduce very
similar traffic pattern within a domain as between domains. See
detailed discussion on resource lists in Section 4.5.
2.1. Known Optimizations
The current optimizations that are approved or are approved as
working group items in the SIMPLE working group can be divided into
two categories:
o Dialogs saving optimization - Here we refer to optimizations as
the resource list RFC [10] or to the Uri list subscriptions draft
[15]. These documents define ways to reduce the number of dialogs
that are required between the subscriber and the presence system.
o Notification optimizations - Here we refer to the optimizations
that are suggested in the subnot-etags draft [16]. This draft
suggests ways to suppress the sending of unnecessary notifies when
for example a subscription is refreshed. There are other drafts
that reduce the size of messages as partial notifies or filtering
but in this document we mostly care about the amount of messages &
bandwidth so the partial optimizations can help a bit in the
bandwidth but will not help in the number of messages.
2.2. Assumptions
In the document we have several assumptions regarding size of
messages, rate of presence change and more. It should be noted that
these assumptions are not directly based on rigorous statistics that
was done on actual SIP based messages but more from experience on
other types of presence based systems.
Even though the assumptions in this document are not based on
rigorous statistical data the target here is not to analyse specific
system but show that even with VERY moderate assumptions, the number
of messages, the network bandwidth, the required state management and
Houri, et al. Expires January 25, 2008 [Page 5]
Internet-Draft Presence Scaling Analysis July 2007
the load on the CPU is very high. Real life systems should have a
much bigger scalability requirements. for example the presence state
change that we assumed (one presence state change per hour) is maybe
one of the most moderate assumptions that we have taken. Experience
from consumer networks show that the frequency here is much bigger
and especially with the younger generation. In an environment where
a user may have several devices and other resources for presence
information as geographical location and calendar the frequency of
presence state changes will be much higher.
It is very hard to measure presence load since the behavior of users
is very different. Some users will have a very small number of
presentities in their watch list while others may have hundreds.
Some users will change their state a lot and have many sources of
presence information while others may have very small number of
changes during the day. In addition the "rush hour" calculation of
when the day starts and ends was not included yet in this document
yet (to be added). Rush hour differs between different enterprises
and is still different in the consumer presence systems. It is very
hard if not impossible to take into a static model all the possible
combinations.
Saying the above, there are still several things to be done to create
a more complete picture:
o Get rigorous statistical data that can be formally published from
real presence systems.
o Add to the model the possibility of having multiple sources of
presence data per presentity and change calculations accordingly
o Add "rush hour" calculations for the end and the beginning of the
day
The authors will especially appreciate any input in this area that
will help us to create a more real life model. We intend to try and
gather more data and improve the assumptions and the model in the
next revisions of this document.
2.3. Analysis
The basic SIMPLE subscription dialog involves the following message-
transfer:
o SUBSCRIBE/200
o Initial NOTIFY/200
o (j) NOTIFY/200 where 'j' is the number of presence changes seen by
the watcher
Houri, et al. Expires January 25, 2008 [Page 6]
Internet-Draft Presence Scaling Analysis July 2007
o (k) SUBSCRIBE/200 where 'k' is the number of subscription dialog
refresh periods
o SUBSCRIBE/200 with Expires = 0 to terminate the dialog
o NOTIFY/200 ending the dialog
An individual watcher will generate X number of SIMPLE subscription
dialogs corresponding to the number of presentities it chooses to
watch. The amount of traffic generated is significantly affected by
several factors:
o Number of watchers connected to the system
o Number of presentities connected to the system
o Frequency of changes to presence information
This document contains several calculations that show the expected
message rate and bandwidth between presence domains. The following
sections explain the assumptions and methods behind the calculations.
2.3.1. Constants
The following are number of "constants" that we use in the
calculations. Some of the constants are used throughout the
calculation while other change between use cases
o (C01) Subscription lifetime (hours)- The assumed lifetime of a
subscription in hours. We assume 8 hours for all calculations.
o (C02) Presence state changes / hour - The average time that a
presentity changes his/hers status in one hour. We assumed 3
times per hour for most calculations. Note that for some users in
consumer messaging systems, the actual number of changes is likely
to be much higher.
o (C03) Subscription refresh interval / hour - The duration of the
SUBSCRIBE session after which it needs to be refreshed. We
assumed that the duration is one hour.
o (C04) Total federated presentities per watcher - The number of
presentities that the watcher is watching. The number here
changes in this document according to the type of the specific
deployment.
o (C05) Number of dialogs to maintain per watcher - The number of
the SUBSCRIBE dialogs that are maintained per watcher. if a dialog
optimization is not assumed this number is equal to A04, otherwise
it is 1.
o (C06) Total number of watchers in the federated presence domains.
The number here is the number of all watchers in all the federated
domains.
o (C07) SUBSCRIBE message size in bytes. We assume 450 bytes in all
calculations. The size is based on a typical SUBSCIRBE taken from
RFCs.
Houri, et al. Expires January 25, 2008 [Page 7]
Internet-Draft Presence Scaling Analysis July 2007
o (C08) 200 OK for SUBSCRIBE message size in bytes. We assume 370
bytes in all calculations. The size is based on a typical 200 OK
taken from RFCs.
o (C09) NOTIFY message size not including the presence document.
The size of this message for a single presentity is assumed to be
500 bytes for the NOTIFY message itself (based on sizes from
examples in RFCs).
o (C10) 200 OK for NOTIFY message size in bytes. We assume 370
bytes in all calculations. The size is based on a typical 200 OK
taken from RFCs.
o (C11) Size of an average presence document. The size is assumed
to be 3000 bytes based on sizes from examples in RFCs. Note that
assuming 3000 bytes for presence document is relatively modest if
we take into account multiple devices and location information.
When there will be multiple presentities in the same NOTIFY as in
the initial NOTIFY for a resource list [10] or there is less
information in the presence document due to partial notifications
these factors will be taken into account.
2.3.2. Initial Messages
The following are the calculations for the messages in the initial
phase of the establishment of the subscriptions. The calculations
contain both number of messages and the number of bytes.
o (I01) Number of initial SUBSCRIBE messages per watcher = C05.
o (I02) Number of initial 200 OK messages for SUBSCRIBE messages per
watcher = C05.
o (I03) Number of initial NOTIFY messages per watcher = C05.
o (I04) Number of initial 200 OK messages for NOTIFY messages per
watcher = C05.
o (I05) Total number and bytes of initial SUBSCRIBE messages for all
watchers = Number - I01*C06, Bytes - I01*C06*C07.
o (I06) Total number and bytes of initial 200 OK for SUBSCRIBE
messages for all watchers = Number - I01*C06, Bytes - I01*C06*C08.
o (I07) Total number and bytes of initial NOTIFY messages for all
watchers = Number - I01*C06, Bytes - (I03*C06*C09)+((C04/
C05)*C11). The calculation of the size is a bit complicates since
it takes into account the case where the optimization of resource
lists is used and there is a single NOTIFY with all the
presentities for the single subscription.
o (I08) Total number and bytes of initial 200 OK for NOTIFY messages
for all watchers = Number - I04*C06, Bytes - I04*C06*C10.
o (I09) Total number and bytes of initial messages per day = Number
- numbers in I05+I06+I07+I08, Size -sizes in I05+I06+I07+I08.
Houri, et al. Expires January 25, 2008 [Page 8]
Internet-Draft Presence Scaling Analysis July 2007
2.3.3. Steady State Messages
Here we describe the calculations for the steady state messages. In
steady state we mean the time between the initial subscription and
the tear down of the subscription. It contains the notifies due to
state change and the subscription refreshes.
o (S01) NOTIFY messages due to state change per watched presentity
per day (less 2 since the NOTIFY for initial and terminating state
is calculated in the initial and terminating calculations) =
(C02*C01-2).
o (S02) 200 (for NOTIFY due to state change) messages per watched
presentity per day (less 2 since the NOTIFY for initial and
terminating state is calculated in the initial and terminating
calculations) = (C02*C01-2).
o (S03) Total number and size of messages due to state change per
day = Number - (S01+S02)*C06*C04, Bytes - ((S01*C06*C04*(C09+C11))
+ (S02*C06* C04*C10)).
o (S04) Number of SUBSCRIBE messages for refreshes per watcher per
day = ((C01/C03)-1)*C05. One is subtracted since the termination
is calculated separately. for example if there are 8 hours in the
day and a refresh should occur every hour, there are 7 refreshes
during the day and not 8.
o (S05) Number of 200 OK messages for SUBSCRIBE messages for
refreshes per watcher per day = ((C01/C03)-1)*C05.
o (S06) Number of NOTIFY messages for refreshes per watcher per day
= ((C01/C03)-1)*C05.
o (S07) Number of 200 OK messages for NOTIFY messages for refreshes
per watcher per day = ((C01/C03)-1)*C05.
o (S08) Total number and size of messages due to SUBSCRIBE refreshes
per day = Number - (S04+S05+S06+S07)*C06, Size - SUBSCIRBE bytes
(S04*C06*C07) + OK for SUBSCRIBE bytes (S05*C06*C08) + NOTIFY
bytes (S06*C06*(C09+((C04/C05)*C11))) + OK for NOTIFY
(S07*C06*C08). The calculation of the size is a bit complicates
since it takes into account the case where the optimization of
resource lists is used and there is a single NOTIFY with all the
presentities for the single subscription. Note that a full state
should be given in SUBSCRIBE refreshes in resource lists. See
section 4.5 in [10]. The fact that the full state needs to be
returned in a NOTIFY response to refresh makes the NOTIFY
optimization more efficient in conjunction with the dialog
optimization.
o (S09) Total number and bytes of steady messages per day = Number -
numbers in S03+S08, Bytes - sizes in S03+S08.
Houri, et al. Expires January 25, 2008 [Page 9]
Internet-Draft Presence Scaling Analysis July 2007
2.3.4. Termination Messages
The following are the calculations for the messages in the
termination phase of the of the subscriptions. The calculations
contain both number of messages and the number of bytes.
o (T01) Number of terminating SUBSCRIBE messages per watcher = C05.
o (T02) Number of terminating 200 OK messages for SUBSCRIBE messages
per watcher = C05.
o (T03) Number of terminating NOTIFY messages per watcher = C05.
o (T04) Number of terminating 200 OK messages for NOTIFY messages
per watcher = C05.
o (T05) Total number and bytes of terminating SUBSCRIBE messages for
all watchers = Number - T01*C06, Bytes - T01*C06*C07.
o (T06) Total number and bytes of terminating 200 OK for SUBSCRIBE
messages for all watchers = Number - T01*C06, Bytes - T01*C06*C08.
o (T07) Total number and bytes of terminating NOTIFY messages for
all watchers = Number - T01*C06, Bytes - (T03*C06*(C09+C11). It
is assumed that there will be a single presence document in the
terminating NOTIFY.
o (T08) Total number and bytes of terminating 200 OK for NOTIFY
messages for all watchers = Number - T04*C06, Bytes - T04*C06*C10.
o (T09) Total number and bytes of terminating messages per day =
Number - numbers in T05+T06+T07+T08, Size -sizes in T05+T06+T07+
T08.
2.3.5. Bottom Line
The following are the calculations of the total number of messages
and bytes per day and per second that will be sent on the link
between the federating domains.
o (B01) Total number of message and bytes during the day = Number -
numbers in I09+S09+T09, Bytes - sizes in I09+S09+T09.
o (B02) Total number of message and bytes per second = Number -
number in B01/(C01*3600) Bytes - size in B01/(C01*3600).
2.3.6. Rush Hour Calculations
The way that the calculations are built it is relatively easy to see
the affect of rush hours at the beginning and the end of the day. for
the beginning of the day we should look at the numbers of "(I09)
Total number and bytes of initial messages per day" and for the end
of the day we should look at the number of "(T09) Total number and
bytes of terminating messages per day". Taking these numbers with
some assumed percentage of the numbers of users that log in at the
same hour should give good indication for the rush hour load.
Houri, et al. Expires January 25, 2008 [Page 10]
Internet-Draft Presence Scaling Analysis July 2007
2.4. SIMPLE with no optimizations
The following table uses some common presence characteristics to
demonstrate the effect these factors have on state and message rate
within a presence domain using base SIMPLE protocols without any
proposed optimizations. In this example, there are two presence
domains with total of 40,000 federating users with an average of 4
contacts in the peer domain
** Constants
(C01) Subscription lifetime (hours)...........................8
(C02) Presence state changes / hour...........................3
(C03) Subscription refresh interval / hour....................1
(C04) Total federated presentities per watcher................4
(C05) Number of dialogs to maintain per watcher...............4
(C06) Total number of watchers in domains................40,000
(C07) SUBSCRIBE message size in bytes.......................450
(C08) 200 OK for SUBSCRIBE message size in bytes............370
(C09) NOTIFY message size not including presence doc........500
(C10) 200 OK for NOTIFY message size in bytes...............370
(C11) Size of an average presence document................3,000
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher......................4
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............4
(I03) Initial NOTIFY msgs per watcher.........................4
(I04) Initial 200 OK msgs (NOTIFY) per watcher................4
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers.....................72,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers.....................59,200,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers....................560,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers.....................59,200,000
(I09) Total number & bytes of initial messages per day
Number of msgs for all watchers...............640,000
Bytes for all watchers....................750,400,000
** Steady State Messages
(S01) NOTIFY msgs due to state change
per watched presentity per day.....................22
(S02) 200 (for NOTIFY due to state change) msgs
per watched presentity per day.....................22
Houri, et al. Expires January 25, 2008 [Page 11]
Internet-Draft Presence Scaling Analysis July 2007
(S03) Total number and size of msgs due to state change per day
Number of msgs for all watchers.............7,040,000
Bytes for all watchers.................13,622,400,000
(S04) Number of SUBSCRIBE msgs for refreshes
per watcher per day................................28
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
per watcher per day................................28
(S06) Number of NOTIFY msgs for refreshes
per watcher per day................................28
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
per watcher per day................................28
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
Number of msgs for all watchers per day.....4,480,000
Bytes for all watchers per day..........5,252,800,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers............11,520,000
Bytes for all watchers.................18,875,200,000
** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher..................4
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........4
(T03) Terminating NOTIFY msgs per watcher.....................4
(T04) Terminating 200 OK msgs (NOTIFY) per watcher............4
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
Number of msgs for all watchers.............. 160,000
Bytes for all watchers.....................72,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers.....................59,200,000
(T07) Total number & bytes of terminating NOTIFY msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers....................560,000,000
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers.....................59,200,000
(T09) Total number & bytes of terminating messages per day
Number of msgs for all watchers...............640,000
Bytes for all watchers....................750,400,000
** Bottom Line
(B01) Total number of message & bytes during the day
Number of msgs.............................12,800,000
Bytes..................................20,376,000,000
(B02) Total number of message & bytes per second
Number of msgs....................................444
Bytes.........................................707,500
Figure 1: SIMPLE with no optimizations
Houri, et al. Expires January 25, 2008 [Page 12]
Internet-Draft Presence Scaling Analysis July 2007
2.5. SIMPLE with dialog optimization
The same analysis provided above is repeated here with the assumption
that the dialog optimization is applied. Note that while the sign-in
(ramp up) and sign-out messages flows are positively affected, the
steady state rates are not.
** Constants
(C01) Subscription lifetime (hours)...........................8
(C02) Presence state changes / hour...........................3
(C03) Subscription refresh interval / hour....................1
(C04) Total federated presentities per watcher................4
(C05) Number of dialogs to maintain per watcher...............1
(C06) Total number of watchers in domains................40,000
(C07) SUBSCRIBE message size in bytes.......................450
(C08) 200 OK for SUBSCRIBE message size in bytes............370
(C09) NOTIFY message size not including presence doc........500
(C10) 200 OK for NOTIFY message size in bytes...............370
(C11) Size of an average presence document................3,000
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher......................1
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1
(I03) Initial NOTIFY msgs per watcher.........................1
(I04) Initial 200 OK msgs (NOTIFY) per watcher................1
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................18,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................14,800,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers................40,000
Bytes for all watchers....................500,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................14,800,000
(I09) Total number & bytes of initial messages per day
Number of msgs for all watchers...............160,000
Bytes for all watchers....................547,600,000
** Steady State Messages
(S01) NOTIFY msgs due to state change
per watched presentity per day.....................22
(S02) 200 (for NOTIFY due to state change) msgs
per watched presentity per day.....................22
(S03) Total number and size of msgs due to state change per day
Number of msgs for all watchers.............7,040,000
Houri, et al. Expires January 25, 2008 [Page 13]
Internet-Draft Presence Scaling Analysis July 2007
Bytes for all watchers.................13,622,400,000
(S04) Number of SUBSCRIBE msgs for refreshes
per watcher per day.................................7
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
per watcher per day.................................7
(S06) Number of NOTIFY msgs for refreshes
per watcher per day.................................7
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
per watcher per day.................................7
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
Number of msgs for all watchers per day.....1,120,000
Bytes for all watchers per day..........3,833,200,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers.............8,160,000
Bytes for all watchers.................17,455,600,000
** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher..................1
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1
(T03) Terminating NOTIFY msgs per watcher.....................1
(T04) Terminating 200 OK msgs (NOTIFY) per watcher............1
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................18,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................14,800,000
(T07) Total number & bytes of terminating NOTIFY msgs
Number of msgs for all watchers................40,000
Bytes for all watchers....................140,000,000
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................14,800,000
(T09) Total number & bytes of terminating messages per day
Number of msgs for all watchers...............160,000
Bytes for all watchers....................187,600,000
** Bottom Line
(B01) Total number of message & bytes during the day
Number of msgs..............................8,480,000
Bytes..................................18,190,800,000
(B02) Total number of message & bytes per second
Number of msgs....................................294
Bytes.........................................631,625
Figure 2: SIMPLE with Dialog optimizations
Houri, et al. Expires January 25, 2008 [Page 14]
Internet-Draft Presence Scaling Analysis July 2007
2.6. SIMPLE with NOTIFY optimization
The initial analysis of analysis provided in Figure 1 is repeated
here with the assumption that the notify optimization is applied.
The optimization saves the need for NOTIFY upon refreshing a
SUBSCRIBE if there was no change since the last NOTIFY. It is
assumed here that there will be no NOTIFY message for a SUBSCRIBE
refreshes. As should be expected this optimization affects the
steady state and does not affect the initial and termination
messages.
** Constants
(C01) Subscription lifetime (hours)...........................8
(C02) Presence state changes / hour...........................3
(C03) Subscription refresh interval / hour....................1
(C04) Total federated presentities per watcher................4
(C05) Number of dialogs to maintain per watcher...............4
(C06) Total number of watchers in domains................40,000
(C07) SUBSCRIBE message size in bytes.......................450
(C08) 200 OK for SUBSCRIBE message size in bytes............370
(C09) NOTIFY message size not including presence doc........500
(C10) 200 OK for NOTIFY message size in bytes...............370
(C11) Size of an average presence document................3,000
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher......................4
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............4
(I03) Initial NOTIFY msgs per watcher.........................4
(I04) Initial 200 OK msgs (NOTIFY) per watcher................4
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers.....................72,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers.....................59,200,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers....................560,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers.....................59,200,000
(I09) Total number & bytes of initial messages per day
Number of msgs for all watchers...............640,000
Bytes for all watchers....................750,400,000
** Steady State Messages
(S01) NOTIFY msgs due to state change
per watched presentity per day.....................22
Houri, et al. Expires January 25, 2008 [Page 15]
Internet-Draft Presence Scaling Analysis July 2007
(S02) 200 (for NOTIFY due to state change) msgs
per watched presentity per day.....................22
(S03) Total number and size of msgs due to state change per day
Number of msgs for all watchers.............7,040,000
Bytes for all watchers.................13,622,400,000
(S04) Number of SUBSCRIBE msgs for refreshes
per watcher per day................................28
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
per watcher per day................................28
(S06) Number of NOTIFY msgs for refreshes
per watcher per day.................................0
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
per watcher per day.................................0
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
Number of msgs for all watchers per day.....2,240,000
Bytes for all watchers per day............918,400,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers.............9,280,000
Bytes for all watchers.................14,540,800,000
** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher..................4
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........4
(T03) Terminating NOTIFY msgs per watcher.....................4
(T04) Terminating 200 OK msgs (NOTIFY) per watcher............4
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
Number of msgs for all watchers.............. 160,000
Bytes for all watchers.....................72,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers.....................59,200,000
(T07) Total number & bytes of terminating NOTIFY msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers....................560,000,000
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers.....................59,200,000
(T09) Total number & bytes of terminating messages per day
Number of msgs for all watchers...............640,000
Bytes for all watchers....................750,400,000
** Bottom Line
(B01) Total number of message & bytes during the day
Number of msgs.............................10,560,000
Bytes..................................16,041,600,000
(B02) Total number of message & bytes per second
Number of msgs....................................367
Bytes.........................................557,000
Houri, et al. Expires January 25, 2008 [Page 16]
Internet-Draft Presence Scaling Analysis July 2007
Figure 3: SIMPLE with NOTIFY optimizations
2.7. SIMPLE with Dialog & NOTIFY optimizations
Here both optimizations are combined. In all the other use cases we
will show only the analysis with no optimizations and with both
optimizations combined.
** Constants
(C01) Subscription lifetime (hours)...........................8
(C02) Presence state changes / hour...........................3
(C03) Subscription refresh interval / hour....................1
(C04) Total federated presentities per watcher................4
(C05) Number of dialogs to maintain per watcher...............1
(C06) Total number of watchers in domains................40,000
(C07) SUBSCRIBE message size in bytes.......................450
(C08) 200 OK for SUBSCRIBE message size in bytes............370
(C09) NOTIFY message size not including presence doc........500
(C10) 200 OK for NOTIFY message size in bytes...............370
(C11) Size of an average presence document................3,000
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher......................1
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1
(I03) Initial NOTIFY msgs per watcher.........................1
(I04) Initial 200 OK msgs (NOTIFY) per watcher................1
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................18,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................14,800,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers................40,000
Bytes for all watchers....................500,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................14,800,000
(I09) Total number & bytes of initial messages per day
Number of msgs for all watchers...............160,000
Bytes for all watchers....................547,600,000
** Steady State Messages
(S01) NOTIFY msgs due to state change
per watched presentity per day.....................22
(S02) 200 (for NOTIFY due to state change) msgs
per watched presentity per day.....................22
(S03) Total number and size of msgs due to state change per day
Houri, et al. Expires January 25, 2008 [Page 17]
Internet-Draft Presence Scaling Analysis July 2007
Number of msgs for all watchers.............7,040,000
Bytes for all watchers.................13,622,400,000
(S04) Number of SUBSCRIBE msgs for refreshes
per watcher per day.................................7
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
per watcher per day.................................7
(S06) Number of NOTIFY msgs for refreshes
per watcher per day.................................0
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
per watcher per day.................................0
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
Number of msgs for all watchers per day.......560,000
Bytes for all watchers per day............229,600,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers.............7,600,000
Bytes for all watchers.................13,852,000,000
** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher..................1
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1
(T03) Terminating NOTIFY msgs per watcher.....................1
(T04) Terminating 200 OK msgs (NOTIFY) per watcher............1
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................18,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................14,800,000
(T07) Total number & bytes of terminating NOTIFY msgs
Number of msgs for all watchers................40,000
Bytes for all watchers....................140,000,000
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................14,800,000
(T09) Total number & bytes of terminating messages per day
Number of msgs for all watchers...............160,000
Bytes for all watchers....................187,600,000
** Bottom Line
(B01) Total number of message & bytes during the day
Number of msgs..............................7,920,000
Bytes..................................14,587,200,000
(B02) Total number of message & bytes per second
Number of msgs....................................275
Bytes.........................................506,500
Figure 4: SIMPLE with Dialog & NOTIFY optimizations
Houri, et al. Expires January 25, 2008 [Page 18]
Internet-Draft Presence Scaling Analysis July 2007
2.8. Presence Federations
While these scalability issues exist in any large deployment, certain
characteristics make the deployment conducive to the existing
resource- list optimizations, and others have characteristics that
cannot be exploited with the existing SIMPLE model. Following is a
list of federation relationships that have varying usage
characteristics. For each, a message rate and bandwidth table is
provided reflecting typical changes message rates. Those
characteristics can alter the overall effectiveness of existing
optimizations.
2.8.1. Widely distributed inter-domain presence
In some environments presence federation may be very common, perhaps
even more common than intra-domain presence. An example of this type
of environment is a small ISV or public server. Users in that small
ISV are not likely to subscribe to the presence of other users in the
their server since they do not necessarily have any relationship with
each other aside from receiving service from the same provider. They
are much more likely to be subscribed to the presence of users in one
of the federated domains (whether in consumer domains, academic,
other ISVs, etc). Common characteristics of this deployment are:
o Federated subscriptions are the majority of subscription traffic
o Individual users are likely to subscribe to multiple users in any
one domain
o The intersection of users in the deployment watching the same
presentities is quite small (i.e., probability that watchers in
the domain subscribe to the same presentity is low)
To account for the extraordinarily high percentage of federation
traffic, the number of federated presentities is increased to 20.
The number of watchers in the domain could also be adjusted to
account for an expected larger community of users being peered with,
it is omitted here for simplification
The first table below provides the calculations without optimizations
the second table provides the calculations with optimization. Note
that the number of messages per second decreases by a quarter with
the optimizations but it is still quite big. It is interesting to
see that the bandwidth is almost the quarter of the bandwidth when
optimizations are applied.
** Constants
(C01) Subscription lifetime (hours)...........................8
(C02) Presence state changes / hour...........................3
(C03) Subscription refresh interval / hour....................1
Houri, et al. Expires January 25, 2008 [Page 19]
Internet-Draft Presence Scaling Analysis July 2007
(C04) Total federated presentities per watcher...............20
(C05) Number of dialogs to maintain per watcher..............20
(C06) Total number of watchers in domains................40,000
(C07) SUBSCRIBE message size in bytes.......................450
(C08) 200 OK for SUBSCRIBE message size in bytes............370
(C09) NOTIFY message size not including presence doc........500
(C10) 200 OK for NOTIFY message size in bytes...............370
(C11) Size of an average presence document................3,000
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher.....................20
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher............20
(I03) Initial NOTIFY msgs per watcher........................20
(I04) Initial 200 OK msgs (NOTIFY) per watcher...............20
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers...............800,000
Bytes for all watchers....................360,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers...............800,000
Bytes for all watchers....................296,000,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers...............800,000
Bytes for all watchers..................2,800,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
Number of msgs for all watchers...............800,000
Bytes for all watchers....................296,000,000
(I09) Total number & bytes of initial messages per day
Number of msgs for all watchers.............3,200,000
Bytes for all watchers..................3,752,000,000
** Steady State Messages
(S01) NOTIFY msgs due to state change
per watched presentity per day.....................22
(S02) 200 (for NOTIFY due to state change) msgs
per watched presentity per day.....................22
(S03) Total number and size of msgs due to state change per day
Number of msgs for all watchers............35,200,000
Bytes for all watchers.................68,112,000,000
(S04) Number of SUBSCRIBE msgs for refreshes
per watcher per day...............................140
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
per watcher per day...............................140
(S06) Number of NOTIFY msgs for refreshes
per watcher per day...............................140
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
per watcher per day...............................140
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
Number of msgs for all watchers per day....22,400,000
Houri, et al. Expires January 25, 2008 [Page 20]
Internet-Draft Presence Scaling Analysis July 2007
Bytes for all watchers per day.........26,264,000,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers............57,600,000
Bytes for all watchers.................94,376,000,000
** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher.................20
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........20
(T03) Terminating NOTIFY msgs per watcher....................20
(T04) Terminating 200 OK msgs (NOTIFY) per watcher...........20
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
Number of msgs for all watchers...............800,000
Bytes for all watchers....................360,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers...............800,000
Bytes for all watchers....................296,000,000
(T07) Total number & bytes of terminating NOTIFY msgs
Number of msgs for all watchers...............800,000
Bytes for all watchers..................2,800,000,000
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
Number of msgs for all watchers...............800,000
Bytes for all watchers....................296,000,000
(T09) Total number & bytes of terminating messages per day
Number of msgs for all watchers.............3,200,000
Bytes for all watchers..................3,752,000,000
** Bottom Line
(B01) Total number of message & bytes during the day
Number of msgs.............................65,000,000
Bytes.................................101,880,000,000
(B02) Total number of message & bytes per second
Number of msgs..................................2,222
Bytes.......................................3,537,500
Figure 5: Widely distributed inter-domain with no optimizations
** Constants
(C01) Subscription lifetime (hours)...........................8
(C02) Presence state changes / hour...........................3
(C03) Subscription refresh interval / hour....................1
(C04) Total federated presentities per watcher...............20
(C05) Number of dialogs to maintain per watcher...............1
(C06) Total number of watchers in domains................40,000
(C07) SUBSCRIBE message size in bytes.......................450
(C08) 200 OK for SUBSCRIBE message size in bytes............370
(C09) NOTIFY message size not including presence doc........500
(C10) 200 OK for NOTIFY message size in bytes...............370
Houri, et al. Expires January 25, 2008 [Page 21]
Internet-Draft Presence Scaling Analysis July 2007
(C11) Size of an average presence document................3,000
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher......................1
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1
(I03) Initial NOTIFY msgs per watcher.........................1
(I04) Initial 200 OK msgs (NOTIFY) per watcher................1
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................18,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................14,800,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers................40,000
Bytes for all watchers..................2,420,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................14,800,000
(I09) Total number & bytes of initial messages per day
Number of msgs for all watchers...............160,000
Bytes for all watchers..................2,467,600,000
** Steady State Messages
(S01) NOTIFY msgs due to state change
per watched presentity per day.....................22
(S02) 200 (for NOTIFY due to state change) msgs
per watched presentity per day.....................22
(S03) Total number and size of msgs due to state change per day
Number of msgs for all watchers............35,200,000
Bytes for all watchers.................68,112,000,000
(S04) Number of SUBSCRIBE msgs for refreshes
per watcher per day.................................7
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
per watcher per day.................................7
(S06) Number of NOTIFY msgs for refreshes
per watcher per day.................................0
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
per watcher per day.................................0
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
Number of msgs for all watchers per day.......560,000
Bytes for all watchers per day............229,600,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers............35,760,000
Bytes for all watchers.................68,341,600,000
** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher..................1
Houri, et al. Expires January 25, 2008 [Page 22]
Internet-Draft Presence Scaling Analysis July 2007
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1
(T03) Terminating NOTIFY msgs per watcher.....................1
(T04) Terminating 200 OK msgs (NOTIFY) per watcher............1
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................18,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................14,800,000
(T07) Total number & bytes of terminating NOTIFY msgs
Number of msgs for all watchers................40,000
Bytes for all watchers....................140,000,000
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................14,800,000
(T09) Total number & bytes of terminating messages per day
Number of msgs for all watchers...............160,000
Bytes for all watchers....................187,600,000
** Bottom Line
(B01) Total number of message & bytes during the day
Number of msgs.............................36,080,000
Bytes..................................70,996,800,000
(B02) Total number of message & bytes per second
Number of msgs..................................1,253
Bytes.......................................2,465,167
Figure 6: Widely distributed inter-domain with optimizations
2.8.2. Associated inter-domain presence
In this type of environment, the domain is a collection of associated
users such as an enterprise. Here, federation is once again very
common. However, there is also a strong association between some
users in the deployment. These associations make it somewhat more
likely that users in that domain will be watchers of the same
presentity. This can occur because of business relationships (e.g.
two co-workers on a project federating with a partner company).
Common characteristics of this deployment are:
o Federated subscriptions are large minority or small majority of
subscription traffic
o Individual users are likely to subscribe to multiple users in any
one domain, especially their own
o The intersection of users in the deployment watching the same
presentities increases
Houri, et al. Expires January 25, 2008 [Page 23]
Internet-Draft Presence Scaling Analysis July 2007
This federation type has traffic rates similar to the previous
examples but with different levels of association of the users.
2.8.3. Very large network peering
In this environment, two or more very large networks create a peering
relationship allowing their users to subscribe to presence in the
other domains. Where as the number of users in other deployment
types ranges from hundreds to several hundred thousand, these large
networks host up to hundreds of millions of users. Examples of these
networks are large wireless carriers and consumer IM networks.
Common characteristics of this deployment are:
o As users become accustomed to network boundaries disappearing,
federated subscriptions become as common as subscriptions within
the same domain
o Individual users are highly likely to want to see presence of
multiple presentities in the peer network
o The intersection of users in the deployment watching the same
presentities is very high (i.e., two or more users in network A
are extremely likely to be watching a same user in network B)
o Status changes increase greatly due to typical observed consumer
behavior
The first table below provides the calculations without optimizations
the second table provides the calculations with optimizations. Even
though the optimizations help a lot (almost cut the number of
messages by half), the numbers are still very high. Note also that
the bandwidth required is very high (almost 1GB per second).
** Constants
(C01) Subscription lifetime (hours)...........................8
(C02) Presence state changes / hour...........................6
(C03) Subscription refresh interval / hour....................1
(C04) Total federated presentities per watcher...............10
(C05) Number of dialogs to maintain per watcher..............10
(C06) Total number of watchers in domains............20,000,000
(C07) SUBSCRIBE message size in bytes.......................450
(C08) 200 OK for SUBSCRIBE message size in bytes............370
(C09) NOTIFY message size not including presence doc........500
(C10) 200 OK for NOTIFY message size in bytes...............370
(C11) Size of an average presence document................3,000
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher.....................10
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher............10
(I03) Initial NOTIFY msgs per watcher........................10
Houri, et al. Expires January 25, 2008 [Page 24]
Internet-Draft Presence Scaling Analysis July 2007
(I04) Initial 200 OK msgs (NOTIFY) per watcher...............10
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers.................90,000,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers.................74,000,000,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers................700,000,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers.................74,000,000,000
(I09) Total number & bytes of initial messages per day
Number of msgs for all watchers...........800,000,000
Bytes for all watchers................938,000,000,000
** Steady State Messages
(S01) NOTIFY msgs due to state change
per watched presentity per day.....................46
(S02) 200 (for NOTIFY due to state change) msgs
per watched presentity per day.....................46
(S03) Total number and size of msgs due to state change per day
Number of msgs for all watchers........18,400,000,000
Bytes for all watchers.............35,604,000,000,000
(S04) Number of SUBSCRIBE msgs for refreshes
per watcher per day................................70
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
per watcher per day................................70
(S06) Number of NOTIFY msgs for refreshes
per watcher per day................................70
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
per watcher per day................................70
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
Number of msgs for all watchers per day.5,600,000,000
Bytes for all watchers per day......6,566,000,000,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers........24,000,000,000
Bytes for all watchers.............42,170,000,000,000
** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher.................10
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........10
(T03) Terminating NOTIFY msgs per watcher....................10
(T04) Terminating 200 OK msgs (NOTIFY) per watcher...........10
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers.................90,000,000,000
Houri, et al. Expires January 25, 2008 [Page 25]
Internet-Draft Presence Scaling Analysis July 2007
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers.................74,000,000,000
(T07) Total number & bytes of terminating NOTIFY msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers................700,000,000,000
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers.................74,000,000,000
(T09) Total number & bytes of terminating messages per day
Number of msgs for all watchers...........800,000,000
Bytes for all watchers................938,002,000,000
** Bottom Line
(B01) Total number of message & bytes during the day
Number of msgs.........................25,600,000,000
Bytes..............................44,046,000,000,000
(B02) Total number of message & bytes per second
Number of msgs................................888,889
Bytes...................................1,529,375,333
Figure 7: Very large network peering with no optimizations
** Constants
(C01) Subscription lifetime (hours)...........................8
(C02) Presence state changes / hour...........................6
(C03) Subscription refresh interval / hour....................1
(C04) Total federated presentities per watcher...............10
(C05) Number of dialogs to maintain per watcher...............1
(C06) Total number of watchers in domains............20,000,000
(C07) SUBSCRIBE message size in bytes.......................450
(C08) 200 OK for SUBSCRIBE message size in bytes............370
(C09) NOTIFY message size not including presence doc........500
(C10) 200 OK for NOTIFY message size in bytes...............370
(C11) Size of an average presence document................3,000
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher......................1
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1
(I03) Initial NOTIFY msgs per watcher.........................1
(I04) Initial 200 OK msgs (NOTIFY) per watcher................1
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers..................9,000,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers..................7,400,000,000
Houri, et al. Expires January 25, 2008 [Page 26]
Internet-Draft Presence Scaling Analysis July 2007
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers................610,000,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers..................7,400,000,000
(I09) Total number & bytes of initial messages per day
Number of msgs for all watchers............80,000,000
Bytes for all watchers................663,800,000,000
** Steady State Messages
(S01) NOTIFY msgs due to state change
per watched presentity per day.....................46
(S02) 200 (for NOTIFY due to state change) msgs
per watched presentity per day.....................46
(S03) Total number and size of msgs due to state change per day
Number of msgs for all watchers........18,400,000,000
Bytes for all watchers.............35,604,000,000,000
(S04) Number of SUBSCRIBE msgs for refreshes
per watcher per day.................................7
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
per watcher per day.................................7
(S06) Number of NOTIFY msgs for refreshes
per watcher per day.................................0
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
per watcher per day.................................0
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
Number of msgs for all watchers per day...280,000,000
Bytes for all watchers per day........114,800,000,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers........18,680,000,000
Bytes for all watchers.............35,718,800,000,000
** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher..................1
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1
(T03) Terminating NOTIFY msgs per watcher.....................1
(T04) Terminating 200 OK msgs (NOTIFY) per watcher............1
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers..................9,000,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers..................7,400,000,000
(T07) Total number & bytes of terminating NOTIFY msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers.................70,000,000,000
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
Houri, et al. Expires January 25, 2008 [Page 27]
Internet-Draft Presence Scaling Analysis July 2007
Number of msgs for all watchers............20,000,000
Bytes for all watchers..................7,400,000,000
(T09) Total number & bytes of terminating messages per day
Number of msgs for all watchers............80,000,000
Bytes for all watchers.................93,800,000,000
** Bottom Line
(B01) Total number of message & bytes during the day
Number of msgs.........................18,840,000,000
Bytes..............................36,446,400,000,000
(B02) Total number of message & bytes per second
Number of msgs................................654,167
Bytes...................................1,265,500,000
Figure 8: Very large network peering with optimizations
2.8.4. Intra-domain peering
Within a particular domain, multiple presence infrastructures are
deployed with users split between the two. This scenario is unique
in that federated messages do not pass outside the administrative
domain's network. The two infrastructures peer directly inside the
domain. A common example of this is an enterprise IT system with
multiple independent vendor presence solutions deployed(e.g., a
presence solution for desktop messaging deployed alongside a presence
solution for IP telephony).
Common characteristics of this deployment are
o The difference between subscriptions to presentities in one system
vs. the other are completely arbitrary. Any one presentity is as
likely to be homed on one infrastructure as the other
o Active users are almost guaranteed of subscribing to many users in
the peer infrastructure
o The level of intersection of presentities is extremely high
The first table below provides the calculations without optimizations
the second table provides the calculations with optimization. Even
though the relatively conservative numbers are used, the amount of
messages is still very high even though optimization may cut the
traffic by more then half
** Constants
(C01) Subscription lifetime (hours)...........................8
(C02) Presence state changes / hour...........................3
(C03) Subscription refresh interval / hour....................1
(C04) Total federated presentities per watcher...............10
(C05) Number of dialogs to maintain per watcher..............10
Houri, et al. Expires January 25, 2008 [Page 28]
Internet-Draft Presence Scaling Analysis July 2007
(C06) Total number of watchers in domains...............120,000
(C07) SUBSCRIBE message size in bytes.......................450
(C08) 200 OK for SUBSCRIBE message size in bytes............370
(C09) NOTIFY message size not including presence doc........500
(C10) 200 OK for NOTIFY message size in bytes...............370
(C11) Size of an average presence document................3,000
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher.....................10
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher............10
(I03) Initial NOTIFY msgs per watcher........................10
(I04) Initial 200 OK msgs (NOTIFY) per watcher...............10
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers.............1,200,000
Bytes for all watchers....................540,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers.............1,200,000
Bytes for all watchers....................444,000,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers.............1,200,000
Bytes for all watchers..................4,200,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
Number of msgs for all watchers.............1,200,000
Bytes for all watchers....................444,000,000
(I09) Total number & bytes of initial messages per day
Number of msgs for all watchers.............4,800,000
Bytes for all watchers..................5,628,000,000
** Steady State Messages
(S01) NOTIFY msgs due to state change
per watched presentity per day.....................22
(S02) 200 (for NOTIFY due to state change) msgs
per watched presentity per day.....................22
(S03) Total number and size of msgs due to state change per day
Number of msgs for all watchers............52,800,000
Bytes for all watchers................102,168,000,000
(S04) Number of SUBSCRIBE msgs for refreshes
per watcher per day................................70
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
per watcher per day................................70
(S06) Number of NOTIFY msgs for refreshes
per watcher per day................................70
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
per watcher per day................................70
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
Number of msgs for all watchers per day....33,600,000
Bytes for all watchers per day.........39,396,000,000
(S09) Total number & bytes of steady messages per day
Houri, et al. Expires January 25, 2008 [Page 29]
Internet-Draft Presence Scaling Analysis July 2007
Number of msgs for all watchers............86,400,000
Bytes for all watchers................141,564,000,000
** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher.................10
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........10
(T03) Terminating NOTIFY msgs per watcher....................10
(T04) Terminating 200 OK msgs (NOTIFY) per watcher...........10
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
Number of msgs for all watchers.............1,200,000
Bytes for all watchers....................540,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers.............1,200,000
Bytes for all watchers....................444,000,000
(T07) Total number & bytes of terminating NOTIFY msgs
Number of msgs for all watchers.............1,200,000
Bytes for all watchers..................4,200,000,000
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
Number of msgs for all watchers.............1,200,000
Bytes for all watchers....................444,000,000
(T09) Total number & bytes of terminating messages per day
Number of msgs for all watchers.............4,800,000
Bytes for all watchers..................5,628,000,000
** Bottom Line
(B01) Total number of message & bytes during the day
Number of msgs.............................96,000,000
Bytes.................................152,820,000,000
(B02) Total number of message & bytes per second
Number of msgs..................................3,333
Bytes.......................................5,306,250
Figure 9: Inter-domain peering with no optimizations
** Constants
(C01) Subscription lifetime (hours)...........................8
(C02) Presence state changes / hour...........................3
(C03) Subscription refresh interval / hour....................1
(C04) Total federated presentities per watcher...............10
(C05) Number of dialogs to maintain per watcher...............1
(C06) Total number of watchers in domains...............120,000
(C07) SUBSCRIBE message size in bytes.......................450
(C08) 200 OK for SUBSCRIBE message size in bytes............370
(C09) NOTIFY message size not including presence doc........500
(C10) 200 OK for NOTIFY message size in bytes...............370
(C11) Size of an average presence document................3,000
Houri, et al. Expires January 25, 2008 [Page 30]
Internet-Draft Presence Scaling Analysis July 2007
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher......................1
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1
(I03) Initial NOTIFY msgs per watcher.........................1
(I04) Initial 200 OK msgs (NOTIFY) per watcher................1
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers...............120,000
Bytes for all watchers.....................54,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers...............120,000
Bytes for all watchers.....................44,400,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers...............120,000
Bytes for all watchers..................3,660,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
Number of msgs for all watchers...............120,000
Bytes for all watchers.....................44,400,000
(I09) Total number & bytes of initial messages per day
Number of msgs for all watchers...............480,000
Bytes for all watchers..................3,802,800,000
** Steady State Messages
(S01) NOTIFY msgs due to state change
per watched presentity per day.....................22
(S02) 200 (for NOTIFY due to state change) msgs
per watched presentity per day.....................22
(S03) Total number and size of msgs due to state change per day
Number of msgs for all watchers............52,800,000
Bytes for all watchers................102,168,000,000
(S04) Number of SUBSCRIBE msgs for refreshes
per watcher per day.................................7
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
per watcher per day.................................7
(S06) Number of NOTIFY msgs for refreshes
per watcher per day.................................0
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
per watcher per day.................................0
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
Number of msgs for all watchers per day.....1,680,000
Bytes for all watchers per day............668,800,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers............54,480,000
Bytes for all watchers................102,856,800,000
** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher..................1
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1
(T03) Terminating NOTIFY msgs per watcher.....................1
Houri, et al. Expires January 25, 2008 [Page 31]
Internet-Draft Presence Scaling Analysis July 2007
(T04) Terminating 200 OK msgs (NOTIFY) per watcher............1
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
Number of msgs for all watchers...............120,000
Bytes for all watchers.....................54,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers...............120,000
Bytes for all watchers.....................44,400,000
(T07) Total number & bytes of terminating NOTIFY msgs
Number of msgs for all watchers...............120,000
Bytes for all watchers....................420,000,000
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
Number of msgs for all watchers...............120,000
Bytes for all watchers.....................44,400,000
(T09) Total number & bytes of terminating messages per day
Number of msgs for all watchers...............480,000
Bytes for all watchers....................562.800,000
** Bottom Line
(B01) Total number of message & bytes during the day
Number of msgs.............................55,440,000
Bytes.................................107,222,400,000
(B02) Total number of message & bytes per second
Number of msgs..................................1,925
Bytes.......................................3,723,417
Figure 10: Inter-domain peering with optimizations
2.9. Partial Notifications Optimization
Draft [11] define a way for the watcher to request getting only what
was changed in the presence document. The following is a calculation
of the bandwidth that is saved in the very large peering network
case, when we add the partial notification optimization to the dialog
and NOTIFY optimization. It is assumed that except for the initial
NOTIFY all the other NOTIFY messages will be partial and the size of
the partial presence document is 200 bytes
** Constants
(C01) Subscription lifetime (hours)...........................8
(C02) Presence state changes / hour...........................6
(C03) Subscription refresh interval / hour....................1
(C04) Total federated presentities per watcher...............10
(C05) Number of dialogs to maintain per watcher...............1
(C06) Total number of watchers in domains............20,000,000
(C07) SUBSCRIBE message size in bytes.......................450
(C08) 200 OK for SUBSCRIBE message size in bytes............370
(C09) NOTIFY message size not including presence doc........500
(C10) 200 OK for NOTIFY message size in bytes...............370
Houri, et al. Expires January 25, 2008 [Page 32]
Internet-Draft Presence Scaling Analysis July 2007
(C11) Size of an average presence document................3,000
(C12) Size of an average partial presence document..........200
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher......................1
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1
(I03) Initial NOTIFY msgs per watcher.........................1
(I04) Initial 200 OK msgs (NOTIFY) per watcher................1
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers..................9,000,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers..................7,400,000,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers................610,000,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers..................7,400,000,000
(I09) Total number & bytes of initial messages per day
Number of msgs for all watchers............80,000,000
Bytes for all watchers................663,800,000,000
** Steady State Messages
(S01) NOTIFY msgs due to state change
per watched presentity per day.....................46
(S02) 200 (for NOTIFY due to state change) msgs
per watched presentity per day.....................46
(S03) Total number and size of msgs due to state change per day
Number of msgs for all watchers........18,400,000,000
Bytes for all watchers..............9,844,000,000,000
(S04) Number of SUBSCRIBE msgs for refreshes
per watcher per day.................................7
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
per watcher per day.................................7
(S06) Number of NOTIFY msgs for refreshes
per watcher per day.................................0
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
per watcher per day.................................0
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
Number of msgs for all watchers per day...280,000,000
Bytes for all watchers per day........114,800,000,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers........18,680,000,000
Bytes for all watchers..............9,958,800,000,000
** Termination Messages
Houri, et al. Expires January 25, 2008 [Page 33]
Internet-Draft Presence Scaling Analysis July 2007
(T01) Terminating SUBSCRIBE msgs per watcher..................1
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1
(T03) Terminating NOTIFY msgs per watcher.....................1
(T04) Terminating 200 OK msgs (NOTIFY) per watcher............1
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers..................9,000,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers..................7,400,000,000
(T07) Total number & bytes of terminating NOTIFY msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers.................70,000,000,000
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers..................7,400,000,000
(T09) Total number & bytes of terminating messages per day
Number of msgs for all watchers............80,000,000
Bytes for all watchers.................93,800,000,000
** Bottom Line
(B01) Total number of message & bytes during the day
Number of msgs.........................18,840,000,000
Bytes..............................10,630,400,000,000
(B02) Total number of message & bytes per second
Number of msgs................................654,167
Bytes.....................................369,111,111
Figure 11: Very large networks peering with dialog, NOTIFY and
partial optimizations
Compared to the numbers we got for optimized very large peering
networks (36,446,400,000,000 bytes per day, it seems that the partial
notify can save a lot in the bandwidth.
2.10. Other Protocols
In SIP there are several differences from other protocols of presence
as XMPP [6] and the proprietary protocols of the consumer domains.
The differences are:
o There is no 200 OK for each message. These protocols support only
TCP and they do not compensate for network issues.
o There is no refresh for subscription.
o There is no NOTIFY upon termination of SUBSCRIPTION
o The size of each message of these protocol is smaller since they
are either binary and/or there is no need for the various headers
that SIP uses for routing etc. So we need to assume smaller
Houri, et al. Expires January 25, 2008 [Page 34]
Internet-Draft Presence Scaling Analysis July 2007
message sizes while we will keep the size of the presence document
the same.
The following is an analysis of the very large networks peering
assuming all the changes in other protocols with respect to SIP.
** Constants
(C01) Subscription lifetime (hours)...........................8
(C02) Presence state changes / hour...........................6
(C03) Subscription refresh interval / hour....................0
(C04) Total federated presentities per watcher...............10
(C05) Number of dialogs to maintain per watcher..............10
(C06) Total number of watchers in domains............20,000,000
(C07) SUBSCRIBE message size in bytes.......................150
(C08) 200 OK for SUBSCRIBE message size in bytes..............0
(C09) NOTIFY message size not including presence doc........150
(C10) 200 OK for NOTIFY message size in bytes.................0
(C11) Size of an average presence document................3,000
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher.....................10
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............0
(I03) Initial NOTIFY msgs per watcher........................10
(I04) Initial 200 OK msgs (NOTIFY) per watcher................0
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers.................30,000,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers.....................0
Bytes for all watchers..............................0
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers....................630,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
Number of msgs for all watchers.....................0
Bytes for all watchers..............................0
(I09) Total number & bytes of initial messages per day
Number of msgs for all watchers...........400,000,000
Bytes for all watchers.................660,00,000,000
** Steady State Messages
(S01) NOTIFY msgs due to state change
per watched presentity per day.....................46
(S02) 200 (for NOTIFY due to state change) msgs
per watched presentity per day......................0
(S03) Total number and size of msgs due to state change per day
Number of msgs for all watchers.........9,200,000,000
Bytes for all watchers.............28,980,000,000,000
Houri, et al. Expires January 25, 2008 [Page 35]
Internet-Draft Presence Scaling Analysis July 2007
(S04) Number of SUBSCRIBE msgs for refreshes
per watcher per day.................................0
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
per watcher per day.................................0
(S06) Number of NOTIFY msgs for refreshes
per watcher per day.................................0
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
per watcher per day.................................0
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
Number of msgs for all watchers per day.............0
Bytes for all watchers per day......................0
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers.........9,200,480,000
Bytes for all watchers.............28,980,000,000,000
** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher.................10
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........0
(T03) Terminating NOTIFY msgs per watcher.....................0
(T04) Terminating 200 OK msgs (NOTIFY) per watcher............0
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers.................30,000,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers.....................0
Bytes for all watchers..............................0
(T07) Total number & bytes of terminating NOTIFY msgs
Number of msgs for all watchers.....................0
Bytes for all watchers..............................0
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
Number of msgs for all watchers.....................0
Bytes for all watchers..............................0
(T09) Total number & bytes of terminating messages per day
Number of msgs for all watchers...........200,000,000
Bytes for all watchers.................30,000,000,000
** Bottom Line
(B01) Total number of message & bytes during the day
Number of msgs..........................9,800,000,000
Bytes..............................29,670,000,000,000
(B02) Total number of message & bytes per second
Number of msgs................................340,278
Bytes...................................1,030,208,333
Figure 12: Very large networks peering in other protocols
Compared to the numbers we got for optimized very large peering
networks (18,840,000,000 messages per day and 10,630,400,000,000
Houri, et al. Expires January 25, 2008 [Page 36]
Internet-Draft Presence Scaling Analysis July 2007
bytes per day, the numbers of message with other protocols are only
about half and with due to the partial notification optimization we
get even less bytes per day. It seems that this shows that the
scalability issue of presence is less due to some protocol choice but
more an inherent issue with presence.
3. State Management
In previous sections we have discussed the big amount of messages
that need to be sent to/from a presence server In this section the
state that needs to be maintained by a presence server will be
analysed and shown to be far from trivial.
The presence server has two parallel tasks.
1. Maintain the state of the presentities to which watchers
subscribe.
2. Maintain the state of the subscriptions of watchers and provide
timely updates to the watchers.
For a single subscription from a single watcher on a presentity, the
presence server has to maintain the following state:
o Subscription state including all the parameters that are needed in
order to maintain the subscription as timers.
o Optional filtering information that was requested by the watcher.
This includes enough information that is needed for doing the
filtering. In addition additional information has to be
maintained if partial notification is being supported for the
subscription
o Optional rate management information as throttling
o Watcher information [4], [5] that is the result of the
subscription in order to enable watched presentities to see who is
watching them.
For each presentity that has been subscribed to in the presence
server, the presence server has to maintain the following state:
o A list of the subscriptions for the presentity. Note that this is
already taken care of from the size calculation point of view by
the subscription state above.
o Authorization information for the presentity.
For each presentity for which there was any publication and the
presentity has a state other then a default value, the presence
server has to maintain the current value of the presentity.
Houri, et al. Expires January 25, 2008 [Page 37]
Internet-Draft Presence Scaling Analysis July 2007
3.1. State Size Calculations
Lets assume the following sizes:
o Subscription size - 2K bytes. This includes watcher information
that need to be created by the presence server for each
subscription.
o Subscribed to resource - 1K bytes (for privacy information and
other management info). The subscriptions themselves are already
calculated in the previous bullet.
o Resource with a state - 6K bytes. This is a moderate assumption
if we take into account the amount of data that is being put in a
presence document as multiple devices, calendar and geographical
information.
3.1.1. Tiny System
o 10K subscriptions = 19M bytes.
o 5K subscribed to presentities = 5M bytes.
o 10K presentities with state = 58M bytes.
Total is 82M bytes.
3.1.2. Medium System
o 100K subscriptions = 195M bytes.
o 50K subscribed to presentities = 49M bytes.
o 100K presentities with state = 586M bytes.
Total is 830M bytes.
3.1.3. Large System
o 6M subscriptions = 11,718M bytes.
o 3M subscribed to presentities = 2,929M bytes.
o 4M presentities with state = 23437M bytes.
Total is 38G bytes.
3.1.4. Very Large System
o 150M subscriptions = 292,969M bytes.
o 75M subscribed to presentities = 73,242M bytes.
o 100M presentities with state = 585,937M bytes.
Total is 952G bytes which is a very big number for a very dynamic
storage as needed by the presence server.
Houri, et al. Expires January 25, 2008 [Page 38]
Internet-Draft Presence Scaling Analysis July 2007
Although the numbers above may seem moderate enough for the sizes
that the presence server is handling we should consider the
following:
o Dynamic state - Although the state may seem not so big for
databases even for the very large system, we need to remember that
this state is a very dynamic state. Subscriptions come and go all
the time, the status of presentities is being updated and so
forth. This means that the presence server has to manage its
state in a medium that is very dynamic and for such large sizes
this task is not trivial.
o Interlinked state - The subscriptions and the subscribed to
presentities are dependent on each other. There needs to be a
link from the presentity to the subscriptions and vice versa. See
Section 4.5 about the interlinkage that is created due to resource
lists.
o Moderate assumptions - The size assumptions that were made above
are quite moderate. As presence is becoming more a core
middleware functionality that holds a lot of data on the user. In
real-life the numbers above may be even higher and the presence
server can have additional overhead as managing the SIP sessions,
networking and more.
Although the calculations above do not show that there is a real
issue with state management of presence in medium systems or even in
big systems since it should be possible to divide the state between
different machines, the state size is still very big. A bigger issue
with the state is more when resource lists are involved and create an
interlinked state between many servers. In that case the division of
very big state to multiple servers becomes less trivial...
4. Processing complexities
The basic presence paradigm consists from a watcher and a presentity
to which the watcher watches. It sounds simple enough but there are
many additions and extensions that the presence server has to manage
that make the processing of the presence server very complex.
In this section we show that in addition to the large amount of
messages and the big state that the presence server has to handle, it
has also to handle quite intensive processing for aggregation,
partial notify and publish, filtering and privacy. This adds another
complexity to the presence server in the CPU front in addition to the
network and memory fronts that were described before.
Houri, et al. Expires January 25, 2008 [Page 39]
Internet-Draft Presence Scaling Analysis July 2007
4.1. Aggregation
A presence document may contain multiple resources. These resources
can be devices of the presentity, information that is received form
external providers of presence information for the presentity as
geographical and calendar information and more.
The presence server needs to be able to get the updates from all the
resources and aggregate them correctly into a single presence
document. Although this is just "XML processing" task, the amount of
updates that the presence server may get, the need to keep the
presence document aligned with its schema and the need to notify the
users as soon as possible create a significant processing burden on
the presence server
4.2. Partial Publish and Notify
Drafts [11], [12] define a way for the watcher to request getting
only what was changed in the presence document and for the publisher
of presence information to publish only what was changed in the
presence document since the last publish. Although these
optimizations help in reducing the amount of the data that is sent
from/to the presence server, these optimizations create additional
processing burden on the presence server.
When a partial publish is arriving to the presence server, the
presence server has to be able to process the partial publish, change
only what is indicated in the partial publish while keeping the
presence document in a well formed shape according to the schema.
In partial notify the processing is even more complex since each
watcher needs to get the partial update based on the last update that
was received by that watcher. Therefore [11] specifies a versioning
mechanism that enables the watcher to get the updates based on the
previous state that it has seen. This versioning mechanism has to be
maintained by the presence server for each watcher that is subscribed
to a presentity and requires partial notify.
4.3. Filtering
Filtering as defined in RFCs [8], [9] enables a watcher to request to
be notified only when the presence document fulfills certain
conditions. Although this is a very convenient feature for watchers,
the burden that is put on the presence server is quite big. For each
change in the presence document, the presence server needs to compute
the filtering expressions which can be very complex, decide whether
and what to send to the watcher that have requested filtering.
Houri, et al. Expires January 25, 2008 [Page 40]
Internet-Draft Presence Scaling Analysis July 2007
4.4. Authorization
Draft [13] defines presence authorization rules that can be used by
presentities to define who can see what from their presence
documents. The processing that the presence server has to do here is
very similar to filtering. When there is a change to any presence
document that has privacy defined for it, the presence server needs
to create different notification for different watchers according to
what is defined in the authorization rules.
4.5. Resource List Service
RFC [10] defines a way to subscribe on a single URI while that URI is
actually a list of resources that are being subscribed to by a single
subscription. Although this is quite useful mechanism and it
significantly saves on the number of sessions between the watcher and
the presence server (as we show in the calculations of messages),
this feature has the potential to make the scalability issue of
presence systems harder and more complex.
The reasons that resource lists may make the scalability problem of
the presence server even more complex are:
o Subscriptions and state - The resource list may contain reference
to many other presence servers in many other domains. This
requires the RLS to create subscriptions to other presence servers
and buffer the state of all presentities in order to be able to
provide the full state of the presentities in the list when
needed. So in the overall system, the subscriptions that were
saved between the watcher and the presence server are moved to the
backend system while state has been duplicated between the various
presence servers that serve the various presentities and the RLSs.
This issue could have been mitigated if there was a way for the
RLS to retrieve the presence information for many watchers while
adhering to privacy when sending the actual notifications to the
watchers.
o Interlinkage - The resource list subscription will reach one RLS
that will open it and send it to many presence servers and to
other RLSs (if there is a subgroup inside the list). This way a
complex linkage between the state of many components is created.
This linkage makes state management and other maintenance of a
presence systems quite complex.
o Big lists are easy - There are two types of groups that may be
used with this feature, private groups that are defined by/for
each watcher and public groups that are defined in the system and
can be used by any watcher. Although we should expect IT
administrators to take caution when creating public groups, this
may be not the case in real life. The connection between the size
Houri, et al. Expires January 25, 2008 [Page 41]
Internet-Draft Presence Scaling Analysis July 2007
of the public group and the load on the presence server system may
not apparent to everyone. Furthermore many public groups that are
used in presence systems may have been created for other purposes
as email systems (where the size of the lists was not so
important) and are taken as they are to presence systems. So for
example we may very easily find that a public group that actually
covers all the users in the enterprise are used by many users in
the enterprise thus creating unbearable load on the presence
server. Note that this issue is not a protocol or design issue
but more a usage issue that may have a real impact on the presence
system.
o Stopping notifications - A watcher may accidentally subscribe to a
very big list and be overwhelmed by the amount of notifies that it
receives from the presence server. There is no current way to
stop this stream of notifies and even canceling the subscription
may take time until being affective.
The issues mentioned above are one example of an optimization that
helps in one part of the system but creates even bigger problems in
the overall system. There is a need to think about the problems
listed above but more then that there is a need to make sure that
when an optimization is introduced it does not create issues in other
places.
5. Current Optimizations
This section lists and discusses several optimizations that are
either already part of the SIP protocol or they have been suggested
in various drafts. Several other optimizations that have been
suggested but have not been discussed in the working group yet are
summarized in [18].
o Subnot-etags - Draft [16]. This draft suggests ways to suppress
the sending of unnecessary notifies when for example a
subscription is refreshed. This suggestion seems to be an
efficient optimization since it saves both the number of messages
sent and on the processing time of the presence server.
o Resource List Service - [10] enable creating a single subscription
session between the watcher and the presence server for
subscribing on a list of users. This saves the amount of sessions
that are created between watchers and presence servers. On the
other hand, this mechanism enables creating very large amount of
subscriptions in the presence server/RLS system thus enabling the
creation of a very large number of subscriptions between presence
servers and RLSs with relatively few clients especially if large
public groups are used. It seems that in order to really optimize
in this area, the usage of large public groups should not be
Houri, et al. Expires January 25, 2008 [Page 42]
Internet-Draft Presence Scaling Analysis July 2007
considered as BCP and there should be a way for an RLS to create a
single subscription for multiple occurrences of the same resource
in resource lists. See consolidates subscriptions below.
o Partial notify/publish - Drafts [11], [12] define a way for the
subscriber to request getting only what was changed in the
presence document and for the publisher of presence information to
publish only what was changed in the presence document since the
last publish. Although these optimizations help in reducing the
amount of actual data that is sent from/to the presence server,
these optimizations create additional processing burden on the
presence server as was discussed above.
o Filtering as defined in RFCs [8], [9] enables a watcher to request
to be notified only when the presence document fulfills certain
conditions. Although this optimization enables saving on the
amount of messages that are sent from the presence server to the
watcher, this optimization puts more burden on the processing time
of the presence server as was discussed above.
o Throttling [19] defines a mechanism in which a watcher requires to
be updated only in certain intervals. Although this mechanism may
give some extra load on the processing time of the presence
server, that load is negligible and the reduction on the amount of
messages sent from the presence server to the watchers is
significant. This optimization is even more important with
resource lists where there can be many resources in the resource
lists and if the traffic of updates on resource list is not
regulated, the watcher may get very large amount of notifications.
o Presence specific sigcomp dictionary [14] defines a SIGCOMP [3]
dictionary for presence. This optimization will enable to reduce
the number of bytes that are transferred in presence systems by
compressing the textual SIP messages and using the specialized
presence dictionary the compression may be more significant then
just using SIGCOMP as is. Note that number of actual messages
will remain the same and a calculation of the amount of bytes that
will be saved may be useful here.
o Content Indirection [7] enables sending only the URI of the
presence document to the watcher thus offloading the presence
server from sending the presence document to the watcher. This
optimization may be useful in some cases especially where there is
a big number of users that get the same presence document.
6. Conclusions
The document analyses the scalability of presence systems and of the
SIP based in particular. It is apparent that the scalability of
these systems is far from being trivial from several perspectives:
number of messages, network bandwidth, state management and CPU load.
Houri, et al. Expires January 25, 2008 [Page 43]
Internet-Draft Presence Scaling Analysis July 2007
As part of the analysis we have analysed several optimizations and
showed the effect of these optimizations on the number of messages
and the number of bytes that are sent between the federating domains.
We have also computed the number of messages and bytes for a very
large number while assuming a protocol that has much less "overhead"
then SIP. Even in that protocol we got relatively high numbers.
It is very possible that the issues that are described in this
document are inherent to presence systems in general and not specific
to the SIMPLE protocol. Organizations need to be prepared to invest
a lot in network and hardware in order to create real big systems.
However, it is apparent that not all the possible optimizations were
done yet and further work is needed in the IETF in order to provide
better scalability
It seems that we need to think about the problem in a different way.
We need to think about scalability as part of the protocol design.
The IETF tends not to think about actual deployments when designing a
protocol but in this case it seems that if we do not think about
scalability with the protocol design it will not be very hard to
scale.
We should also consider whether using the same protocol between
clients and servers and between servers is a good choice with this
problem? It may be that in interdomain or even between servers in
the same domain (as between RLSs and presence servers) there is a
need to have a different protocol that will be very optimized for the
load and can assume some assumptions about the network (e.g. do not
use unreliable protocol as UDP but only TCP).
Another issue that is more concerning protocol design is whether
NOTIFY messages should not be considered as media as the audio, video
and even text messaging are considered? The SUBSCRIBE can be
extended to do similar three way handshake as INVITE and negotiate
where the notify messages should go, rate and other parameters. This
way the load can be offloaded to specialized NOTIFY "relays" thus not
loading the control path of SIP.
7. Security Considerations
This document discusses scalability issues with the existing SIP/
SIMPLE presence protocol and model. Therefore, there are no security
considerations to be considered for this document. However, a lot of
the possible optimizations that should emerge as a result of this
document will have security implications that will need to be solved.
Houri, et al. Expires January 25, 2008 [Page 44]
Internet-Draft Presence Scaling Analysis July 2007
8. Changes from Previous Versions
8.1. Changes in version 02
o Fixed a bug in the calculations. Thanks to Marc Willekens for
finding the bug.
8.2. Changes in version 01
o Clarifications and corrections of the computation model and the
computations.
o Added several more computations to show the influence of different
optimizations.
o The requirements were moved to [17]
o The new suggestions for optimizations were moved to [18]
9. Acknowledgments
We would like to thank Jonathan Rosenberg, Ben Campbell, Markus
Isomaki Piotr Boni, David Viamonte and Aki Niemi for ideas and input.
Special thanks to Marc Willekens for finding a bug in the
calculations.
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
10.2. Informational References
[2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[3] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu,
Z., and J. Rosenberg, "Signaling Compression (SigComp)",
RFC 3320, January 2003.
[4] Rosenberg, J., "A Watcher Information Event Template-Package
for the Session Initiation Protocol (SIP)", RFC 3857,
August 2004.
[5] Rosenberg, J., "An Extensible Markup Language (XML) Based
Format for Watcher Information", RFC 3858, August 2004.
Houri, et al. Expires January 25, 2008 [Page 45]
Internet-Draft Presence Scaling Analysis July 2007
[6] Saint-Andre, P., "End-to-End Signing and Object Encryption for
the Extensible Messaging and Presence Protocol (XMPP)",
RFC 3923, October 2004.
[7] Burger, E., "A Mechanism for Content Indirection in Session
Initiation Protocol (SIP) Messages", RFC 4483, May 2006.
[8] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-
Requena, "Functional Description of Event Notification
Filtering", RFC 4660, September 2006.
[9] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-
Requena, "An Extensible Markup Language (XML)-Based Format for
Event Notification Filtering", RFC 4661, September 2006.
[10] Roach, A., Campbell, B., and J. Rosenberg, "A Session
Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", RFC 4662, August 2006.
[11] Lonnfors, M., "Session Initiation Protocol (SIP) extension for
Partial Notification of Presence Information",
draft-ietf-simple-partial-notify-09 (work in progress),
February 2007.
[12] Lonnfors, M., "Publication of Partial Presence Information",
draft-ietf-simple-partial-publish-06 (work in progress),
February 2007.
[13] Rosenberg, J., "Presence Authorization Rules",
draft-ietf-simple-presence-rules-10 (work in progress),
July 2007.
[14] Garcia-Martin, M., "The Presence-Specific Static Dictionary for
Signaling Compression (Sigcomp)",
draft-garcia-simple-presence-dictionary-05 (work in progress),
May 2007.
[15] Camarillo, G., "Subscriptions to Request-Contained Resource
Lists in the Session Initiation Protocol (SIP)",
draft-ietf-sipping-uri-list-subscribe-05 (work in progress),
May 2006.
[16] Niemi, A., "An Extension to Session Initiation Protocol (SIP)
Events for Conditional Event Notification",
draft-ietf-sip-subnot-etags-00 (work in progress), May 2007.
[17] Houri, A., "Scaling Requirements for Presence in SIP/SIMPLE",
draft-houri-sipping-presence-scaling-requirements-00 (work in
Houri, et al. Expires January 25, 2008 [Page 46]
Internet-Draft Presence Scaling Analysis July 2007
progress), July 2007.
[18] Houri, A., "Scaling Optimizations for Presence in SIP/SIMPLE",
draft-houri-simple-interdomain-scaling-optimizations-00 (work
in progress), July 2007.
[19] Niemi, A., "Session Initiation Protocol (SIP) Event
Notification Extension for Notification Throttling",
draft-niemi-sipping-event-throttle-05 (work in progress),
March 2007.
Authors' Addresses
Avshalom Houri
IBM
Science Park Building 18/D
Rehovot,
Israel
Email: avshalom@il.ibm.com
Tim Rang
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
Email: timrang@microsoft.com
Edwin Aoki
AOL LLC
360 W. Caribbean Drive
Sunnyvale, CA 94089
USA
Email: aoki@aol.net
Houri, et al. Expires January 25, 2008 [Page 47]
Internet-Draft Presence Scaling Analysis July 2007
Vishal Singh
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Email: vs2140@cs.columbia.edu
URI: http://www.cs.columbia.edu/~vs2140
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7004
Email: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Houri, et al. Expires January 25, 2008 [Page 48]
Internet-Draft Presence Scaling Analysis July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Houri, et al. Expires January 25, 2008 [Page 49]