Problem Statement for SIP/SIMPLE

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

As more experience of deploying SIMPLE based presence systems is accumulated, it seems that deploying a large SIMPLE presence system is actually a very hard task. The document analyzes several aspects of SIMPLE based presence system deployment and shows that difficulties around the amount of messages (network), state management (memory) and processing load (cpu). Although this document is a problem statement document and not a BCP document, several possible optimizations and directions are listed at the end of the document in addition to an initial set of requirements for what should be the characteristic of the solution to the problem stated in the document This document is intended to be used by the SIMPLE WG in order to work on possible solutions that will make the deployment of a presence server more reasonable task. Note that the document does not try to compare the SIP based presence server to other types of presence servers but only analyzes the SIP based presence server. 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. Messages load - By computing the number of messages that are required for connecting presence systems the document shows that the number of messages is enormous and it is quite obvious that some optimizations are needed. 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. 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. Groups - Resource List Servers optimize that 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 this document several time. By this term we refer to a presence system 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.

Even though some optimizations are approved or are being defined, we show in this section that a very large number of messages 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 very similar situations occur between RLSs and presence servers due to the amount of subscriptions that RLSs may need to create to presence servers in order to handle the resource list subscriptions

The current optimizations that are approved or considered in the SIMPLE group can be divided into two categories: Dialogs saving optimization - Here we refer to optimizations as the resource list RFC or to the Uri list subscriptions draft . These documents define ways to reduce the number of dialogs that are required between the subscriber and the presence system. Notification optimizations - Here we refer to the optimizations that are suggested in the subnot-etags draft . This draft suggests ways to suppress the sending of unnecessary notifies when for example a subscription is refreshed. There are other drafts that reduce the size of messages as partial notifies or filtering but in this document we mostly care about the amount of messages.

The basic SIMPLE subscription dialog involves the following message- transfer: SUBSCRIBE/200 Initial NOTIFY/200 (j) NOTIFY/200 where ‘j’ is the number of presence changes seen by the watcher (k) SUBSCRIBE/200 where ‘k’ is the number of subscription dialog refresh periods SUBSCRIBE/200 with Expires = 0 to terminate the dialog NOTIFY/200 ending the dialog An individual watcher will generate X number of SIMPLE subscription dialogs corresponding to the number of presentities it chooses to watch. The amount of traffic generated is significantly affected by several factors: Number of watchers connected to the system Number of presentities connected to the system Complexity of presence & frequency of presence change This document contains several calculations that show the expected message rate between presence domains. The following explains the assumptions and methods behind the calculations: (A01) Subscription lifetime (hours)- The assumed lifetime of a subscription in hours. Here we assume 8 hours for all calculations. (A02) Presence state changes / hour - The average time that a presentity changes his/hers status in one hour. We assumed 3 times a hour for most calculations. Note that for some users in consumer messaging systems, the actual numbers are likely to be much higher. (A03) 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. (A04) 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 (A05) 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 A4, otherwise it is 1 (A06) Number of watchers in a federated presence domain - The number of watchers in one presence domain that watch users in the other domain. The number here varies according to the assumptions for a specific deployment (A07) Initial SUBSCRIBE/200 per watcher = A5*2 (message and an OK) (A08) Initial NOTIFY/200 per watcher = A5*2 (message and an OK) (A09) Total initial messages = (A7+A8)*A6 (A10) NOTIFY/200 per watched presentity = (A2*A1*A4*2) (message and an OK) (A11) SUBSCRIBE/200 refreshes = (A1/A3)*A5*2 (message and an OK) (A12) NOTIFY/200 due to subscribe refresh - In a deployment where the notification optimization is not deployed this number will be ((A1/A3)*A5), otherwise it is 0 (A13) Number of steady state messages = (A10+A11+A12)*A6 (A14) SUBSCRIBE termination = A5*2 (message and an OK) (A15) NOTIFY terminated = A5*2 (message and an OK) (A16) Number of sign-out messages = (A7+A8)*A6 (A17) Total messages between domains (both directions where users from domain A subscribe to users from domain B and vice versa)= (A9+A13+A16)*2 (A18) Total number of messages / second = A17/A1/3600 (seconds in hour)

