| TOC |
|
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 May 21, 2008.
The document analyzes 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 analyzes 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 analyzed with the possible impact on the load. Separate documents contain the requirements for optimizations and suggestions for new optimizations.
1.
Introduction
2.
Message Load
2.1.
Known Optimizations
2.2.
Assumptions
2.3.
Analysis
2.3.1.
Constants
2.3.2.
Initial Messages
2.3.3.
Steady State Messages
2.3.4.
Termination Messages
2.3.5.
Bottom Line
2.3.6.
Rush Hour Calculations
2.4.
SIMPLE with no optimizations
2.5.
SIMPLE with dialog optimization
2.6.
SIMPLE with NOTIFY optimization
2.7.
SIMPLE with Dialog & NOTIFY optimizations
2.8.
Presence Federations
2.8.1.
Widely distributed inter-domain presence
2.8.2.
Associated inter-domain presence
2.8.3.
Very large network peering
2.8.4.
Intra-domain peering
2.9.
Partial Notifications Optimization
2.10.
Other Protocols
3.
State Management
3.1.
State Size Calculations
3.1.1.
Tiny System
3.1.2.
Medium System
3.1.3.
Large System
3.1.4.
Very Large System
4.
Processing complexities
4.1.
Aggregation
4.2.
Partial Publish and Notify
4.3.
Filtering
4.4.
Authorization
4.5.
Resource List Service
5.
Current Optimizations
6.
Summary
7.
Conclusions
8.
Security Considerations
9.
Changes from Previous Versions
9.1.
Changes in version 03
9.2.
Changes in version 02
9.3.
Changes in version 01
10.
Acknowledgments
11.
References
11.1.
Normative References
11.2.
Informational References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
The document analyzes the traffic that is generated due to presence subscriptions between domains. It is shown that the number of messages and the amount of data sent can be extremely big. In addition to the very large traffic the document also analysis 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 analyzed with the possible impact on the load. Other documents contain the requirements for optimizations [21] (Houri, A., Parameswar, S., Aoki, E., Singh, V., and H. Schulzrinne, “Scaling Requirements for Presence in SIP/SIMPLE,” November 2007.) and suggestions for new optimizations are included in the following documents: [22] (Houri, A., “Scaling Optimizations for Presence in SIP/SIMPLE,” July 2007.). [24] (Rosenberg, J., Donovan, S., and K. McMurry, “Optimizing Federated Presence with View Sharing,” February 2008.)
This document is intended to be drive work on possible solutions that will make the deployment of a presence server more reasonable task. Although a comparison to another protocol is given in the document, the intention of the document is not try to compare the SIP based presence protocol to other types of presence protocols but only to analyze the SIP based presence protocol. It is very likely that that the 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.
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 enterprise or in a very large consumer network.
| TOC |
Some optimizations are approved or are being defined for the SIP presence protocol, but even with these optimizations 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) [12] (Roach, A., Campbell, B., and J. Rosenberg, “A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists,” August 2006.) introduce very similar traffic pattern in intra-domain and in inter-domain. See detailed discussion on resource lists in Section 4.5 (Resource List Service).
| TOC |
The current optimizations that are approved or are approved as working group items in the SIMPLE working group can be divided into two categories:
Note that dialog optimization or RLS usage as it is used in this document refers to the usage of a URI that represents a list of a URI list between domains and not within the same domain. An example is a user Alice in domain example.org that subsides to URI of e.g. external-reps-list at example.com or uses a URI list to subscribe at on her watch list in example.com. Note also that when calculating the traffic that is due to RLS within a domain the traffic between the RLS and the presence agents should also be taken into account. However, since in this document we are mostly dealing with inter- domain traffic, the traffic between the RLS and the presence agents was not taken into account.
| TOC |
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 deployments of presence systems but more from some experience on other types of presence based systems.
In a large consumer network we have seen the following patterns:
In a deployment in enterprises we have seen the following patterns:
Even though the assumptions in this document are not based on rigorous statistical data the target here is not to analyze specific system but show that even with VERY moderate assumptions (which are even less then the observations mentioned above), the number of messages, the network bandwidth, the required state management and 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" calculations of when the day starts and ends were not included yet in this document. 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.
| TOC |
The basic SIMPLE subscription dialog involves the following message- transfer:
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:
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.
| TOC |
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
When dialog optimization [12] (Roach, A., Campbell, B., and J. Rosenberg, “A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists,” August 2006.) is used, an RLMI document is being sent and that document contains the presence documents for the users that are in the watch list. In previous version of this document we have omitted the overhead of the RLMI document. This "bug" was found by Victoria Beltran-Martinez and is being fixed in this document by adding the constants C13, C14 and C15 to the calculations
| TOC |
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.
| TOC |
Here we describe the calculations for the steady state messages. Steady state is 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.
| TOC |
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.
| TOC |
The following are the calculations of several totals that are based on the above calculations.
| TOC |
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.
| TOC |
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. Note that the main calculation is done for a presence document size of 350 bytes which is the base PIDF [6] (Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, “Presence Information Data Format (PIDF),” August 2004.) document size but the bottom line calculation is also given for a presence document size for rich presence [8] (Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, “RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF),” July 2006.) which is assumed to be 3000 bytes based on the examples given in the RFCs. This two folded calculation is done for every use case in this document.
** 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..................350
** 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....................136,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....................326,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
(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..................4,294,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..........2,284,800,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers............11,520,000
Bytes for all watchers..................6,579,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....................136,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....................326,400,000
** Bottom Line
(B01) Total of messages between domains..............12,800,000
Total of bytes between domains (PD=350).....7,232,000,000
Total of bytes between domains (PD=3000)...20,376,000,000
(B02) Total number of messages / second.. ..................444
Total of bytes per second (PD=350)................251,111
Total of bytes per second (PD=3000)...............707,500
(B03) Total number of by msgs per user/day......... ........320
Total number of bytes per user/day (PD=350).......180,800
Total number of bytes per user/day (PD=3000)......509,400
| Figure 1: SIMPLE with no optimizations |
| TOC |
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..................350
(C13) Additional data per document in RLMI..................160
(C14) Multiparty boundary in RLMI document..................144
(C15) XML root node in RLMI document........................144
** 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....................130,400,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....................178,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.............7,040,000
Bytes for all watchers..................5,871,360,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..........1,246,000,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers.............8,160,000
Bytes for all watchers..................7,117,360,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.....................51,920,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.....................99,520,000
** Bottom Line
(B01) Total of messages between domains...............8,480,000
Total of bytes between domains (PD=350).....7,394,880,000
Total of bytes between domains (PD=3000)...20,220,880,000
(B02) Total number of messages / second.....................294
Total of bytes per second (PD=350)................256,767
Total of bytes per second (PD=3000)...............702,114
(B03) Total number of by msgs per user/day..................212
Total number of bytes per user/day (PD=350).......184,872
Total number of bytes per user/day (PD=3000)......505,522
| Figure 2: SIMPLE with Dialog optimizations |
| TOC |
The initial analysis of analysis provided in Figure 1 (SIMPLE with no optimizations) 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 and terminations. As should be expected this optimization affects the steady and termination state and does not affect the initial state.
** 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..................350
** 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....................136,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....................326,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
(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..................4,294,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..................5,212,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.....................0
(T04) Terminating 200 OK msgs (NOTIFY) per watcher............0
(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.....................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...............320,000
Bytes for all watchers....................131,200,000
** Bottom Line
(B01) Total of messages between domains..............10,240,000
Total of bytes between domains (PD=350).....5,670,400,000
Total of bytes between domains (PD=3000)...15,422,400,000
(B02) Total number of messages / second.....................356
Total of bytes per second (PD=350)................196,889
Total of bytes per second (PD=3000)...............535,500
(B03) Total number of by msgs per user/day..................256
Total number of bytes per user/day (PD=350).......141,760
Total number of bytes per user/day (PD=3000)......385,560
| Figure 3: SIMPLE with NOTIFY optimizations |
| TOC |
Here both optimizations are combined. In all the subsequent 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..................350
(C13) Additional data per document in RLMI..................160
(C14) Multiparty boundary in RLMI document..................144
(C15) XML root node in RLMI document........................144
** 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....................130,400,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....................178,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.............7,040,000
Bytes for all watchers..................5,871,360,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..................6,100,960,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.....................0
(T04) Terminating 200 OK msgs (NOTIFY) per watcher............0
(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.....................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................80,000
Bytes for all watchers.....................32,800,000
** Bottom Line
(B01) Total of messages between domains...............7,840,000
Total of bytes between domains (PD=350).....6,311,760,000
Total of bytes between domains (PD=3000)...16,063,760,000
(B02) Total number of messages / second.....................272
Total of bytes per second (PD=350)................219,158
Total of bytes per second (PD=3000)...............557,769
(B03) Total number of by msgs per user/day..................196
Total number of bytes per user/day (PD=350).......157,794
Total number of bytes per user/day (PD=3000)......401,594
| Figure 4: SIMPLE with Dialog & NOTIFY optimizations |
| TOC |
While 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.
| TOC |
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:
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.
** 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..............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..................350
** 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....................680,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..................1,632,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.................21,472,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
Bytes for all watchers per day.........11,424,000,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers............57,600,000
Bytes for all watchers.................32,896,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....................680,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..................1,632,000,000
** Bottom Line
B01 Total of messages between domains................64,000,000
Total of bytes between domains (PD=350)........36,160,000,000
Total of bytes between domains (PD=3000)......101,880,000,000
B02 Total number of messages / second.....................2,222
Total of bytes per second (PD=350)..................1,255,556
Total of bytes per second (PD=3000).................3,537,500
B03 Total number of by msgs per user/day..................1,600
Total number of bytes per user/day (PD=350)...........904,000
Total number of bytes per user/day (PD=3000)........2,547,000
(B01) Total of messages between domains..............64,000,000
Total of bytes between domains (PD=350)....36,160,000,000
Total of bytes between domains (PD=3000)..101,880,000,000
(B02) Total number of messages / second...................2,222
Total of bytes per second (PD=350)..............1,255,556
Total of bytes per second (PD=3000).............3,537,500
(B03) Total number of by msgs per user/day................1,600
Total number of bytes per user/day (PD=350).......904,000
Total number of bytes per user/day (PD=3000).....,547,000
| 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
(C11) Size of an average presence document..................350
(C13) Additional data per document in RLMI..................160
(C14) Multiparty boundary in RLMI document..................144
(C15) XML root node in RLMI document........................144
** 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....................548,960,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....................596,560,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.................29,356,800,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.................29,586,400,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.....................0
(T04) Terminating 200 OK msgs (NOTIFY) per watcher............0
(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.....................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................80,000
Bytes for all watchers.....................32,800,000
** Bottom Line
(B01) Total of messages between domains..............36,000,000
Total of bytes between domains (PD=350)....30,215,760,000
Total of bytes between domains (PD=3000)...78,975,760,000
(B02) Total number of messages / second...................1,250
Total of bytes per second (PD=350)..............1,049,158
Total of bytes per second (PD=3000).............2,742,214
B(03 )Total number of by msgs per user/day..................900
Total number of bytes per user/day (PD=350).......755,394
Total number of bytes per user/day (PD=3000)....1,974,394
| Figure 6: Widely distributed inter-domain with optimizations |
| TOC |
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:
This federation type has traffic rates similar to the previous examples but with different levels of association of the users.
| TOC |
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:
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.
** 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..................350
** 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...........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................170,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................408,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.............11,224,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......2,856,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.............14,080,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
(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................170,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................408,000,000,000
** Bottom Line
(B01) Total of messages between domains..........25,600,000,000
Total of bytes bet. domains (PD=350)...14,896,000,000,000
Total of bytes bet. domains (PD=3000)..44,046,000,000,000
(B02) Total number of messages / second.................888,889
Total of bytes per second (PD=350)............517,222,222
Total of bytes per second (PD=3000).........1,529,375,000
(B03) Total number of by msgs per user/day................1,280
Total number of bytes per user/day (PD=350).......744,800
Total number of bytes per user/day (PD=3000)....2,202,300
| 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..................350
(C13) Additional data per document in RLMI..................160
(C14) Multiparty boundary in RLMI document..................144
(C15) XML root node in RLMI document........................144
** 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................143,680,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................167,480,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.............15,345,600,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.............15,460,400,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.....................0
(T04) Terminating 200 OK msgs (NOTIFY) per watcher............0
(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.....................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............40,000,000
Bytes for all watchers.................16,400,000,000
** Bottom Line
(B01) Total of messages between domains..........18,800,000,000
Total of bytes bet. domains (PD=350)...15,644,400,000,000
Total of bytes bet. domains (PD=3000)..40,554,280,000,000
(B02) Total number of messages / second.................652,778
Total of bytes per second (PD=350)............543,208,333
Total of bytes per second (PD=3000).........1,408,134,722
(B03) Total number of by msgs per user/day..................940
Total number of bytes per user/day (PD=350).......782,220
Total number of bytes per user/day (PD=3000)....2,027,714
| Figure 8: Very large network peering with optimizations |
| TOC |
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
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
(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..................350
** 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..................1,020,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..................2,448,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.................32,208,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.........17,136,000,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers............86,400,000
Bytes for all watchers.................49,344,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..................1,020,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..................2,448,000,000
** Bottom Line
(B01) Total of messages between domains..............96,000,000
Total of bytes between domains (PD=350)....54,240,000,000
Total of bytes between domains (PD=3000)..152,820,000,000
(B02) Total number of messages / second...................3,333
Total of bytes per second (PD=350)..............1,883,333
Total of bytes per second (PD=3000).............5,306,250
B(03 )Total number of by msgs per user/day..................800
Total number of bytes per user/day (PD=350).......452,000
Total number of bytes per user/day (PD=3000)....1,273,500
| Figure 9: Intra-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..................350
(C13) Additional data per document in RLMI..................160
(C14) Multiparty boundary in RLMI document..................144
(C15) XML root node in RLMI document........................144
** 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....................862,080,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..................1,004,880,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.................44,035,200,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............688,800,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers............54,480,000
Bytes for all watchers.................44,724,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...............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.....................0
Bytes for all watchers..............................0
(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...............240,000
Bytes for all watchers.....................98.400,000
** Bottom Line
(B01) Total of messages between domains..............55,200,000
Total of bytes between domains (PD=350)....45,827,280,000
Total of bytes between domains (PD=3000)..118,967,280,000
(B02) Total number of messages / second...................1,917
Total of bytes per second (PD=350)..............1,591,225
Total of bytes per second (PD=3000).............4,130,808
(B03) Total number of by msgs per user/day..................460
Total number of bytes per user/day (PD=350).......381,894
Total number of bytes per user/day (PD=3000)......991,394
| Figure 10: Intra-domain peering with optimizations |
| TOC |
Draft [15] (Lonnfors, M., Costa-Requena, J., Leppanen, E., and H. Khartabil, “Session Initiation Protocol (SIP) extension for Partial Notification of Presence Information,” January 2008.) 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. It is also assumed that only a single attribute in the presence document will be changed each time, thus the size of the partial presence document is assumed to be 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..............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..................350
(C12) Size of an average partial presence document..........200
** 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...........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,00,000,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers................170,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................408,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..............9,844,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.................................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,800,000,000
Bytes for all watchers per day......1,148,000,000,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers........21,200,000,000
Bytes for all watchers.............10,992,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.....................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.................90,000,000,000
(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.....................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...........400,000,000
Bytes for all watchers................164.000,000,000
** Bottom Line
(B01) Total of messages between domains..........22,400,000,000
Total of bytes bet. domains (PD=350)...11,564,000,000,000
Total of bytes bet. domains (PD=3000)..12,094,000,000,000
(B02) Total number of messages / second.................777,778
Total of bytes per second (PD=350)............401,527,778
Total of bytes per second (PD=3000)...........419,930,556
(B03) Total number of by msgs per user/day................1,120
Total number of bytes per user/day (PD=350).......578,200
Total number of bytes per user/day (PD=3000)......604,700
| Figure 11: Very large networks peering with NOTIFY and partial optimizations |
| TOC |
In SIP there are several differences from other protocols of presence as XMPP [7] (Saint-Andre, P., “End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP),” October 2004.) and the proprietary protocols of the consumer domains. The differences are:
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..................350
** 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................100,000,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................130,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......................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..............4,600,000,000,000
(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..............4,600,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 of messages between domains...........9,800,000,000
Total of bytes between domains (PD=50)..1,940,000,000,000
Total of bytes between domains (PD=350).4,760,000,000,000
Total of bytes bet. domains (PD=3000)..29,670,000,000,000
(B02) Total number of messages / second.................340,278
Total of bytes per second (PD=50)..............67,361,111
Total of bytes per second (PD=350)............165,277,778
Total of bytes per second (PD=3000).........1,030,208,333
(B03) Total number of by msgs per user/day..................490
Total number of bytes per user/day (PD=50).........97,000
Total number of bytes per user/day (PD=350).......238,000
Total number of bytes per user/day (PD=3000)....1,483,500
| Figure 12: Very large networks peering in other protocols |
| TOC |
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 analyzed and shown to be far from trivial.
The presence server has two parallel tasks.
For a single subscription from a single watcher on a presentity, the presence server has to maintain the following state:
For each presentity that has been subscribed to in the presence server, the presence server has to maintain the following state:
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.
| TOC |
Lets assume the following sizes:
| TOC |
Total is 82M bytes.
| TOC |
Total is 830M bytes.
| TOC |
Total is 38G bytes.
| TOC |
Total is 952G bytes which is a very big number for a very dynamic storage as needed by the presence server.
Although the numbers above may seem moderate enough for the sizes that the presence server is handling we should consider the following:
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...
| TOC |
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.
| TOC |
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
| TOC |
Drafts [15] (Lonnfors, M., Costa-Requena, J., Leppanen, E., and H. Khartabil, “Session Initiation Protocol (SIP) extension for Partial Notification of Presence Information,” January 2008.), [16] (Niemi, A., Lonnfors, M., and E. Leppanen, “Publication of Partial Presence Information,” February 2008.) 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 [15] (Lonnfors, M., Costa-Requena, J., Leppanen, E., and H. Khartabil, “Session Initiation Protocol (SIP) extension for Partial Notification of Presence Information,” January 2008.) 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.
| TOC |
Filtering as defined in RFCs [10] (Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, “Functional Description of Event Notification Filtering,” September 2006.), [11] (Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, “An Extensible Markup Language (XML)-Based Format for Event Notification Filtering,” September 2006.) 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.
| TOC |
Draft [17] (Rosenberg, J., “Presence Authorization Rules,” July 2007.) 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.
| TOC |
RFC [12] (Roach, A., Campbell, B., and J. Rosenberg, “A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists,” August 2006.) 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:
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.
| TOC |
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 any working group yet are summarized in [22] (Houri, A., “Scaling Optimizations for Presence in SIP/SIMPLE,” July 2007.) and in [24] (Rosenberg, J., Donovan, S., and K. McMurry, “Optimizing Federated Presence with View Sharing,” February 2008.). Note that trials with batched notifies optimization that is describes in [22] (Houri, A., “Scaling Optimizations for Presence in SIP/SIMPLE,” July 2007.), showed an improvement of 117% in the whole throughput of presence traffic.
| TOC |
Following is a summary of the various calculations. This is repeated here in order to ease the understanding of the conclusions that are listed below.
The following table summarizes the various constants that are used in ALL calculations.
(C01) Subscription lifetime (hours)...........................8
(C03) Subscription refresh interval / hour....................1
(C05) Number of dialogs to maintain per watcher = Number of
federated presentities when dialog optimization is
not used and to 1 when dialog optimization is used.
(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..........350 or 3000
Calculations are done for both sizes
(C12) Size of an average partial presence document..........200
(C13) Additional data per document in RLMI..................160
(C14) Multiparty boundary in RLMI document..................144
(C15) XML root node in RLMI document........................144
| Figure 13: Constants in ALL calculations |
The following table summarizes the results of various optimization factors for the basic use case.
C02 Presence state changes / hour.............................3 C04 Total federated presentities per watcher..................4 C06 Total # of watchers in the federated domains.........40,000 No optimizations are applied B01 Total of messages between domains................12,800,000 Total of bytes between domains (PD=350).........7,232,000,000 Total of bytes between domains (PD=3000).......20,376,000,000 B02 Total number of messages / second.......................444 Total of bytes per second (PD=350)....................251,111 Total of bytes per second (PD=3000)...................707,500 B03 Total number of by msgs per user/day....................320 Total number of bytes per user/day (PD=350)...........180,800 Total number of bytes per user/day (PD=3000)..........509,400 Dialog optimization is applied B01 Total of messages between domains.................8,480,000 Total of bytes between domains (PD=350).........7,394,880,000 Total of bytes between domains (PD=3000).......20,220,880,000 B02 Total number of messages / second.......................294 Total of bytes per second (PD=350)....................256,767 Total of bytes per second (PD=3000)...................702,114 B03 Total number of by msgs per user/day....................212 Total number of bytes per user/day (PD=350)...........184,872 Total number of bytes per user/day (PD=3000)..........505,522 Notify optimization is applied B01 Total of messages between domains................10,240,000 Total of bytes between domains (PD=350).........5,670,400,000 Total of bytes between domains (PD=3000).......15,422,400,000 B02 Total number of messages / second.......................356 Total of bytes per second (PD=350)....................196,889 Total of bytes per second (PD=3000)...................535,500 B03 Total number of by msgs per user/day....................256 Total number of bytes per user/day (PD=350)...........141,760 Total number of bytes per user/day (PD=3000)..........385,560 Dialog and notify optimizations are applied B01 Total of messages between domains.................7,840,000 Total of bytes between domains (PD=350).........6,311,760,000 Total of bytes between domains (PD=3000).......16,063,760,000 B02 Total number of messages / second.......................272 Total of bytes per second (PD=350)....................219,158 Total of bytes per second (PD=3000)...................557,769 B03 Total number of by msgs per user/day....................196 Total number of bytes per user/day (PD=350)...........157,794 Total number of bytes per user/day (PD=3000)..........401,594
| Figure 14: Basic use case |
The following table summarizes the results of various optimization factors for the widely distributed inter domain use case.
C02 Presence state changes / hour.............................3 C04 Total federated presentities per watcher.................20 C06 Total # of watchers in the federated domains.........40,000 No optimizations are applied B01 Total of messages between domains................64,000,000 Total of bytes between domains (PD=350)........36,160,000,000 Total of bytes between domains (PD=3000)......101,880,000,000 B02 Total number of messages / second.....................2,222 Total of bytes per second (PD=350)..................1,255,556 Total of bytes per second (PD=3000).................3,537,500 B03 Total number of by msgs per user/day..................1,600 Total number of bytes per user/day (PD=350)...........904,000 Total number of bytes per user/day (PD=3000)........2,547,000 Dialog and notify optimizations are applied B01 Total of messages between domains................36,000,000 Total of bytes between domains (PD=350)........30,215,760,000 Total of bytes between domains (PD=3000).......78,975,760,000 B02 Total number of messages / second.....................1,250 Total of bytes per second (PD=350)..................1,049,158 Total of bytes per second (PD=3000).................2,742,214 B03 Total number of by msgs per user/day....................900 Total number of bytes per user/day (PD=350)...........755,394 Total number of bytes per user/day (PD=3000)........1,974,394
| Figure 15: Widely distributed inter-domain |
The following table summarizes the results of various optimization factors for the intra-domain peering use case.
C02 Presence state changes / hour.............................3 C04 Total federated presentities per watcher.................10 C06 Total # of watchers in the federated domains........120,000 No optimizations are applied B01 Total of messages between domains................96,000,000 Total of bytes between domains (PD=350)........54,240,000,000 Total of bytes between domains (PD=3000)......152,820,000,000 B02 Total number of messages / second.....................3,333 Total of bytes per second (PD=350)..................1,883,333 Total of bytes per second (PD=3000).................5,306,250 B03 Total number of by msgs per user/day....................800 Total number of bytes per user/day (PD=350)...........452,000 Total number of bytes per user/day (PD=3000)........1,273,500 Dialog and notify optimizations are applied B01 Total of messages between domains................55,200,000 Total of bytes between domains (PD=350)........45,827,280,000 Total of bytes between domains (PD=3000)......118,967,280,000 B02 Total number of messages / second.....................1,917 Total of bytes per second (PD=350)..................1,591,225 Total of bytes per second (PD=3000).................4,130,808 B03 Total number of by msgs per user/day....................460 Total number of bytes per user/day (PD=350)...........381,894 Total number of bytes per user/day (PD=3000)..........991,394
| Figure 16: Inter-domain peering |
The following table summarizes the results of various optimization factors for the very large scale peering networks use case.
C02 Presence state changes / hour.............................6 C04 Total federated presentities per watcher.................10 C06 Total # of watchers in the federated domains.....20,000,000 No optimizations are applied B01 Total of messages between domains............25,600,000,000 Total of bytes between domains (PD=350)....14,896,000,000,000 Total of bytes between domains (PD=3000)...44,046,000,000,000 B02 Total number of messages / second...................888,889 Total of bytes per second (PD=350)................517,222,222 Total of bytes per second (PD=3000).............1,529,375,000 B03 Total number of by msgs per user/day..................1,280 Total number of bytes per user/day (PD=350)...........744,800 Total number of bytes per user/day (PD=3000)........2,202,300 Dialog and notify optimizations are applied B01 Total of messages between domains............18,800,000,000 Total of bytes between domains (PD=350)....15,644,400,000,000 Total of bytes between domains (PD=3000)...40,554,280,000,000 B02 Total number of messages / second...................652,778 Total of bytes per second (PD=350)................543,208,333 Total of bytes per second (PD=3000).............1,408,134,722 B03 Total number of by msgs per user/day....................940 Total number of bytes per user/day (PD=350)...........782,220 Total number of bytes per user/day (PD=3000)........2,027,714 Partial and notify optimizations are applied B01 Total of messages between domains............22,400,000,000 Total of bytes between domains (PD=350)....11,564,000,000,000 Total of bytes between domains (PD=3000)...12,094,000,000,000 B02 Total number of messages / second...................777,778 Total of bytes per second (PD=350)................401,527,778 Total of bytes per second (PD=3000)...............419,930,556 B03 Total number of by msgs per user/day..................1,120 Total number of bytes per user/day (PD=350)...........578,200 Total number of bytes per user/day (PD=3000)..........604,700 Calculation for other protocols B01 Total of messages between domains.............9,800,000,000 Total of bytes between domains (PD=50)......1,940,000,000,000 Total of bytes between domains (PD=350).....4,760,000,000,000 Total of bytes between domains (PD=3000)...29,670,000,000,000 B02 Total number of messages / second...................340,278 Total of bytes per second (PD=50)..................67,361,111 Total of bytes per second (PD=350)................165,277,778 Total of bytes per second (PD=3000).............1,030,208,333 B03 Total number of by msgs per user/day....................490 Total number of bytes per user/day (PD=50).............97,000 Total number of bytes per user/day (PD=350)...........238,000 Total number of bytes per user/day (PD=3000)........1,483,500
| Figure 17: Very large scale peering networks |
| TOC |
The following conclusions can be drawn from the above numbers:
The document analyzes 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.
As part of the analysis we have analyzed 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 scale peering network 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
Nevertheless, we should remember that SIP was originally designed for end to end session creation and number and size of messages are of secondary importance for end to end session negotiation. For large scale and especially for very large scale presence the number of messages that are needed and the size of each message are of extreme importance. 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 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).
When servers is connecting to another server using current protocol, there will be an extreme number of redundant messages due to the overhead of supporting UDP and to the need to send multiple presence documents for the same watched user due to privacy issue. A server to server protocol will have to address these issues. Some initial work to address these issues can be found in: [22] (Houri, A., “Scaling Optimizations for Presence in SIP/SIMPLE,” July 2007.), [24] (Rosenberg, J., Donovan, S., and K. McMurry, “Optimizing Federated Presence with View Sharing,” February 2008.) and [25] (Rosenberg, J., “Models for Intra-Domain Presence Federation,” February 2008.)
Another issue that is more concerning protocol design is whether NOTIFY messages should not be considered as media as 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 a specialized NOTIFY "relays" thus not loading the control path of SIP. One of the possible ideas (Marc Willekens) is to use the SIP stack for the client/server NOTIFY but make use of a more optimized and controllable protocol for the server-to-server interface. Another possibility is to use the MSRP [13] (Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” September 2007.), [14] (Jennings, C., Mahy, R., and A. Roach, “Relay Extensions for the Message Sessions Relay Protocol (MSRP),” September 2007.)protocol for the notifies.
| TOC |
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.
| TOC |
| TOC |
| TOC |
| TOC |
| TOC |
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 and Victoria Beltran-Martinez for finding issues in the calculations.
| TOC |
| TOC |
| [1] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| TOC |
| [2] | Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” RFC 3265, June 2002 (TXT). |
| [3] | Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z., and J. Rosenberg, “Signaling Compression (SigComp),” RFC 3320, January 2003 (TXT). |
| [4] | Rosenberg, J., “A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP),” RFC 3857, August 2004 (TXT). |
| [5] | Rosenberg, J., “An Extensible Markup Language (XML) Based Format for Watcher Information,” RFC 3858, August 2004 (TXT). |
| [6] | Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, “Presence Information Data Format (PIDF),” RFC 3863, August 2004 (TXT). |
| [7] | Saint-Andre, P., “End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP),” RFC 3923, October 2004 (TXT, HTML, XML). |
| [8] | Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, “RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF),” RFC 4480, July 2006 (TXT). |
| [9] | Burger, E., “A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages,” RFC 4483, May 2006 (TXT). |
| [10] | Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, “Functional Description of Event Notification Filtering,” RFC 4660, September 2006 (TXT). |
| [11] | 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 (TXT). |
| [12] | Roach, A., Campbell, B., and J. Rosenberg, “A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists,” RFC 4662, August 2006 (TXT). |
| [13] | Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” RFC 4975, September 2007 (TXT). |
| [14] | Jennings, C., Mahy, R., and A. Roach, “Relay Extensions for the Message Sessions Relay Protocol (MSRP),” RFC 4976, September 2007 (TXT). |
| [15] | Lonnfors, M., Costa-Requena, J., Leppanen, E., and H. Khartabil, “Session Initiation Protocol (SIP) extension for Partial Notification of Presence Information,” draft-ietf-simple-partial-notify-10 (work in progress), January 2008 (TXT). |
| [16] | Niemi, A., Lonnfors, M., and E. Leppanen, “Publication of Partial Presence Information,” draft-ietf-simple-partial-publish-07 (work in progress), February 2008 (TXT). |
| [17] | Rosenberg, J., “Presence Authorization Rules,” draft-ietf-simple-presence-rules-10 (work in progress), July 2007 (TXT). |
| [18] | Garcia-Martin, M., “The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp),” draft-garcia-simple-presence-dictionary-06 (work in progress), August 2007 (TXT). |
| [19] | 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 (TXT). |
| [20] | Niemi, A., “An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification,” draft-ietf-sip-subnot-etags-03 (work in progress), March 2009 (TXT). |
| [21] | Houri, A., Parameswar, S., Aoki, E., Singh, V., and H. Schulzrinne, “Scaling Requirements for Presence in SIP/SIMPLE,” draft-houri-sipping-presence-scaling-requirements-01 (work in progress), November 2007 (TXT). |
| [22] | Houri, A., “Scaling Optimizations for Presence in SIP/SIMPLE,” draft-houri-simple-interdomain-scaling-optimizations-00 (work in progress), July 2007 (TXT). |
| [23] | Niemi, A., Kiss, K., and S. Loreto, “Session Initiation Protocol (SIP) Event Notification Extension for Notification Throttling,” draft-niemi-sipping-event-throttle-08 (work in progress), February 2009 (TXT). |
| [24] | Rosenberg, J., Donovan, S., and K. McMurry, “Optimizing Federated Presence with View Sharing,” draft-rosenberg-simple-view-sharing-01 (work in progress), February 2008 (TXT). |
| [25] | Rosenberg, J., “Models for Intra-Domain Presence Federation,” draft-rosenberg-simple-intradomain-federation-01 (work in progress), February 2008 (TXT). |
| TOC |
| Avshalom Houri | |
| IBM | |
| Science Park Building 18/D | |
| Rehovot, | |
| Israel | |
| Email: | avshalom@il.ibm.com |
| Edwin Aoki | |
| AOL LLC | |
| 360 W. Caribbean Drive | |
| Sunnyvale, CA 94089 | |
| USA | |
| Email: | aoki@aol.net |
| Sriram Parameswar | |
| Microsoft Corporation | |
| One Microsoft Way | |
| Redmond, WA 98052 | |
| USA | |
| Email: | Sriram.Parameswar@microsoft.com |
| Tim Rang | |
| Microsoft Corporation | |
| One Microsoft Way | |
| Redmond, WA 98052 | |
| USA | |
| Email: | timrang@microsoft.com |
| 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 |
| TOC |
Copyright © 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.
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.