SIMPLE WG A. Houri Internet-Draft IBM Intended status: Informational E. Aoki Expires: April 25, 2009 AOL LLC S. Parameswar T. Rang Microsoft Corporation V. Singh H. Schulzrinne Columbia U. October 22, 2008 Presence Interdomain Scaling Analysis for SIP/SIMPLE draft-ietf-simple-interdomain-scaling-analysis-05.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 25, 2009. Abstract 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 Houri, et al. Expires April 25, 2009 [Page 1] Internet-Draft Presence Scaling Analysis October 2008 optimizations to the SIP protocol are analyzed with the possible impact on the load. Separate documents contain the requirements for optimizations and suggestions for new optimizations. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Message Load . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Known Optimizations . . . . . . . . . . . . . . . . . . . 5 2.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3.1. Constants . . . . . . . . . . . . . . . . . . . . . . 8 2.3.2. Initial Messages . . . . . . . . . . . . . . . . . . . 10 2.3.3. Steady State Messages . . . . . . . . . . . . . . . . 10 2.3.4. Termination Messages . . . . . . . . . . . . . . . . . 12 2.3.5. Bottom Line . . . . . . . . . . . . . . . . . . . . . 12 2.3.6. Rush Hour Calculations . . . . . . . . . . . . . . . . 13 2.4. No optimizations used . . . . . . . . . . . . . . . . . . 13 2.5. Dialog optimization used . . . . . . . . . . . . . . . . . 15 2.6. NOTIFY optimization used . . . . . . . . . . . . . . . . . 17 2.7. Dialog & NOTIFY optimizations used . . . . . . . . . . . . 19 2.8. Presence Federation Scenarios . . . . . . . . . . . . . . 21 2.8.1. Widely distributed inter-domain presence . . . . . . . 22 2.8.2. Associated inter-domain presence . . . . . . . . . . . 26 2.8.3. Very large network peering . . . . . . . . . . . . . . 27 2.8.4. Intra-domain peering . . . . . . . . . . . . . . . . . 31 2.9. Partial Notifications Optimization . . . . . . . . . . . . 36 2.10. Very Optimized SIP . . . . . . . . . . . . . . . . . . . . 38 3. State Management . . . . . . . . . . . . . . . . . . . . . . . 42 3.1. State Size Calculations . . . . . . . . . . . . . . . . . 43 3.1.1. Tiny System . . . . . . . . . . . . . . . . . . . . . 44 3.1.2. Medium System . . . . . . . . . . . . . . . . . . . . 44 3.1.3. Large System . . . . . . . . . . . . . . . . . . . . . 44 3.1.4. Very Large System . . . . . . . . . . . . . . . . . . 44 4. Processing complexities . . . . . . . . . . . . . . . . . . . 45 4.1. Aggregation . . . . . . . . . . . . . . . . . . . . . . . 45 4.2. Partial Publish and Notify . . . . . . . . . . . . . . . . 46 4.3. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 46 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 46 4.5. Resource List Service . . . . . . . . . . . . . . . . . . 47 5. Current Optimizations . . . . . . . . . . . . . . . . . . . . 48 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 55 8. Security Considerations . . . . . . . . . . . . . . . . . . . 56 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 10. Changes from Previous Versions . . . . . . . . . . . . . . . . 57 10.1. Changes in version 05 . . . . . . . . . . . . . . . . . . 57 Houri, et al. Expires April 25, 2009 [Page 2] Internet-Draft Presence Scaling Analysis October 2008 10.2. Changes in version 04 . . . . . . . . . . . . . . . . . . 57 10.3. Changes in version 03 . . . . . . . . . . . . . . . . . . 57 10.4. Changes in version 02 . . . . . . . . . . . . . . . . . . 58 10.5. Changes in version 01 . . . . . . . . . . . . . . . . . . 58 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58 12. Informational References . . . . . . . . . . . . . . . . . . . 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60 Intellectual Property and Copyright Statements . . . . . . . . . . 62 Houri, et al. Expires April 25, 2009 [Page 3] Internet-Draft Presence Scaling Analysis October 2008 1. Introduction The document analyzes the SIP protocol for presence (AKA SIMPLE but SIMPLE is not a different protocol then SIP but the name of the working group). It analyses the traffic that is generated due to presence subscriptions between domains. It is shown that the number of messages and the amount of data 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 SIP protocol are analyzed with the possible impact on the load. Another document provides requirements for optimizations [18] while other documents contain suggestions for new optimizations: [19]. [21] This document is intended to be drive work on possible solutions that will make the deployment of a SIP based presence server less challenging task. Deployment of highly scalable presence systems is challenging by its nature and each protocol developers design their own technique for optimizing their protocol. This document does not try to compare between protocols and it is behind the scope of this document. The document discusses the following areas. In each area we try to show the complexity and the load that the presence server has to handle in order to provide its service. o Messages load - By computing the number of messages that are required for connecting presence systems the document shows that the number of messages is very big and it is quite obvious that some optimizations are needed. In addition we also show that the bandwidth required is also very big. o State management - Due to the nature of the service that the presence server provides, the presence server has to manage a relatively big and complex state and some computations are provided in the document. o Processing complexities - The presence server maintains many small objects and has to do frequent operations on these objects. We show that these operations and especially the optimizations that are intended to save on the amount of data that is being sent between watchers and presence servers, are not so simple and may create a very heavy processing load on the presence server. o Groups - Resource List Servers [9] optimize the number of sessions that are created between the watchers and the presence server. On the other hand, this optimization may create an exponential size of subscription due to the unbearable ease of subscribing to large groups. The term presence domain or presence system appears in the document Houri, et al. Expires April 25, 2009 [Page 4] Internet-Draft Presence Scaling Analysis October 2008 several time. By this term we refer to a SIP based 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. 2. Message Load 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) [9] introduce very similar traffic pattern in intra-domain and in inter-domain. See detailed discussion on resource lists in Section 4.5. 2.1. Known Optimizations The current optimizations that are approved or are approved as working group items in the SIMPLE working group can be divided into two categories: o Dialogs saving optimization - Here we refer to optimizations as the resource list RFC [9] or to the URI list subscriptions draft [16]. These documents define ways to reduce the number of dialogs that are required between the subscriber and the presence system. 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. o Notification optimizations - Here we refer to the optimizations that are suggested in the subnot-etags draft [17]. This draft suggests ways to suppress the sending of unnecessary notifies when for example a subscription is refreshed. There are other drafts Houri, et al. Expires April 25, 2009 [Page 5] Internet-Draft Presence Scaling Analysis October 2008 that reduce the size of messages as partial notifications or filtering but in this document we mostly care about the amount of messages & bandwidth so the partial optimizations can help a bit in the bandwidth but will not help in the number of messages. In addition to the above optimizations another optimization could have been considered but it is not taken into account in the computations in this document. This optimization is the ability to have some of the presence information received not by the SIP protocol but by offline means as downloading some persistent presence information directly from a web site or by some other offline means. The calculations here are based on the assumption that all data is carried in-bound of the protocol and no optimizations that enable getting the presence information via out bound means are taken into account. These optimizations may improve the number of messages and number of bytes significantly but they are out of scope for this document 2.2. Assumptions In the document several assumptions are used 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. The following numbers are given more as examples from real deployments and they are not intended to be complete In a large consumer network we have seen the following patterns: o Approximately 110 users in the watch list in average. o There are approximately 12 billion status changes a day (139k/ second) across the network. Of these, when a proprietary binary protocol is used to convey the status changes the average of the message is about 188 bytes. When SIP NOTIFY is used the average is about 1228 bytes for the message. o The average of logins/logouts in the system is about 2000 logins per second and about 4000 logouts per second. When something happens - either a promotion, contest, or a network hiccup that causes many users to login and logout simultaneously, there are about 20,000 logins per second. o The peak of the instant messages sent is about 50,000 messages per second. In a deployment in enterprises we have seen the following patterns: Houri, et al. Expires April 25, 2009 [Page 6] Internet-Draft Presence Scaling Analysis October 2008 o Averages watch list size was 200 users. o About half of the registered users were online at peak time o Status change per hour was 2 changes per hour. o The average logins/logouts in the system was about 5 logins per second with additional 15 logins/logouts during start/end of day rush hours. 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 are very high. Real life systems should have a much bigger scalability challenges. 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 that use more presence attributes like mood etc.. 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 it is very much dependent on the behavior of users and behavior of users differs a lot. Some users will have a very small number of presentities in their watch list while others may have hundreds if not thousands. 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 document all the possible combinations. Throughout the calculations certain number of users are assumed for the different models. It does not mean that in actual deployments all the users of the domain actually subscribed to presence documents and/or publish their presence document. Observing actual deployments shows that in the consumer market the number of users that use presence services may be 10 percent or less of the registered users. In the enterprise market numbers tend to be around 50 percent of the actual enterprise registered users. The same is correct for the number for of watched presentities per watcher. if only some percent of the domain users are online at a given time then this number should have been that percentage. Houri, et al. Expires April 25, 2009 [Page 7] Internet-Draft Presence Scaling Analysis October 2008 However, trying to add this assumption to the calculations will make the calculations more complex then they are since the affect of the watched presentities that are not online will need to be taken into account. This means that empty notify should be sent for those when the subscription is created and there is no updates on them. In order to make the computations less complex (they are complex enough as they are), the number of the watched presentities that is used in the calculations is the number of the federated presentities from the watcher list that are online. 2.3. Analysis The basic SIP subscription dialog involves the following message- transfer: o SUBSCRIBE/200 o Initial NOTIFY/200 o (j) NOTIFY/200 where 'j' is the number of presence changes seen by the watcher o (k) SUBSCRIBE/200 where 'k' is the number of subscription dialog refresh periods o SUBSCRIBE/200 with Expires = 0 to terminate the dialog o NOTIFY/200 ending the dialog An individual watcher will generate X number of SIP subscription dialogs corresponding to the number of presentities it chooses to watch. The amount of traffic generated is significantly affected by several factors: o Number of watchers connected to the system o Number of presentities connected to the system o Frequency of changes to presence information This document contains several calculations that show the expected message rate and bandwidth between presence domains. The following sections explain the assumptions and methods behind the calculations. 2.3.1. Constants The following are number of "constants" that we use in the calculations. Some of the constants are used throughout the calculation while other change between use cases o (C01) Subscription lifetime (hours)- The assumed lifetime of a subscription in hours. We assume 8 hours for all calculations. o (C02) Presence state changes / hour - The average time that a presentity changes his/hers status in one hour. We assumed 3 times per hour for most calculations. Note that for some users in Houri, et al. Expires April 25, 2009 [Page 8] Internet-Draft Presence Scaling Analysis October 2008 consumer messaging systems, the actual number of changes is likely to be much higher. o (C03) Subscription refresh interval / hour - The duration of the SUBSCRIBE session after which it needs to be refreshed. We assumed that the duration is one hour. o (C04) Total federated presentities per watcher - The number of presentities that the watcher is watching. The number here changes in this document according to the type of the specific deployment. o (C05) Number of dialogs to maintain per watcher - The number of the SUBSCRIBE dialogs that are maintained per watcher. if a dialog optimization is not assumed this number is equal to A04, otherwise it is 1. o (C06) Total number of watchers in the federated presence domains. The number here is the number of all watchers in all the federated domains. o (C07) SUBSCRIBE message size in bytes. We assume 450 bytes in all calculations. The size is based on a typical SUBSCIRBE taken from RFCs. o (C08) 200 OK for SUBSCRIBE message size in bytes. We assume 370 bytes in all calculations. The size is based on a typical 200 OK taken from RFCs. o (C09) NOTIFY message size not including the presence document. The size of this message for a single presentity is assumed to be 500 bytes for the NOTIFY message itself (based on sizes from examples in RFCs). o (C10) 200 OK for NOTIFY message size in bytes. We assume 370 bytes in all calculations. The size is based on a typical 200 OK taken from RFCs. o (C11) Size of an average presence document. In the previous version of this document we have used only the size of 3000 bytes for a presence document. This number was calculated based on examples of rich presence document in RFCs. Due to discussion in the SIMPLE list where it was claimed that it may be too big and due to the fact that we are talking here about federation between communities where the rich presence document may be of less use, we have done all the calculations with two sizes of presence document. One size is the minimal size of the PIDF [4] document which was taken to be 350 bytes based on examples from RFCs and the other size is the 3000 bytes for rich presence document [5]. It should be noted that assuming 3000 bytes for presence document is relatively modest if we take into account multiple devices and location information. o (C12) The size of NOTIFY when partial [12] notification is being done. We have taken this size to be 200 bytes. The size is much smaller then the example that is given in [12] but the example given there assumes multiple changes in the presence document and here we assume a single change. Houri, et al. Expires April 25, 2009 [Page 9] Internet-Draft Presence Scaling Analysis October 2008 When dialog optimization [9] 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 o (C13) Item size per each contact in RLMI document, 160 bytes. o (C14) The size of the multipart boundary in RLMI notifications, 144 bytes. o (C15) The size of the XML root node in RLMI document (once per notification), 144 bytes. 2.3.2. Initial Messages The following are the calculations for the messages in the initial phase of the establishment of the subscriptions. The calculations contain both number of messages and the number of bytes. o (I01) Number of initial SUBSCRIBE messages per watcher = C05. o (I02) Number of initial 200 OK messages for SUBSCRIBE messages per watcher = C05. o (I03) Number of initial NOTIFY messages per watcher = C05. o (I04) Number of initial 200 OK messages for NOTIFY messages per watcher = C05. o (I05) Total number and bytes of initial SUBSCRIBE messages for all watchers = Number - I01*C06, Bytes - I01*C06*C07. o (I06) Total number and bytes of initial 200 OK for SUBSCRIBE messages for all watchers = Number - I01*C06, Bytes - I01*C06*C08. o (I07) Total number and bytes of initial NOTIFY messages for all watchers = Number - I01*C06, The calculation for the number of bytes is different when dialog optimization is used or not. When dialog optimization is not applied the number of bytes will be calculated by: (I01*C06*C09)+(I01*C06*C11) and when dialog optimization is applied the number of bytes will be calculated by (I01*C06*(C09+C14+C15))+(I01*C06*C04*(C11+C13+C14)). o (I08) Total number and bytes of initial 200 OK for NOTIFY messages for all watchers = Number - I04*C06, Bytes - I04*C06*C10. o (I09) Total number and bytes of initial messages per day = Number - numbers in I05+I06+I07+I08, Size -sizes in I05+I06+I07+I08. 2.3.3. Steady State Messages 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 Houri, et al. Expires April 25, 2009 [Page 10] Internet-Draft Presence Scaling Analysis October 2008 change and the subscription refreshes. o (S01) NOTIFY messages due to state change per watched presentity per day (less 2 since the NOTIFY for initial and terminating state is calculated in the initial and terminating calculations) = (C02*C01-2). o (S02) 200 (for NOTIFY due to state change) messages per watched presentity per day (less 2 since the NOTIFY for initial and terminating state is calculated in the initial and terminating calculations) = (C02*C01-2). o (S03) Total number and size of messages due to state change per day = Number - (S01+S02)*C06*C04. The calculation for the number of bytes is different when dialog optimization is used or not. When dialog optimization is not applied the number of bytes will be calculated by: (C06*C04)*((S01*(C09+C11))+(S02*C10)) and when dialog optimization is applied the number of bytes will be calculated by (C06*C04)*((S01*(C09+C11+C13+C14+C15+C14))+ (S02*C10)). This includes the the multipart boundary of the resource list. Note that for dialog optimization it is assumed that only a single presentity is changed and partial state notification is used. o (S04) Number of SUBSCRIBE messages for refreshes per watcher per day = ((C01/C03)-1)*C05. One is subtracted since the termination is calculated separately. for example if there are 8 hours in the day and a refresh should occur every hour, there are 7 refreshes during the day and not 8. o (S05) Number of 200 OK messages for SUBSCRIBE messages for refreshes per watcher per day = ((C01/C03)-1)*C05. o (S06) Number of NOTIFY messages for refreshes per watcher per day = ((C01/C03)-1)*C05. Since when NOTIFY optimization is used [17] there is no need to send NOTIFY for refreshes, S06 will be zero when NOTIFY optimizations is used. o (S07) Number of 200 OK messages for NOTIFY messages for refreshes per watcher per day = ((C01/C03)-1)*C05. Since when NOTIFY optimization is used [17] there is no need to send NOTIFY for refreshes, S07 will be zero when NOTIFY optimizations is used. o (S08) Total number and size of messages due to SUBSCRIBE refreshes per day = Number - (S04+S05+S06+S07)*C06. The number of bytes is calculated by adding the SUBSCIRBE bytes (S04*C06*C07), the OK for SUBSCRIBE bytes (S05*C06*C08), the NOTIFY bytes C06*(S06*(C09+ C11)) and the OK for NOTIFY (S07*C06*C10). Note that the formula for the notify bytes is for the dialog optimization is not used and when it used the formula will be: C06*(S06*((C09+C14+C15)+ (C04*(C11+C13+C14)))). Note that a full state should be given in SUBSCRIBE refreshes in resource lists. See section 5.2 in [9]. The fact that the full state needs to be returned in a NOTIFY response to refresh makes the NOTIFY optimization more efficient in conjunction with the dialog optimization. Houri, et al. Expires April 25, 2009 [Page 11] Internet-Draft Presence Scaling Analysis October 2008 o (S09) Total number and bytes of steady messages per day = Number - numbers in S03+S08, Bytes - sizes in S03+S08. 2.3.4. Termination Messages The following are the calculations for the messages in the termination phase of the of the subscriptions. The calculations contain both number of messages and the number of bytes. o (T01) Number of terminating SUBSCRIBE messages per watcher = C05. o (T02) Number of terminating 200 OK messages for SUBSCRIBE messages per watcher = C05. o (T03) Number of terminating NOTIFY messages per watcher = C05. Since when NOTIFY optimization is used [17] there is no need to send NOTIFY for terminations, T03 will be zero when NOTIFY optimization is used. o (T04) Number of terminating 200 OK messages for NOTIFY messages per watcher = C05. Since when NOTIFY optimization is used [17] there is no need to send NOTIFY for terminations, T04 will be zero when NOTIFY optimization is used. o (T05) Total number and bytes of terminating SUBSCRIBE messages for all watchers = Number - T01*C06, Bytes - T01*C06*C07. o (T06) Total number and bytes of terminating 200 OK for SUBSCRIBE messages for all watchers = Number - T01*C06, Bytes - T01*C06*C08. o (T07) Total number and bytes of terminating NOTIFY messages for all watchers = Number - T01*C06, The number of bytes is calculated to be: (T03*C06*(C09+C11) when dialog optimization is not used and: (T03*C06*(C09+C14+C15))+(T03*C06*C04*(C11+C13+C14)) when dialog optimization is used. Note that a full state should be given in SUBSCRIBE refreshes in resource lists. See section 5.2 in [9]. o (T08) Total number and bytes of terminating 200 OK for NOTIFY messages for all watchers = Number - T04*C06, Bytes - T04*C06*C10. o (T09) Total number and bytes of terminating messages per day = Number - numbers in T05+T06+T07+T08, Size -sizes in T05+T06+T07+ T08. 2.3.5. Bottom Line The following are the calculations of several totals that are based on the above calculations. o (B01) Total number of messages and bytes during the day = Messages - Number of messages in I09+S09+T09, Bytes - Number of bytes in I09+S09+T09. o (B02) Total number of messages and bytes per second = Messages - Number of messages in B01/(C01*3600) Bytes - Number of bytes in B01/(C01*3600). Houri, et al. Expires April 25, 2009 [Page 12] Internet-Draft Presence Scaling Analysis October 2008 o (B02) Total number of message and bytes per user per day = Messages - number of messages in B01/C06 Bytes - Number of bytes in B01/C06. 2.3.6. Rush Hour Calculations With 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. 2.4. No optimizations used 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 SIP 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 [4] document size but the bottom line calculation is also given for a presence document size for rich presence [5] 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 Houri, et al. Expires April 25, 2009 [Page 13] Internet-Draft Presence Scaling Analysis October 2008 (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 Houri, et al. Expires April 25, 2009 [Page 14] Internet-Draft Presence Scaling Analysis October 2008 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: No optimizations used 2.5. Dialog optimization used 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 Houri, et al. Expires April 25, 2009 [Page 15] Internet-Draft Presence Scaling Analysis October 2008 ** 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....................136,160,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....................183,760,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..................6,378,240,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,286,320,000 (S09) Total number & bytes of steady messages per day Number of msgs for all watchers.............8,160,000 Bytes for all watchers..................7,664,560,000 ** Termination Messages (T01) Terminating SUBSCRIBE msgs per watcher..................1 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1 (T03) Terminating NOTIFY msgs per watcher.....................1 Houri, et al. Expires April 25, 2009 [Page 16] Internet-Draft Presence Scaling Analysis October 2008 (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....................136,160,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....................183,760,000 ** Bottom Line (B01) Total of messages between domains...............8,480,000 Total of bytes between domains (PD=350).....8,032,080,000 Total of bytes between domains (PD=3000)...21,176,080,000 (B02) Total number of messages / second.....................294 Total of bytes per second (PD=350)................278,892 Total of bytes per second (PD=3000)...............735,281 (B03) Total number of by msgs per user/day..................212 Total number of bytes per user/day (PD=350).......200,802 Total number of bytes per user/day (PD=3000)......529,042 Figure 2: Dialog optimization used 2.6. NOTIFY optimization used The initial analysis of analysis provided in Figure 1 is repeated here with the assumption that the notify optimization is applied. The optimization saves the need for NOTIFY upon refreshing a SUBSCRIBE if there was no change since the last NOTIFY. It is assumed here that there will be no NOTIFY message for a SUBSCRIBE refreshes 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 Houri, et al. Expires April 25, 2009 [Page 17] Internet-Draft Presence Scaling Analysis October 2008 (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 Houri, et al. Expires April 25, 2009 [Page 18] Internet-Draft Presence Scaling Analysis October 2008 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: NOTIFY optimization used 2.7. Dialog & NOTIFY optimizations used 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 Houri, et al. Expires April 25, 2009 [Page 19] Internet-Draft Presence Scaling Analysis October 2008 (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....................136,160,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....................183,760,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..................6,378,240,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 Houri, et al. Expires April 25, 2009 [Page 20] Internet-Draft Presence Scaling Analysis October 2008 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,607,840,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,824,400,000 Total of bytes between domains (PD=3000)...16,576,400,000 (B02) Total number of messages / second.....................272 Total of bytes per second (PD=350)................236,958 Total of bytes per second (PD=3000)...............575,569 (B03) Total number of by msgs per user/day..................196 Total number of bytes per user/day (PD=350).......170,610 Total number of bytes per user/day (PD=3000)......414,410 Figure 4: Dialog & NOTIFY optimizations used 2.8. Presence Federation Scenarios While scalability issues exist in any large deployment, certain characteristics make the deployment conducive to the existing optimizations, and others have characteristics that do not. Following is a list of federation scenarios that have varying usage characteristics. For each, a message rate and bandwidth table is provided reflecting typical changes message rates. Those Houri, et al. Expires April 25, 2009 [Page 21] Internet-Draft Presence Scaling Analysis October 2008 characteristics can alter the overall effectiveness of existing optimizations. Note that the number of users used is not the number of the users in the domains but the actual logged in users. As was mentioned before not all the domain users will use the presence service at the same time. The number used for number of watchers and number of watched presentities are for online users. 2.8.1. Widely distributed inter-domain presence In some environments presence federation may be very common, perhaps even more common than intra-domain presence. An example of this type of environment is a small ISV or public server. Users in that small ISV are not likely to subscribe to the presence of other users in the their server since they do not necessarily have any relationship with each other aside from receiving service from the same provider. They are much more likely to be subscribed to the presence of users in one of the federated domains (whether in consumer domains, academic, other ISVs, etc). Common characteristics of this deployment are: o Federated subscriptions are the majority of subscription traffic o Individual users are likely to subscribe to multiple users in any one domain o The intersection of users in the deployment watching the same presentities is quite small (i.e., probability that watchers in the domain subscribe to the same presentity is low) To account for the extraordinarily high percentage of federation traffic, the number of federated presentities is increased to 20. The number of watchers in the domain could also be adjusted to account for an expected larger community of users being peered with, it is omitted here for simplification The first table below provides the calculations without optimizations the second table provides the calculations with optimization. ** 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 Houri, et al. Expires April 25, 2009 [Page 22] Internet-Draft Presence Scaling Analysis October 2008 (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 Houri, et al. Expires April 25, 2009 [Page 23] Internet-Draft Presence Scaling Analysis October 2008 (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).....,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 Houri, et al. Expires April 25, 2009 [Page 24] Internet-Draft Presence Scaling Analysis October 2008 ** 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....................554,720,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....................602,320,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.................31,891,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.......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.................32,120,800,000 ** Termination Messages (T01) Terminating SUBSCRIBE msgs per watcher..................1 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1 (T03) Terminating NOTIFY msgs per watcher.....................0 Houri, et al. Expires April 25, 2009 [Page 25] Internet-Draft Presence Scaling Analysis October 2008 (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)....32,755,920,000 Total of bytes between domains (PD=3000)...81,515,920,000 (B02) Total number of messages / second...................1,250 Total of bytes per second (PD=350)..............1,137,358 Total of bytes per second (PD=3000).............2,830,414 (B03) Total number of by msgs per user/day..................900 Total number of bytes per user/day (PD=350).......818,898 Total number of bytes per user/day (PD=3000)....2,037,898 Figure 6: Widely distributed inter-domain with optimizations 2.8.2. Associated inter-domain presence In this type of environment, the domain is a collection of associated users such as an enterprise. Here, federation is once again very common. However, there is also a strong association between some users in the deployment. These associations make it somewhat more likely that users in that domain will be watchers of the same presentity. This can occur because of business relationships (e.g. two co-workers on a project federating with a partner company). Common characteristics of this deployment are: o Federated subscriptions are large minority or small majority of subscription traffic o Individual users are likely to subscribe to multiple users in any one domain, especially their own Houri, et al. Expires April 25, 2009 [Page 26] Internet-Draft Presence Scaling Analysis October 2008 o The intersection of users in the deployment watching the same presentities increases This federation type has traffic rates similar to the previous examples but with different levels of association of the users. 2.8.3. Very large network peering In this environment, two or more very large networks create a peering relationship allowing their users to subscribe to presence in the other domains. Where as the number of users in other deployment types ranges from hundreds to several hundred thousand, these large networks host up to hundreds of millions of users. Examples of these networks are large wireless carriers and consumer IM networks. Common characteristics of this deployment are: o As users become accustomed to network boundaries disappearing, federated subscriptions become as common as subscriptions within the same domain o Individual users are highly likely to want to see presence of multiple presentities in the peer network o The intersection of users in the deployment watching the same presentities is very high (i.e., two or more users in network A are extremely likely to be watching a same user in network B) o Status changes increase greatly due to typical observed consumer behavior The first table below provides the calculations without optimizations the second table provides the calculations with optimizations. Even though the optimizations help a lot (almost cut the number of messages by half), the numbers are still very high. Note also that the bandwidth required is very high. ** 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 Houri, et al. Expires April 25, 2009 [Page 27] Internet-Draft Presence Scaling Analysis October 2008 (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 Houri, et al. Expires April 25, 2009 [Page 28] Internet-Draft Presence Scaling Analysis October 2008 (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 Houri, et al. Expires April 25, 2009 [Page 29] Internet-Draft Presence Scaling Analysis October 2008 (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................146,560,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................170,360,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.............16,670,400,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.............16,785,200,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 Houri, et al. Expires April 25, 2009 [Page 30] Internet-Draft Presence Scaling Analysis October 2008 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)...16,971,960,000,000 Total of bytes bet. domains (PD=3000)..41,881,960,000,000 (B02) Total number of messages / second.................652,778 Total of bytes per second (PD=350)............589,304,167 Total of bytes per second (PD=3000).........1,454,234,722 (B03) Total number of by msgs per user/day..................940 Total number of bytes per user/day (PD=350).......848,598 Total number of bytes per user/day (PD=3000)....2,094,098 Figure 8: Very large network peering with optimizations 2.8.4. Intra-domain peering Within a particular domain, multiple presence infrastructures are deployed with users split between the two. This scenario is unique in that federated messages do not pass outside the administrative domain's network. The two infrastructures peer directly inside the domain. A common example of this is an enterprise IT system with multiple independent vendor presence solutions deployed (e.g., a presence solution for desktop messaging deployed alongside a presence solution for IP telephony). Common characteristics of this deployment are o The difference between subscriptions to presentities in one system vs. the other are completely arbitrary. Any one presentity is as likely to be homed on one infrastructure as the other. o Active users are almost guaranteed of subscribing to many users in the peer infrastructure. Houri, et al. Expires April 25, 2009 [Page 31] Internet-Draft Presence Scaling Analysis October 2008 o The level of intersection of presentities is extremely high. The first table below provides the calculations without optimizations the second table provides the calculations with optimization. Even though the relatively conservative numbers are used, the amount of messages is still very high even though optimization may cut the traffic by more then half ** Constants (C01) Subscription lifetime (hours)...........................8 (C02) Presence state changes / hour...........................3 (C03) Subscription refresh interval / hour....................1 (C04) Total federated presentities per watcher...............10 (C05) Number of dialogs to maintain per watcher..............10 (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 Houri, et al. Expires April 25, 2009 [Page 32] Internet-Draft Presence Scaling Analysis October 2008 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 Houri, et al. Expires April 25, 2009 [Page 33] Internet-Draft Presence Scaling Analysis October 2008 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....................879,360,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,022,160,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.................47,836,800,000 Houri, et al. Expires April 25, 2009 [Page 34] Internet-Draft Presence Scaling Analysis October 2008 (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.................48,525,600,000 ** Termination Messages (T01) Terminating SUBSCRIBE msgs per watcher..................1 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1 (T03) Terminating NOTIFY msgs per watcher.....................1 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............1 (T05) Total number & bytes of Terminating SUBSCRIBE msgs Number of msgs for all watchers...............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)....49,646,160,000 Total of bytes between domains (PD=3000)..122,796,160,000 (B02) Total number of messages / second...................1,917 Total of bytes per second (PD=350)..............1,723,825 Total of bytes per second (PD=3000).............4,263,408 (B03) Total number of by msgs per user/day..................460 Total number of bytes per user/day (PD=350).......413,718 Total number of bytes per user/day (PD=3000)....1,023,218 Figure 10: Intra-domain peering with optimizations Houri, et al. Expires April 25, 2009 [Page 35] Internet-Draft Presence Scaling Analysis October 2008 2.9. Partial Notifications Optimization Draft [12] 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 Houri, et al. Expires April 25, 2009 [Page 36] Internet-Draft Presence Scaling Analysis October 2008 (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 Houri, et al. Expires April 25, 2009 [Page 37] Internet-Draft Presence Scaling Analysis October 2008 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 2.10. Very Optimized SIP SIP is network agnostic protocol, therefore, the protocol carries additional messages like 200 OK that would have been redundant in a protocol that is TCP based only. The following calculation assumes an imaginary TCP only based version of SIP that optimizes the following: o There is no 200 OK for each message. Since only TCP has to be supported, there is not need to compensate for network issues. o There is no refresh for subscriptions. o There is no NOTIFY upon termination of SUBSCRIPTION o The size of each message is smaller since there is no need for the various headers that SIP uses for routing etc. So we need to assume smaller message sizes while we will keep the size of the presence document the same. As notes above the calculations in this document do not assume offline means of getting parts of the presence information. Therefore, in addition to the above optimizations, the other optimizations that were assumed in the document will be assumed here also. These includes partial notifications and the dialog optimizations. The NOTIFY optimization is not relevant here since there are no refreshes of subscriptions. The following is a calculation for the very large networks peering scenario assuming the imaginary TCP only SIP. It is very interesting to note that the dialog optimization does not reduce the number of bytes when partial notification optimization is applied (on the contrary) due to the RLMI overhead. ** 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...............1 (C06) Total number of watchers in domains............20,000,000 Houri, et al. Expires April 25, 2009 [Page 38] Internet-Draft Presence Scaling Analysis October 2008 (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 (C12) Size of an average partial presence document..........200 ** Initial Messages (I01) Initial SUBSCRIBE msgs per watcher......................1 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............0 (I03) Initial NOTIFY msgs per watcher.........................1 (I04) Initial 200 OK msgs (NOTIFY) per watcher................0 (I05) Total number & bytes of initial SUBSCRIBE msgs Number of msgs for all watchers............20,000,000 Bytes for all watchers..................3,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............20,000,000 Bytes for all watchers................136,680,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............40,000,000 Bytes for all watchers................139,680,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..............8,666,400,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 Houri, et al. Expires April 25, 2009 [Page 39] Internet-Draft Presence Scaling Analysis October 2008 Number of msgs for all watchers.........9,200,000,000 Bytes for all watchers..............8,666,400,000,000 ** Termination Messages (T01) Terminating SUBSCRIBE msgs per watcher..................1 (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............20,000,000 Bytes for all watchers..................3,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............20,000,000 Bytes for all watchers..................3,000,000,000 ** Bottom Line (B01) Total of messages between domains...........9,260,000,000 Total of bytes between domains (PD=350).8,809,080,000,000 Total of bytes bet. domains (PD=3000)...9,339,080,000,000 (B02) Total number of messages / second.................321,528 Total of bytes per second (PD=350)............305,870,833 Total of bytes per second (PD=3000)...........324,273,611 (B03) Total number of by msgs per user/day..................463 Total number of bytes per user/day (PD=350).......440,454 Total number of bytes per user/day (PD=3000)......466,954 Figure 12: Very large networks peering, TCP only SIP+Partial+Dialog optimizations ** 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 Houri, et al. Expires April 25, 2009 [Page 40] Internet-Draft Presence Scaling Analysis October 2008 (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 (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.............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..............3,220,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,000,000 Bytes for all watchers..............3,220,000,000,000 Houri, et al. Expires April 25, 2009 [Page 41] Internet-Draft Presence Scaling Analysis October 2008 ** 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=350).3,380,000,000,000 Total of bytes bet. domains (PD=3000)...3,910,280,000,000 (B02) Total number of messages / second.................340,278 Total of bytes per second (PD=350)............117,361,111 Total of bytes per second (PD=3000)...........135,763,889 (B03) Total number of by msgs per user/day..................490 Total number of bytes per user/day (PD=350).......169,000 Total number of bytes per user/day (PD=3000)......195,500 Figure 13: Very large networks peering, TCP only SIP+Partial optimizations 3. State Management In previous sections we have discussed the big amount of messages that need to be sent to/from a presence server In this section the state that needs to be maintained by a presence server will be analyzed and shown to be far from trivial. The presence server has two parallel tasks. Houri, et al. Expires April 25, 2009 [Page 42] Internet-Draft Presence Scaling Analysis October 2008 1. Maintain the state of the presentities to which watchers subscribe. 2. Maintain the state of the subscriptions of watchers and provide timely updates to the watchers. For a single subscription from a single watcher on a presentity, the presence server has to maintain the following state: o Subscription state including all the parameters that are needed in order to maintain the subscription as timers. o Optional filtering information that was requested by the watcher. This includes enough information that is needed for doing the filtering. In addition additional information has to be maintained if partial notification is being supported for the subscription o Optional rate management information as throttling o Watcher information [2], [3] that is the result of the subscription in order to enable watched presentities to see who is watching them. For each presentity that has been subscribed to in the presence server, the presence server has to maintain the following state: o A list of the subscriptions for the presentity. Note that this is already taken care of from the size calculation point of view by the subscription state above. o Authorization information for the presentity. For each presentity for which there was any publication and the presentity has a state other then a default value, the presence server has to maintain the current value of the presentity. 3.1. State Size Calculations Lets assume the following sizes: o Subscription size - 2K bytes. This includes watcher information that need to be created by the presence server for each subscription. This is for each subscription that is done by each watcher to each presentity that the watcher is watching. So if we have 10K watchers we should have 10K of these. o Subscribed to resource - 1K bytes (for privacy information and other management info). This is for each presentity that is being watched. No matter how many watchers are watching it. The subscriptions themselves are already calculated in the previous bullet. Houri, et al. Expires April 25, 2009 [Page 43] Internet-Draft Presence Scaling Analysis October 2008 o Resource with a state - 6K bytes. This is a moderate assumption if we take into account the amount of data that is being put in a presence document as multiple devices, calendar and geographical information. This is for each presentity that has state other then the default empty state. It does not matter if it is being watched or not. 3.1.1. Tiny System o 10K subscriptions = 19M bytes. o 5K subscribed to presentities = 5M bytes. o 10K presentities with state = 58M bytes. Total is 82M bytes. 3.1.2. Medium System o 100K subscriptions = 195M bytes. o 50K subscribed to presentities = 49M bytes. o 100K presentities with state = 586M bytes. Total is 830M bytes. 3.1.3. Large System o 6M subscriptions = 11,718M bytes. o 3M subscribed to presentities = 2,929M bytes. o 4M presentities with state = 23437M bytes. Total is 38G bytes. 3.1.4. Very Large System o 150M subscriptions = 292,969M bytes. o 75M subscribed to presentities = 73,242M bytes. o 100M presentities with state = 585,937M bytes. Total is 952G bytes which is a very big number for a very dynamic storage as needed by the presence server. Although the numbers above may seem moderate enough for the sizes that the presence server is handling we should consider the following: o Dynamic state - Although the state may seem not so big for databases even for the very large system, we need to remember that this state is a very dynamic state. Subscriptions come and go all the time, the status of presentities is being updated and so Houri, et al. Expires April 25, 2009 [Page 44] Internet-Draft Presence Scaling Analysis October 2008 forth. This means that the presence server has to manage its state in a medium that is very dynamic and for such large sizes this task is not trivial. o Interlinked state - The subscriptions and the subscribed to presentities are dependent on each other. There needs to be a link from the presentity to the subscriptions and vice versa. See Section 4.5 about the interlinkage that is created due to resource lists. o Moderate assumptions - The size assumptions that were made above are quite moderate. As presence is becoming more a core middleware functionality that holds a lot of data on the user. In real-life the numbers above may be even higher and the presence server can have additional overhead as managing the SIP sessions, networking and more. Although the calculations above do not show that there is a real issue with state management of presence in medium systems or even in big systems since it should be possible to divide the state between different machines, the state size is still very big. A bigger issue with the state is more when resource lists are involved and create an interlinked state between many servers. In that case the division of very big state to multiple servers becomes less trivial... 4. Processing complexities The basic presence paradigm consists from a watcher and a presentity to which the watcher watches. It sounds simple enough but there are many additions and extensions that the presence server has to manage that make the processing of the presence server very complex. In this section we show that in addition to the large amount of messages and the big state that the presence server has to handle, it has also to handle quite intensive processing for aggregation, partial notify and publish, filtering and privacy. This adds another complexity to the presence server in the CPU front in addition to the network and memory fronts that were described before. 4.1. Aggregation A presence document may contain multiple resources. These resources can be devices of the presentity, information that is received form external providers of presence information for the presentity as geographical and calendar information and more. The presence server needs to be able to get the updates from all the resources and aggregate them correctly into a single presence document. Although this is just "XML processing" task, the amount of Houri, et al. Expires April 25, 2009 [Page 45] Internet-Draft Presence Scaling Analysis October 2008 updates that the presence server may get, the need to keep the presence document aligned with its schema and the need to notify the users as soon as possible create a significant processing burden on the presence server 4.2. Partial Publish and Notify Drafts [12], [13] 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 [12] specifies a versioning mechanism that enables the watcher to get the updates based on the previous state that it has seen. This versioning mechanism has to be maintained by the presence server for each watcher that is subscribed to a presentity and requires partial notify. 4.3. Filtering Filtering as defined in RFCs [7], [8] 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. 4.4. Authorization Draft [14] 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. Houri, et al. Expires April 25, 2009 [Page 46] Internet-Draft Presence Scaling Analysis October 2008 4.5. Resource List Service RFC [9] defines a way to subscribe on a single URI while that URI is actually a list of resources that are being subscribed to by a single subscription. Although this is quite useful mechanism and it significantly saves on the number of sessions between the watcher and the presence server (as we show in the calculations of messages), this feature has the potential to make the scalability issue of presence systems harder and more complex. The reasons that resource lists may make the scalability problem of the presence server even more complex are: o Subscriptions and state - The resource list may contain reference to many other presence servers in many other domains. This requires the RLS to create subscriptions to other presence servers and buffer the state of all presentities in order to be able to provide the full state of the presentities in the list when needed. So in the overall system, the subscriptions that were saved between the watcher and the presence server are moved to the backend system while state has been duplicated between the various presence servers that serve the various presentities and the RLSs. This issue could have been mitigated if there was a way for the RLS to retrieve the presence information for many watchers while adhering to privacy when sending the actual notifications to the watchers. o Interlinkage - The resource list subscription will reach one RLS that will open it and send it to many presence servers and to other RLSs (if there is a subgroup inside the list). This way a complex linkage between the state of many components is created. This linkage makes state management and other maintenance of a presence systems quite complex. o Big lists are easy - There are two types of groups that may be used with this feature, private groups that are defined by/for each watcher and public groups that are defined in the system and can be used by any watcher. Although we should expect IT administrators to take caution when creating public groups, this may be not the case in real life. The connection between the size of the public group and the load on the presence server system may not apparent to everyone. Furthermore many public groups that are used in presence systems may have been created for other purposes as email systems (where the size of the lists was not so important) and are taken as they are to presence systems. So for example we may very easily find that a public group that actually covers all the users in the enterprise are used by many users in the enterprise thus creating unbearable load on the presence server. Note that this issue is not a protocol or design issue but more a usage issue that may have a real impact on the presence Houri, et al. Expires April 25, 2009 [Page 47] Internet-Draft Presence Scaling Analysis October 2008 system. o Stopping notifications - A watcher may accidentally subscribe to a very big list and be overwhelmed by the amount of notifies that it receives from the presence server. There is no current way to stop this stream of notifies and even canceling the subscription may take time until being affective. The issues mentioned above are one example of an optimization that helps in one part of the system but creates even bigger problems in the overall system. There is a need to think about the problems listed above but more then that there is a need to make sure that when an optimization is introduced it does not create issues in other places. 5. Current Optimizations This section lists and discusses several optimizations that are either already part of the SIP protocol or they have been suggested in various drafts. Several other optimizations that have been suggested but have not been discussed in any working group yet are summarized in [19] and in [21]. Note that trials with batched notifies optimization that is describes in [19], showed an improvement of 117% in the whole throughput of presence traffic. o Subnot-etags - Draft [17]. This draft suggests ways to suppress the sending of unnecessary notifies when for example a subscription is refreshed. This suggestion seems to be an efficient optimization since it saves both the number of messages sent and on the processing time of the presence server. o Resource List Service - [9] enable creating a single subscription session between the watcher and the presence server for subscribing on a list of users. This saves the amount of sessions that are created between watchers and presence servers. On the other hand, this mechanism enables creating very large amount of subscriptions in the presence server/RLS system thus enabling the creation of a very large number of subscriptions between presence servers and RLSs with relatively few clients especially if large public groups are used. It seems that in order to really optimize in this area, the usage of large public groups should not be considered as BCP and there should be a way for an RLS to create a single subscription for multiple occurrences of the same resource in resource lists. See consolidates subscriptions below. o Partial notify/publish - Drafts [12], [13] define a way for the subscriber to request getting only what was changed in the presence document and for the publisher of presence information to publish only what was changed in the presence document since the last publish. Although these optimizations help in reducing the Houri, et al. Expires April 25, 2009 [Page 48] Internet-Draft Presence Scaling Analysis October 2008 amount of actual data that is sent from/to the presence server, these optimizations create additional processing burden on the presence server as was discussed above. o Filtering as defined in RFCs [7], [8] enables a watcher to request to be notified only when the presence document fulfills certain conditions. Although this optimization enables saving on the amount of messages that are sent from the presence server to the watcher, this optimization puts more burden on the processing time of the presence server as was discussed above. o Throttling [20] defines a mechanism in which a watcher requires to be updated only in certain intervals. Although this mechanism may give some extra load on the processing time of the presence server, that load is negligible and the reduction on the amount of messages sent from the presence server to the watchers is significant. This optimization is even more important with resource lists where there can be many resources in the resource lists and if the traffic of updates on resource list is not regulated, the watcher may get very large amount of notifications. o Presence specific sigcomp dictionary [15] defines a SIGCOMP [1] dictionary for presence. This optimization will enable to reduce the number of bytes that are transferred in presence systems by compressing the textual SIP messages and using the specialized presence dictionary the compression may be more significant then just using SIGCOMP as is. Note that number of actual messages will remain the same and a calculation of the amount of bytes that will be saved may be useful here. o Content Indirection [6] enables sending only the URI of the presence document to the watcher thus offloading the presence server from sending the presence document to the watcher. This optimization may be useful in some cases especially where there is a big number of users that get the same presence document. 6. Summary 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. Houri, et al. Expires April 25, 2009 [Page 49] Internet-Draft Presence Scaling Analysis October 2008 (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 14: 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).....8,032,080,000 Total of bytes between domains (PD=3000)...21,176,080,000 (B02) Total number of messages / second.....................294 Total of bytes per second (PD=350)................278,892 Total of bytes per second (PD=3000)...............735,281 (B03) Total number of by msgs per user/day..................212 Total number of bytes per user/day (PD=350).......200,802 Total number of bytes per user/day (PD=3000)......529,042 Houri, et al. Expires April 25, 2009 [Page 50] Internet-Draft Presence Scaling Analysis October 2008 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,824,400,000 Total of bytes between domains (PD=3000)...16,576,400,000 (B02) Total number of messages / second.....................272 Total of bytes per second (PD=350)................236,958 Total of bytes per second (PD=3000)...............575,569 (B03) Total number of by msgs per user/day..................196 Total number of bytes per user/day (PD=350).......170,610 Total number of bytes per user/day (PD=3000)......414,410 Figure 15: Basic use case The following table summarizes the results of various optimization factors for the widely distributed inter domain use case. Houri, et al. Expires April 25, 2009 [Page 51] Internet-Draft Presence Scaling Analysis October 2008 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).....,547,000 Dialog and notify optimizations are applied (B01) Total of messages between domains..............36,000,000 Total of bytes between domains (PD=350)....32,755,920,000 Total of bytes between domains (PD=3000)...81,515,920,000 (B02) Total number of messages / second...................1,250 Total of bytes per second (PD=350)..............1,137,358 Total of bytes per second (PD=3000).............2,830,414 (B03) Total number of by msgs per user/day..................900 Total number of bytes per user/day (PD=350).......818,898 Total number of bytes per user/day (PD=3000)....2,037,898 Figure 16: Widely distributed inter-domain The following table summarizes the results of various optimization factors for the intra-domain peering use case. Houri, et al. Expires April 25, 2009 [Page 52] Internet-Draft Presence Scaling Analysis October 2008 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)....49,646,160,000 Total of bytes between domains (PD=3000)..122,796,160,000 (B02) Total number of messages / second...................1,917 Total of bytes per second (PD=350)..............1,723,825 Total of bytes per second (PD=3000).............4,263,408 (B03) Total number of by msgs per user/day..................460 Total number of bytes per user/day (PD=350).......413,718 Total number of bytes per user/day (PD=3000)....1,023,218 Figure 17: 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 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 Houri, et al. Expires April 25, 2009 [Page 53] Internet-Draft Presence Scaling Analysis October 2008 Dialog and notify optimizations are applied (B01) Total of messages between domains..........18,800,000,000 Total of bytes bet. domains (PD=350)...16,971,960,000,000 Total of bytes bet. domains (PD=3000)..41,881,960,000,000 (B02) Total number of messages / second.................652,778 Total of bytes per second (PD=350)............589,304,167 Total of bytes per second (PD=3000).........1,454,234,722 (B03) Total number of by msgs per user/day..................940 Total number of bytes per user/day (PD=350).......848,598 Total number of bytes per user/day (PD=3000)....2,094,098 Partial and notify optimizations are applied (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 TCP only SIP+Partial+Dialog optimizations (B01) Total of messages between domains...........9,260,000,000 Total of bytes between domains (PD=350).8,809,080,000,000 Total of bytes bet. domains (PD=3000)...9,339,080,000,000 (B02) Total number of messages / second.................321,528 Total of bytes per second (PD=350)............305,870,833 Total of bytes per second (PD=3000)...........324,273,611 (B03) Total number of by msgs per user/day..................463 Total number of bytes per user/day (PD=350).......440,454 Total number of bytes per user/day (PD=3000)......466,954 TCP only SIP+Partial optimizations (B01) Total of messages between domains...........9,800,000,000 Total of bytes between domains (PD=350).3,380,000,000,000 Total of bytes bet. domains (PD=3000)...3,910,280,000,000 (B02) Total number of messages / second.................340,278 Total of bytes per second (PD=350)............117,361,111 Total of bytes per second (PD=3000)...........135,763,889 (B03) Total number of by msgs per user/day..................490 Total number of bytes per user/day (PD=350).......169,000 Total number of bytes per user/day (PD=3000)......195,500 Houri, et al. Expires April 25, 2009 [Page 54] Internet-Draft Presence Scaling Analysis October 2008 Figure 18: Very large scale peering networks 7. Conclusions The following conclusions can be drawn from the above numbers: o Due to the overhead of RLMI, the dialog optimization does not help in reducing the number of bytes nor in the number of the messages. It seems to be more important from the point of view of the convenience of the user since it enables the user to manage his/ hers watch list on e.g. a web page. o The notify optimization optimizes both the number of messages and the number of bytes. o Partial notification saves a lot in the number of bytes especially when the presence document is a rich presence document which is relatively big. o Comparing to very optimized SIP protocol (imaginary TCP only SIP) shows that the number of messages is less by about a half. The number of bytes is also reduced by about a half. o When looking at the numbers from the perspective of the number of bytes that a user "consumes" per day the numbers may not look so big. Nevertheless, we should remember that the overall affect on the network may be quite big since the network will have to convey dozens of Giga bytes per day for the modest use cases that are described in this document for presence traffic only. Recalling that presence is only an enabler for other media these numbers are not so easy to handle. 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 Houri, et al. Expires April 25, 2009 [Page 55] Internet-Draft Presence Scaling Analysis October 2008 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: [19], [21] and [22] 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 [10], [11]protocol for the notifies. 8. Security Considerations This document discusses scalability issues with the existing SIP/ SIMPLE presence protocol and model. Therefore, there are no security considerations to be considered for this document. However, a lot of Houri, et al. Expires April 25, 2009 [Page 56] Internet-Draft Presence Scaling Analysis October 2008 the possible optimizations that should emerge as a result of this document will have security implications that will need to be solved. 9. IANA Considerations This document has no actions for IANA. 10. Changes from Previous Versions 10.1. Changes in version 05 o Fixed mistakes in calculations that were found by Victoria Beltran-Martinez, both relate to dialog optimizations. One mistake was not including the multipart boundary of the resource list itself in S03 when dialog optimizations were used. The other one was assuming in T07 that only a single presentity is returned in termination in T07 calculation. o Fixed nits that were referred to me by Robert Sparks 10.2. Changes in version 04 o Fixed mistake in the formula of I07 and S08 (RLMI was not included). Affect on total number of bytes was very small. o Fixed mistake in the text of the calculation of number of bytes for S08 for non dialog optimization. No actual change in number of bytes since the excel file calculations were done correctly. o Removed general references throughout the text to "other protocols". This was done in order to avoid the impression that the document tries to compare SIP protocol with any other presence base protocol. o Several other editorial and clarification changes 10.3. Changes in version 03 o Added some input from real life deployments and input on a test with batched notifies. o Added Calculations of messages and bytes per user. o Calculations are now done both for minimal size of presence document and for an average size of rich presence document. o Comparison with other protocol is now done using small, tiny and rich presence document sizes. o Removed dialog optimization with partial notification since it is not relevant o Fixed a few issues in calculations that were found by Victoria Beltran-Martinez. Houri, et al. Expires April 25, 2009 [Page 57] Internet-Draft Presence Scaling Analysis October 2008 * Added overhead for RLMI for dialog optimizations (list subscription). This calculation fix actually shows that dialog optimization is not a real optimization from the point of view of bytes and number of messages. * When NOTIFY optimizations are applied no need for final NOTIFY * The usage of RLS between domains was clarified. o Significantly enhanced the conclusions section o Several typo fixes 10.4. Changes in version 02 o Fixed a bug in the calculations. Thanks to Marc Willekens for finding the bug. 10.5. Changes in version 01 o Clarifications and corrections of the computation model and the computations. o Added several more computations to show the influence of different optimizations. o The requirements were moved to [18] o The new suggestions for optimizations were moved to [19] 11. Acknowledgments We would like to thank Jonathan Rosenberg, Ben Campbell, Robert Sparks, Markus Isomaki Piotr Boni, David Viamonte, Aki Niemi and Peter-Saint Andre for ideas and input. Special thanks to Marc Willekens and Victoria Beltran-Martinez for finding several issues in the calculations. 12. Informational References [1] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z., and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, January 2003. [2] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", RFC 3857, August 2004. [3] Rosenberg, J., "An Extensible Markup Language (XML) Based Format for Watcher Information", RFC 3858, August 2004. [4] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", Houri, et al. Expires April 25, 2009 [Page 58] Internet-Draft Presence Scaling Analysis October 2008 RFC 3863, August 2004. [5] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", RFC 4480, July 2006. [6] Burger, E., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006. [7] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- Requena, "Functional Description of Event Notification Filtering", RFC 4660, September 2006. [8] 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. [9] Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, August 2006. [10] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007. [11] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", RFC 4976, September 2007. [12] Lonnfors, M., Costa-Requena, J., Leppanen, E., and H. Khartabil, "Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information", RFC 5263, September 2008. [13] Niemi, A., Lonnfors, M., and E. Leppanen, "Publication of Partial Presence Information", RFC 5264, September 2008. [14] Rosenberg, J., "Presence Authorization Rules", RFC 5025, December 2007. [15] Garcia-Martin, M., "The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp)", RFC 5112, January 2008. [16] 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. [17] Niemi, A., "An Extension to Session Initiation Protocol (SIP) Houri, et al. Expires April 25, 2009 [Page 59] Internet-Draft Presence Scaling Analysis October 2008 Events for Conditional Event Notification", draft-ietf-sip-subnot-etags-03 (work in progress), July 2008. [18] Houri, A., Parameswar, S., Aoki, E., Singh, V., and H. Schulzrinne, "Scaling Requirements for Presence in SIP/SIMPLE", draft-ietf-sipping-presence-scaling-requirements-01 (work in progress), July 2008. [19] Houri, A., "Scaling Optimizations for Presence in SIP/SIMPLE", draft-houri-simple-interdomain-scaling-optimizations-00 (work in progress), July 2007. [20] Niemi, A., Kiss, K., and S. Loreto, "Session Initiation Protocol (SIP) Event Notification Extension for Notification Throttling", draft-niemi-sipping-event-throttle-07 (work in progress), October 2008. [21] Rosenberg, J., Donovan, S., and K. McMurry, "Optimizing Federated Presence with View Sharing", draft-ietf-simple-view-sharing-01 (work in progress), July 2008. [22] Rosenberg, J., Houri, A., and C. Smyth, "Models for Intra- Domain Presence and Instant Messaging (IM) Federation", draft-ietf-simple-intradomain-federation-01 (work in progress), July 2008. Authors' Addresses Avshalom Houri IBM Science Park Rehovot, Israel Email: avshalom@il.ibm.com Edwin Aoki AOL LLC 401 Ellis St. Mountain View, CA 94043 USA Email: aoki@aol.net Houri, et al. Expires April 25, 2009 [Page 60] Internet-Draft Presence Scaling Analysis October 2008 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 Houri, et al. Expires April 25, 2009 [Page 61] Internet-Draft Presence Scaling Analysis October 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Houri, et al. Expires April 25, 2009 [Page 62]