The following table uses some common presence characteristics to demonstrate the effect these factors have on state and message rate within a presence domain using base SIMPLE protocols without any proposed optimizations. In this example, there are two presence domains, each with 20,000 federating users with an average of 4 contacts in the peer domain

The same analysis provided above is repeated here with the assumption that both the dialog and the notification optimizations are applied. Note that while the sign-in (ramp up) and sign-out messages flows are positively affected, the steady state rates are not. The optimizations enable the creation of a single dialog to the other domain from each subscriber for the set of presentities it is subscribing to. The optimizations also enable that there will be no need for a NOTIFY upon refreshing a SUBSCRIBE since the NOTIFY should not be sent in the refresh since it should be the same one as was sent when there was a state change for the presentity.

While these scalability issues exist in any large deployment, certain characteristics make the deployment conducive to the existing resource- list optimizations, and others have characteristics that cannot be exploited with the existing SIMPLE model. Following is a list of federation relationships that have varying usage characteristics. For each, a message rate table is provided reflecting typical changes message rates. Those characteristics can alter the overall effectiveness of existing optimizations.

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: Federated subscriptions are the majority of subscription traffic Individual users are likely to subscribe to multiple users in any one domain 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) To account for the extraordinarily high percentage of federation traffic, the number of federated presentities is increased to 20. The number of watchers in the domain could also be adjusted to account for an expected larger community of users being peered with, it is omitted here for simplification The first table below provides the calculations without optimizations the second table provides the calculations with optimization. Note that the number of messages per second decreases by a quarter with the optimizations but it is still quite big.

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: Federated subscriptions are large minority or small majority of subscription traffic Individual users are likely to subscribe to multiple users in any one domain, especially their own 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.

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 at the low end and consumer IM networks at the high end. Common characteristics of this deployment are: As users become accustomed to network boundaries disappearing, federated subscriptions become as common as subscriptions within the same domain Individual users are highly likely to want to see presence of multiple presentities in the peer network 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) 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 optimization. Even though the optimization help a lot (almost cut the number of messages by half), the numbers are still very concerning.

Within a particular domain, multiple presence infrastructures are deployed with users split between the two. This scenario is unique in that federated messages do not pass outside the administrative domain's network. The two infrastructures peer directly inside the domain. A common example of this is an enterprise IT system with multiple independent vendor presence solutions deployed(e.g., a presence solution for desktop messaging deployed alongside a presence solution for IP telephony). Common characteristics of this deployment are The 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 Active users are almost guaranteed of subscribing to many users in the peer infrastructure 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

In previous section 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. Maintain the state of the resources to which subscribers subscribe. Maintain the state of the subscriptions of subscribers and provide timely updates to the subscription. For a single subscription from a single watcher on a resource, the presence server has to maintain the following state: Subscription state including all the parameter that are needed in order to maintain the subscription as timers. Optional filtering information that was requested by the subscriber. 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 Optional rate management information as throttling Watcher information , that is resulted from the subscription itself so users that are subscribed to can see who is watching them For each resource that has been subscribed to in the presence server, the presence server has to maintain the following state: A list of the subscriptions for the resource. Note that this is already taken care of from the size calculation point of view by the subscription state above. Privacy information for the resource. For each resource for which there was any publication and the resource has a state other then a default value, the presence server has to maintain the current value of the resource.

Lets assume the following sizes: Subscription size - 2K bytes. This includes watcher information that need to be created by the presence server for each subscription. Subscribed to resource - 1K bytes (for privacy information and other management info. The subscriptions themselves are already calculated in the previous bullet. 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.

10K subscriptions = 19M bytes. 5K subscribed to resources = 5M bytes. 10K resources with state = 58M bytes. Total is 82M bytes.

100K subscriptions = 195M bytes. 50K subscribed to resources = 49M bytes. 100K resources with state = 586M bytes. Total is 830M bytes.

6M subscriptions = 11,718M bytes. 3M subscribed to resources = 2,929M bytes. 4M resources with state = 23437M bytes. Total is 38G bytes.

150M subscriptions = 292,969M bytes. 75M subscribed to resources = 73,242M bytes. 100M resources 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: 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 resources is being updated and so forth. This means that the presence server has to manage its state in a medium that is very dynamic and for such large sizes this task is not trivial. Intelinked state - The subscriptions and the subscribed to resources are dependent on each other. There need to be a link from the resource to the subscriptions and vice versa. This means that it is not trivial to e.g. separate the storage of subscriptions from the the resources. The intelinking is becoming a much more complex task when the presence server is deployed as a cluster of servers where each of the servers need to manage part of the overall state. 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, the state size in large and very large systems is very big and may need special technology to enable a presence server to handle the sate efficiently.

The basic presence paradigm consists from a subscriber and a resource to which the subscriber subscribes to. 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 one. 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 makes the task for the presence server challenging in all possible fronts: network, memory and cpu.

A presence document does not represent a single resource only but a user may have many resources that update the presence documents. These resources can be devices of the user, external providers of presence information for the user as geographical and calendar information and more. The presence server need to be able to get the updates from all the resource and aggregate them correctly into a single presence document. Although this is just "XML processing" task, the amount of updates that the presence server may get, the need to keep the presence document aligned with its schema and the need to notify the users as soon as possible create a significant processing burden on the presence server

Drafts , define a way for the subscriber to request getting only what was changed in the presence document and for the publisher of presence information to publish only what was changed in the presence document since the last publish. Although these optimizations help in reducing the amount of actual data that is sent from/to the presence server, these optimizations create additional processing burden on the presence server. 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. In partial notify each watcher need to get the partial update based on the last update that was received by that watcher. Therefore specifies a versioning mechanism that enables the watcher to get the updates based on the previous state that it has seen. However this versioning mechanism has to be maintained by the presence server for each watcher to the subscribed to resource that requires partial publish.

Filtering as defined in RFCs , 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.

Draft 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 filtering defined for it, the presence server needs to create different notification for different watchers according to what is defined in the authorization rules.

RFC 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 message calculations), this feature has the potential to make the number of subscriptions in a presence system to grow exponentially. There are two types of groups that may be used with this feature, private groups that are defined for each watcher and public groups that are defined in the system and can be used by any user. Public groups can be a source of making the number of subscriptions in the system grow exponentially. They are convenient to use, usually system administrator do not limit the size of these groups and in many cases we can find public groups that cover almost all the enterprise... Another aspect of the exponentially of resource lists is that as it is defined today by and with the current way that authorization between servers can be done, the RLS needs to subscribe on each resource that appear in the resource list even if that resource has been subscribed to by the RLS dozen times for other resource lists. This way of behavior creates an exponential and complex mesh of subscriptions between RLSs and presence servers.

In the previous sections we have shown several areas where the deployment of a presence system is far from being trivial, these include network load, memory load and CPU load. In this section we are listing an initial set of requirements to a possible optimizations in this area and we also list the existing and some suggested suggestions for opimizations.

The following is an initial list requirements for optimizations that seem to be necessary in presence systems: Backward compatibility requirements The solution should not hinder the ability of existing SIMPLE clients and/or servers from peering with a domain or client implementing the solution. No changes may be required of existing servers to interoperate It does NOT constrain any existing RFC functional or security requirements for presence Systems that are not using the new additions to the protocol should operate at the same level as they do today Policy, privacy, permissions requirements The solution does not limit the ability for presentities to present different views of presence to different watchers The solution does not restrict the ability of a presentity to obtain its list of watchers The solution MUST NOT create any new or make worse any existing privacy holes Scalability requirements It is highly desirable for any presence system (intra or inter-domain) to scale linearly as number of watchers and presentities increase linearly The solution SHOULD NOT require significantly more state in order to implement the solution It MUST be able to scale to tens of millions of concurrent users in each domain and in each peer domain It MUST support a very high level of watcher/presentity intersections in various intersection models Protocol changes MUST NOT prohibit optimizations in different deployment models esp. where there is a high level of cross subscriptions between the domains New functionalities and extensions to the presence protocol SHOULD take into account scalability with respect to the number of messages, state size and management and processing load. Topology requirement The solution SHOULD allow for arbitrary federation topologies including direct peering and intermediary routing

This section lists the current optimizations that have been defined, are being worked on or are suggested. Subnot-etags - Draft . 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. Resource List Service - 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. Partial notify/publish - Drafts , define a way for the subscriber to request getting only what was changed in the presence document and for the publisher of presence information to publish only what was changed in the presence document since the last publish. Although these optimizations help in reducing the amount of actual data that is sent from/to the presence server, these optimizations create additional processing burden on the presence server as was discussed above. Filtering as defined in RFCs , 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. Throttling [draft-niemi-sipping-event-throttle-04.txt - expired at the time of the writing of this document] 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. Presence specific sigcomp dictionary defines a SIGCOMP 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. Content Indirection 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 but in reality it may have several drawbacks: Due to partial/privacy/filtering and other functionalities, it will be relatively a rare case where many watchers will get exactly the same presence document. There should be a mechanism that will enable removing the content from the content server at the appropriate time. Defining the appropriate time is far from trivial since the removal should be synchronized with all the watcher that need to get the content. Resubscription to resource list requires that a full state will be sent for subside refreshes. In large resource lists the amount of data that needs to be sent for each subscribe refresh may be very big. Having an optimization that will enable sending only partial information at subscribe refreshes may let RLS subscriptions be more optimized. No Resubscriptions - Due to the nature of SIP that is network agnostic and always assumes the worst for the network layer, resubscriptions are part of the SIP sub/notify model . In many cases it should be possible to negotiate a special connection between watchers and presence servers, this type of connection will use a different mechanism of e.g. keep alives and will not necessitate resubscribes. This will be mostly important between presence domains and between RLSs and presence servers and may save many messages. Consolidated Subscriptions - In many of cases described in this document there are many subscriptions between peers that may be consolidated into a single subscription. One example of such subscriptions are subscriptions between domains, another example of such subscriptions are subscriptions that are created by the resource list server (RLS) to the presence servers that hold the presence document. The reason for not being able to do consolidation of subscriptions is privacy. A presence server needs to know who is the actual watcher in order to know if and what to send on the subscription. Enabling a single subscription from one presence server or an RLS to another presence server on behalf of many watchers contradicts the privacy considerations but on the other hand this single optimization can have a very big impact of the amount of the subscriptions that are required in the presence system. Some suggestions have been suggested but there is not concrete proposal on how to enable consolidated subscriptions while adhering to the privacy requirments.

The following calculations are made assuming that the following optimizations are deployed: No resubscriptions are necessary. Consolidates Subscriptions are possible. The following table shows the amount of messages that are required in this model using the very large network model numbers. We assume that even though there are 10M watchers from one domain to the other, the number of actually watched resources is only 3M.

Note that we get almost a 3 fold less messages by only assuming that 10M absorbers subscribe to 3M resources while consolidated subscriptions are possible. Note that due to the usage of the subnot-etags optimization the total removal of resubscribes does not save many messages as the following table shows:

"Only" additional 3.5K messages per second are needed if we re-introduce re-subscriptions, since the subnot-etags optimization is used.

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.

We would like to thank Jonathan Rosenberg, Markus Isomaki and David Viamonte for their ideas and input.