One document matched: draft-ietf-simple-interdomain-scaling-analysis-08.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="no" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="yes" ?>
<rfc category="info" ipr="trust200902" docName="draft-ietf-simple-interdomain-scaling-analysis-08.txt">
<front> <title abbrev='Presence Scaling Analysis'>Presence Interdomain Scaling Analysis for SIP/SIMPLE</title>
<author initials="A." surname="Houri" fullname="Avshalom Houri">
<organization>IBM</organization> <address> <postal> <street>Science Park
</street> <city>Rehovot</city> <region></region> <code></code>
<country>Israel</country> </postal> <email>avshalom@il.ibm.com</email>
</address> </author>
<author initials="E." surname="Aoki" fullname="Edwin Aoki">
<organization>AOL LLC</organization>
<address> <postal> <street>401 Ellis St.</street>
<city>Mountain View</city> <region>CA</region> <code>94043</code>
<country>USA</country> </postal> <email>aoki@aol.net</email> </address>
</author>
<author initials="S." surname="Parameswar" fullname="Sriram Parameswar">
<organization>Microsoft Corporation</organization> <address> <postal>
<street>One Microsoft Way</street> <city>Redmond</city> <region>WA</region>
<code>98052</code> <country>USA</country> </postal>
<email>Sriram.Parameswar@microsoft.com</email> </address> </author>
<author initials="T." surname="Rang" fullname="Tim Rang">
<organization>Microsoft Corporation</organization> <address> <postal>
<street>One Microsoft Way</street> <city>Redmond</city> <region>WA</region>
<code>98052</code> <country>USA</country> </postal>
<email>timrang@microsoft.com</email> </address> </author>
<author initials="V." surname="Singh" fullname="Vishal Singh">
<organization abbrev="Columbia U.">Columbia University</organization> <address>
<postal> <street>Department of Computer Science</street> <street>450 Computer
Science Building</street> <city>New York</city> <region>NY</region>
<code>10027</code> <country>US</country> </postal>
<email>vs2140@cs.columbia.edu</email>
<uri>http://www.cs.columbia.edu/~vs2140</uri> </address> </author>
<author initials="H." surname="Schulzrinne" fullname="Henning Schulzrinne">
<organization abbrev="Columbia U.">Columbia University</organization> <address>
<postal> <street>Department of Computer Science</street> <street>450 Computer
Science Building</street> <city>New York</city> <region>NY</region>
<code>10027</code> <country>US</country> </postal> <phone>+1 212 939
7004</phone> <email>hgs+ecrit@cs.columbia.edu</email>
<uri>http://www.cs.columbia.edu/~hgs</uri> </address> </author>
<date month="August" year="2009"/> <area>Real Time</area>
<workgroup>SIMPLE WG</workgroup> <keyword>I-D</keyword> <keyword>Internet-
Draft</keyword> <keyword>SIMPLE</keyword> <keyword>problem statement</keyword>
<abstract>
<t>This document analyzes the traffic that is generated by presence
subscriptions between domains and shows that the amount of traffic can be
extremely large. This document also analyzes
the effects of a large presence system on the memory footprint and the CPU load.
Approved and in-work optimizations to the Session Initiation Protocol are analyzed,
considering the possible impact on the load. Separate documents contain the
requirements for optimizations and suggestions for new optimizations.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The document analyzes the traffic that is generated by Session Initiation Protocol (SIP) for presence (as defined by the SIMPLE working group) due to presence subscriptions between domains.
It shows that the number of messages and the amount of data generated can be
extremely large. This document also
analyzes the effects of a large presence system on the memory footprint
and the CPU load. Approved and in-work optimizations to SIP
are analyzed, considering the possible impact on the load. Another
document provides requirements for optimizations <xref target="I-D.ietf-sipcore-presence-scaling-requirements" />
while other documents contain suggestions for new
optimizations: <xref target="I-D.houri-simple-interdomain-scaling-optimizations" /> and <xref target="I-D.ietf-simple-view-sharing"/></t>
<t>This document is intended to drive work on possible solutions that
will make the deployment of a SIP-based presence server a less challenging
task. Deployment of highly scalable presence systems is challenging by its
nature, and protocol developers design their own techniques for
optimizing their protocols. Comparing
protocols is beyond the scope of this document. </t>
<t>This document discusses the following areas, showing the
complexity and load that the presence server handles in order to
provide its service:</t>
<t><list style="symbols">
<t>Message load - By computing the number of messages that are required for
connecting presence systems, the document shows that the number of messages and
the required bandwidth are large, and that it is quite obvious that
optimizations are needed. </t>
<t>State management - Due to the nature of the service that the presence server
provides, the presence server has to manage a relatively large and complex state.
Some computations are provided in the document.</t>
<t>Processing complexities - The presence server maintains many small objects
and performs frequent operations on these objects. We show that these operations,
as well as the optimizations that are intended to reduce the amount of data sent
between watchers and presence servers, are not so simple and may create a heavy
processing load on the presence server.</t>
<t>Groups - Resource List Servers <xref target="RFC4662"/> optimize the number
of sessions that are created between the watchers and the presence server.
However, this optimization may create an exponential increase in the size of subscriptions
as a result of the minimal effort of subscribing to large groups.</t>
</list></t>
<t>The terms "presence domain" or "presence system" appear in this document frequently.
These terms refer to SIP-based presence servers that provide presence
subscription and notification services to their users. A presence system can be
deployed in a small enterprise or in a large consumer network.</t>
</section>
<section title="Message Load">
<t>Some optimizations are approved or are being defined for the SIP presence
protocol, but even with these optimizations, a large number of messages and
wide 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.</t>
<t>Note that even though this document talks about inter-domain traffic, the
introduction of resource list servers (RLSs) <xref target="RFC4662"/> introduces
similar traffic patterns intra-domain and inter-domain. See the detailed
discussion on resource lists in <xref target="RLS"/>.</t>
<section title="Message Load Optimizations Considered">
<t>The current optimizations that were approved as RFCs
or are approved as working group items
in the SIMPLE working group can be divided into two categories:</t>
<t><list style="symbols">
<t>Dialog-saving optimizations - Here we refer to optimizations such as the
resource list RFC <xref target="RFC4662"/> or to the URI list subscriptions
RFC <xref target="RFC5367"/>. These documents
define ways to reduce the number of dialogs that are required between the
subscriber and the presence system.
<list style="empty">
<t><vspace />Note that the terms "dialog optimization" or "RLS usage", as used in this
document, refer to the usage of a URI that represents a list of URI lists
between domains and not within the same domain. An example is a user Alice in
domain example.org who subscribes to the URI external-reps-list at
example.com or uses a URI list to subscribe to her watch list in example.com.
Note also that, when calculating the traffic due to the RLS within a domain,
the traffic between the RLS and the presence agents should also be considered.
However, because we are mostly concerned with inter-
domain traffic, we are not taking into account the traffic between the RLS and the presence agents.
<vspace blankLines='1' /> </t>
</list>
</t>
<t>Notification optimizations - Here we refer to the optimizations
covered in the subnot-etags draft <xref target="I-D.ietf-sipcore-subnot-etags"/>,
which describes the suppression of unnecessary NOTIFYs when
subscriptions are refreshed. There are other drafts that reduce the size of
messages by using partial notifications or filtering. This document shows that
partial optimizations can reduce the bandwidth but do not reduce the number of
messages. </t>
</list></t>
<t>One optimization that was not considered
is the reception of presence information
outside of SIP. An example of this is the ability to download
persistent presence information directly from a web site.
The calculations assume that all presence
data is carried within SIP and not by other means.
These out-of-band optimizations may improve the number of messages and number
of bytes significantly, but they are out of scope for this document.</t>
</section>
<section title="Assumptions">
<t>In this 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 from actual SIP-based deployments of
presence systems but more on some experience with other types of presence-based systems.</t>
<t>The following numbers are given more as examples from real deployments and they are not intended to be
complete.</t>
<t>In a large consumer network, we have seen the following patterns:</t>
<t><list style="symbols">
<t>There are approximately 110 users on a watch list on average.</t>
<t>There are approximately 12 billion status changes a day (139k/second) across
the network. When a proprietary binary protocol conveys the
status changes, the average message size is about 188 bytes. When a SIP NOTIFY is
used, the average is about 1228 bytes.</t>
<t>The average number of logins/logouts in the system is about 2000 logins per second and about 4000 logouts per second.
When a promotion, contest, or network
hiccup causes many users to login and logout simultaneously, there are about 20,000 logins per second.</t>
<t>The peak number of instant messages sent is about 50,000 messages per second.</t>
</list></t>
<t>In an enterprise deployment, we have seen the following patterns:</t>
<t><list style="symbols">
<t>Average watch list size was 200 users.</t>
<t>About half of the registered users were online at peak time.</t>
<t>Status change rate was 2 changes per hour.</t>
<t>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.</t>
</list></t>
<t>Even though the assumptions in this document are not based on rigorous
statistical data, the target here is not to analyze a specific system but
to show that even with VERY moderate assumptions (which are even less than
the observations mentioned above), the number of messages, the network
bandwidth, the required state management, and the CPU load are
high. Real-life systems could have much larger 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 shows that the frequency can be much higher, especially with the younger generation using more
presence attributes like mood, etc. In an environment where a user may
have several devices and other resources for presence information such as
geographical location and calendar, the frequency of presence state changes
will be much higher.</t>
<t>It is hard to measure presence load because it depends heavily
on the behavior of users, and the behavior of users differs widely.
Some users will have a small number of presentities in their watch
list, while others may have hundreds, or even thousands. Some users will
change their state frequently and have many sources of presence information,
while others may have small number of changes during the day. In
addition, the "rush hour" calculations of when the day starts and ends were
not included in this document. Rush hour differs between different
enterprises and is different still in the consumer presence systems. It is
hard, if not impossible, to include in a static document all the possible
combinations.</t>
<t>Throughout the calculations, a certain number of users are assumed for the
different models. That does not mean that in actual deployments all the
users of the domain are actually subscribed to presence documents and/or have
published their presence documents. 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, the
numbers tend to be around 50 percent of the actual enterprise registered
users.</t>
<t>The same is true for the number of watched presentities per
watcher. If only some percentage of the domain users are online at a given
time, then this number should match that percentage. However, adding
this assumption to the calculations will make the calculations more
complex because the effect of the watched offline presentities
would need to be considered. This means that empty
NOTIFYs would be sent for offline presentities when the subscription is created and there
are 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 used in the calculations is the number of the
federated presentities from the watcher list that are online.</t>
</section>
<section title="Analysis">
<t>The basic SIP subscription dialog involves the following message-
transfer:</t>
<t><list style="symbols">
<t>SUBSCRIBE/200</t>
<t>Initial NOTIFY/200</t>
<t>(j) NOTIFY/200 where "j" is the number of presence changes seen by the
watcher</t>
<t>(k) SUBSCRIBE/200 where "k" is the number of subscription dialog refresh
periods</t>
<t>SUBSCRIBE/200 with Expires = 0 to terminate the dialog</t>
<t>NOTIFY/200 ending the dialog</t>
</list></t>
<t>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:</t>
<t><list style="symbols">
<t>Number of watchers connected to the system.</t>
<t>Number of presentities connected to the system.</t>
<t>Frequency of changes to presence information.</t>
</list></t>
<t>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.</t>
<section title="Constants">
<t>The following are the "constants" that we use in the calculations. Some of the
constants are used throughout the calculations while others change between use cases.</t>
<t><list style="symbols">
<t>(C01) Subscription lifetime (hours) - The assumed lifetime of a subscription,
in hours. We assume 8 hours for all calculations. Note that the term "day" that
is used in the document and C01 are synonymous.</t>
<t>(C02) Presence state changes / hour - The average time that a presentity
changes his/her status in one hour. We assumed 3 times per hour for most
calculations. Note that for some users in consumer messaging systems, the actual
number of changes is likely to be much higher.</t>
<t>(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.</t>
<t>(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.</t>
<t>(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 C04, otherwise it is 1.</t>
<t>(C06) Total number of watchers in the federated presence domains. The number
here is the number of all watchers in all the federated domains.</t>
<t>(C07) SUBSCRIBE message size, in bytes. We assume 450 bytes in all
calculations. The size is based on a typical SUBSCRIBE taken from RFCs.</t>
<t>(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.</t>
<t>(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).</t>
<t>(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.</t>
<t>(C11) Size of an average presence document, in bytes. Two sizes of average presence
doucment are used. One is the minimal size of the PIDF <xref target="RFC3863"/>
document, assumed to be 350 bytes based on examples from RFCs, and the other is
3000 bytes for a rich presence document <xref target="RFC4480"/>. It should be
noted that 3000 bytes for a presence document is relatively modest if we take
into account multiple devices and location information.</t>
<t>(C12) The size of a NOTIFY, in bytes, when partial notification <xref target="RFC5263"/> is used.
We have taken this size to be 200 bytes, much smaller than the
example given in <xref target="RFC5263"/>, which assumes
multiple changes in the presence document. Here we assume a single
change.
<list style="empty">
<t><vspace />When dialog optimization <xref target="RFC4662"/> is used, an RLMI document,
which contains the presence documents for the users on the watch list, is sent.
In a previous version of this document, we had omitted the overhead of the RLMI
document. This "bug" was found by Victoria Beltran-Martinez and is fixed in this
version by adding the following constants C13, C14 and C15 to the
calculations.<vspace blankLines='1' /></t>
</list>
</t>
<t>(C13) Item size per each contact in RLMI document, 160 bytes.</t>
<t>(C14) The size of the multipart boundary in RLMI notifications, 144 bytes.</t>
<t>(C15) The size of the XML root node in RLMI document (once per notification), 144 bytes.</t>
</list></t>
</section>
<section title="Initial Messages">
<t>The following are the calculations for the messages in the initial phase of
the establishment of the subscriptions. The calculations contain both the number of
messages and the number of bytes.</t>
<t><list style="symbols">
<t>(I01) Number of initial SUBSCRIBE messages per watcher = C05.</t>
<t>(I02) Number of initial 200 OK messages for SUBSCRIBE messages per watcher = C05.</t>
<t>(I03) Number of initial NOTIFY messages per watcher = C05.</t>
<t>(I04) Number of initial 200 OK messages for NOTIFY messages per watcher = C05.</t>
<t>(I05) Total number and bytes of initial SUBSCRIBE messages for all watchers =
Number: I01*C06, Bytes: I01*C06*C07.</t>
<t>(I06) Total number and bytes of initial 200 OK for SUBSCRIBE messages for all
watchers = Number: I01*C06, Bytes: I01*C06*C08.</t>
<t>(I07) Total number and bytes of initial NOTIFY messages for all watchers =
Number: I01*C06.
<vspace />
The calculation for the size in bytes is different depending on the use of dialog
optimization:
<list style="symbols">
<t>When dialog optimization is not applied, the number of
bytes is calculated by (I01*C06*C09)+(I01*C06*C11).</t>
<t>When dialog optimization is applied, the number of bytes is calculated by
(I01*C06*(C09+C14+C15))+(I01*C06*C04*(C11+C13+C14)).</t>
</list>
</t>
<t>(I08) Total number and bytes of initial 200 OK for NOTIFY messages for all
watchers = Number: I04*C06, Bytes: I04*C06*C10.</t>
<t>(I09) Total number and bytes of initial messages per day = Number: numbers
in I05+I06+I07+I08, Size: sizes in I05+I06+I07+I08.</t>
</list></t>
</section>
<section title="Steady State Messages">
<t>Here we describe the calculations for steady state messages. Steady state
is the time between the initial subscription and the teardown of the
subscription. It contains the NOTIFYs due to state change and the subscription refreshes.</t>
<t><list style="symbols">
<t>(S01) NOTIFY messages due to state change per watched presentity per day
(less 2, because the NOTIFYs for initial and terminating states are included
in the initial and terminating calculations) = (C02*C01-2).</t>
<t>(S02) 200 messages (for NOTIFYs due to state change) per watched presentity
per day (less 2, because the NOTIFYs for initial and terminating states are included
in the initial and terminating calculations) = (C02*C01-2).</t>
<t>(S03) Total number and size of messages due to state change per day = Number: (S01+S02)*C06*C04.
<vspace />
The calculation for the size in bytes depends on the use of
dialog optimization:
<list style="symbols">
<t>When dialog optimization is not applied, the
number of bytes is calculated by (C06*C04)*((S01*(C09+C11))+(S02*C10)).</t>
<t>When dialog optimization is applied, the number of bytes is calculated by
(C06*C04)*((S01*(C09+C11+C13+C14+C15+C14))+(S02*C10)).</t>
</list>
This includes 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.</t>
<t>(S04) Number of SUBSCRIBE messages for refreshes per watcher per day =
((C01/C03)-1)*C05. One is subtracted because 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.</t>
<t>(S05) Number of 200 OK messages for SUBSCRIBE messages for refreshes per watcher per day =
((C01/C03)-1)*C05.</t>
<t>(S06) Number of NOTIFY messages for refreshes per watcher per day =
((C01/C03)-1)*C05. If NOTIFY optimization is used <xref target="I-D.ietf-sipcore-subnot-etags"/>, there is no
need to send NOTIFYs for refreshes, and S06 will be zero.</t>
<t>(S07) Number of 200 OK messages for NOTIFY messages for refreshes per watcher
per day = ((C01/C03)-1)*C05. If NOTIFY optimization is used <xref target="I-D.ietf-sipcore-subnot-etags"/>,
there is no need to send NOTIFYs for refreshes, and S07 will be zero.</t>
<t>(S08) Total number and size of messages due to SUBSCRIBE refreshes per day =
Number: (S04+S05+S06+S07)*C06.
<vspace />
The size in bytes is calculated by adding the
SUBSCRIBE bytes (S04*C06*C07), the OK bytes for the SUBSCRIBE (S05*C06*C08), the
NOTIFY bytes C06*(S06*(C09+C11)) and the OK bytes for the NOTIFY
(S07*C06*C10).
<list style="symbols">
<t>Note that the formula for the NOTIFY bytes assumes that dialog
optimization is not used. When dialog optimization is used, the formula is:
C06*(S06*((C09+C14+C15)+(C04*(C11+C13+C14)))).</t>
<t>Note that a full state should be
given in SUBSCRIBE refreshes in resource lists. See section 5.2 in
<xref target="RFC4662"/>.
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.</t>
</list>
</t>
<t>(S09) Total number and bytes of steady messages per day = Number: numbers
in S03+S08, Bytes: sizes in S03+S08.</t>
</list></t>
</section>
<section title="Termination Messages">
<t>The following are the calculations for the messages in the termination phase of
the subscriptions. The calculations contain both the number of
messages and the number of bytes.</t>
<t><list style="symbols">
<t>(T01) Number of terminating SUBSCRIBE messages per watcher = C05.</t>
<t>(T02) Number of terminating 200 OK messages for SUBSCRIBE messages per watcher = C05.</t>
<t>(T03) Number of terminating NOTIFY messages per watcher = C05. If NOTIFY optimization is used <xref target="I-D.ietf-sipcore-subnot-etags"/>,
there is no need to send a NOTIFY for terminations, and T03 will be zero.</t>
<t>(T04) Number of terminating 200 OK messages for NOTIFY messages per watcher =
C05. If NOTIFY optimization is used <xref target="I-D.ietf-sipcore-subnot-etags"/>,
there is no need to send a NOTIFY for terminations, and T04 will be zero.</t>
<t>(T05) Total number and bytes of terminating SUBSCRIBE messages for all watchers = Number: T01*C06, Bytes: T01*C06*C07.</t>
<t>(T06) Total number and bytes of terminating 200 OK for SUBSCRIBE messages for
all watchers = Number: T01*C06, Bytes: T01*C06*C08.</t>
<t>(T07) Total number and bytes of terminating NOTIFY messages for all watchers
= Number: T01*C06. The number of bytes is calculated to be:
<list style="symbols">
<t>(T03*C06*(C09+C11) when dialog optimization is not used, and</t>
<t>(T03*C06*(C09+C14+C15))+(T03*C06*C04*(C11+C13+C14)) when dialog optimization
is used.</t>
</list>
Note that a full state should be given in SUBSCRIBE refreshes in resource
lists. See section 5.2 in <xref target="RFC4662"/>.</t>
<t>(T08) Total number and bytes of terminating 200 OK for NOTIFY messages for all
watchers = Number: T04*C06, Bytes: T04*C06*C10.</t>
<t>(T09) Total number and bytes of terminating messages per day = Number: numbers
in T05+T06+T07+T08, Size: sizes in T05+T06+T07+T08.</t>
</list></t>
</section>
<section title="Bottom Line">
<t>The following are the calculations of several totals that are based on the
above calculations.</t>
<t><list style="symbols">
<t>(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.</t>
<t>(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).</t>
<t>(B03) Total number of message and bytes per user per day = Messages: number
of messages in B01/C06, Bytes: number of bytes in B01/C06.</t>
</list></t>
</section>
<section title="Rush Hour Calculations">
<t>With the way that the calculations are built, it is relatively easy to see the
effect 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 number of users logging in
at the same hour should give good indication for the rush hour load.</t>
</section>
</section>
<section title="No optimizations used">
<t>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 without any proposed optimizations. In this
example, there are two presence domains with a total of 40,000 federating users
with an average of 4 contacts per user in the peer domain. Note that the main calculation
is done for a presence document size of 350 bytes, which is the base PIDF <xref target="RFC3863"/>
document size, but the bottom-line calculation is also given for a presence
document size for rich presence <xref target="RFC4480"/>, which is assumed to be 3000
bytes, based on the examples given in the RFCs. This two-fold calculation is
done for every use case in this document.</t>
<figure title="No optimizations used" anchor="fig01">
<artwork><![CDATA[
** Constants
(C01) Subscription lifetime (hours)...........................8
(C02) Presence state changes / hour...........................3
(C03) Subscription refresh interval / hour....................1
(C04) Total federated presentities per watcher................4
(C05) Number of dialogs to maintain per watcher...............4
(C06) Total number of watchers in domains................40,000
(C07) SUBSCRIBE message size in bytes.......................450
(C08) 200 OK for SUBSCRIBE message size in bytes............370
(C09) NOTIFY message size not including presence doc........500
(C10) 200 OK for NOTIFY message size in bytes...............370
(C11) Size of an average presence document..................350
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher......................4
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............4
(I03) Initial NOTIFY msgs per watcher.........................4
(I04) Initial 200 OK msgs (NOTIFY) per watcher................4
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers.....................72,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers.....................59,200,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers....................136,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers.....................59,200,000
(I09) Total number & bytes of initial messages per day
Number of msgs for all watchers...............640,000
Bytes for all watchers....................326,400,000
** Steady State Messages
(S01) NOTIFY msgs due to state change
per watched presentity per day.....................22
(S02) 200 (for NOTIFY due to state change) msgs
per watched presentity per day.....................22
(S03) Total number and size of msgs due to state change per day
Number of msgs for all watchers.............7,040,000
Bytes for all watchers..................4,294,400,000
(S04) Number of SUBSCRIBE msgs for refreshes
per watcher per day................................28
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
per watcher per day................................28
(S06) Number of NOTIFY msgs for refreshes
per watcher per day................................28
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
per watcher per day................................28
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
Number of msgs for all watchers per day.....4,480,000
Bytes for all watchers per day..........2,284,800,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers............11,520,000
Bytes for all watchers..................6,579,200,000
** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher..................4
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........4
(T03) Terminating NOTIFY msgs per watcher.....................4
(T04) Terminating 200 OK msgs (NOTIFY) per watcher............4
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
Number of msgs for all watchers.............. 160,000
Bytes for all watchers.....................72,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers.....................59,200,000
(T07) Total number & bytes of terminating NOTIFY msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers....................136,000,000
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers.....................59,200,000
(T09) Total number & bytes of terminating messages per day
Number of msgs for all watchers...............640,000
Bytes for all watchers....................326,400,000
** Bottom Line
(B01) Total of messages between domains..............12,800,000
Total of bytes between domains (PD=350).....7,232,000,000
Total of bytes between domains (PD=3000)...20,376,000,000
(B02) Total number of messages / second.. ..................444
Total of bytes per second (PD=350)................251,111
Total of bytes per second (PD=3000)...............707,500
(B03) Total number of by msgs per user/day......... ........320
Total number of bytes per user/day (PD=350).......180,800
Total number of bytes per user/day (PD=3000)......509,400
]]></artwork></figure>
</section>
<section title="Dialog optimization used">
<t>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 message flows are positively affected, the steady state
rates are not.</t>
<figure title="Dialog optimization used" anchor="fig02">
<artwork><![CDATA[
** Constants
(C01) Subscription lifetime (hours)...........................8
(C02) Presence state changes / hour...........................3
(C03) Subscription refresh interval / hour....................1
(C04) Total federated presentities per watcher................4
(C05) Number of dialogs to maintain per watcher...............1
(C06) Total number of watchers in domains................40,000
(C07) SUBSCRIBE message size in bytes.......................450
(C08) 200 OK for SUBSCRIBE message size in bytes............370
(C09) NOTIFY message size not including presence doc........500
(C10) 200 OK for NOTIFY message size in bytes...............370
(C11) Size of an average presence document..................350
(C13) Additional data per document in RLMI..................160
(C14) Multiparty boundary in RLMI document..................144
(C15) XML root node in RLMI document........................144
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher......................1
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1
(I03) Initial NOTIFY msgs per watcher.........................1
(I04) Initial 200 OK msgs (NOTIFY) per watcher................1
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................18,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................14,800,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers................40,000
Bytes for all watchers....................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
(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
]]></artwork></figure>
</section>
<section title="NOTIFY optimization used">
<t>The analysis provided in <xref target='fig01'/> is
repeated here with the assumption that the notification 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 are no NOTIFY
messages for SUBSCRIBE refreshes and terminations. As expected, this
optimization affects the steady and termination states and does not affect the
initial state.</t>
<figure title="NOTIFY optimization used" anchor="fig03">
<artwork><![CDATA[
** Constants
(C01) Subscription lifetime (hours)...........................8
(C02) Presence state changes / hour...........................3
(C03) Subscription refresh interval / hour....................1
(C04) Total federated presentities per watcher................4
(C05) Number of dialogs to maintain per watcher...............4
(C06) Total number of watchers in domains................40,000
(C07) SUBSCRIBE message size in bytes.......................450
(C08) 200 OK for SUBSCRIBE message size in bytes............370
(C09) NOTIFY message size not including presence doc........500
(C10) 200 OK for NOTIFY message size in bytes...............370
(C11) Size of an average presence document..................350
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher......................4
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............4
(I03) Initial NOTIFY msgs per watcher.........................4
(I04) Initial 200 OK msgs (NOTIFY) per watcher................4
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers.....................72,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers.....................59,200,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers....................136,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers.....................59,200,000
(I09) Total number & bytes of initial messages per day
Number of msgs for all watchers...............640,000
Bytes for all watchers....................326,400,000
** Steady State Messages
(S01) NOTIFY msgs due to state change
per watched presentity per day.....................22
(S02) 200 (for NOTIFY due to state change) msgs
per watched presentity per day.....................22
(S03) Total number and size of msgs due to state change per day
Number of msgs for all watchers.............7,040,000
Bytes for all watchers..................4,294,400,000
(S04) Number of SUBSCRIBE msgs for refreshes
per watcher per day................................28
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
per watcher per day................................28
(S06) Number of NOTIFY msgs for refreshes
per watcher per day.................................0
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
per watcher per day.................................0
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
Number of msgs for all watchers per day.....2,240,000
Bytes for all watchers per day............918,400,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers.............9,280,000
Bytes for all watchers..................5,212,800,000
** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher..................4
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........4
(T03) Terminating NOTIFY msgs per watcher.....................0
(T04) Terminating 200 OK msgs (NOTIFY) per watcher............0
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
Number of msgs for all watchers.............. 160,000
Bytes for all watchers.....................72,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers.....................59,200,000
(T07) Total number & bytes of terminating NOTIFY msgs
Number of msgs for all watchers.....................0
Bytes for all watchers..............................0
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
Number of msgs for all watchers.....................0
Bytes for all watchers..............................0
(T09) Total number & bytes of terminating messages per day
Number of msgs for all watchers...............320,000
Bytes for all watchers....................131,200,000
** Bottom Line
(B01) Total of messages between domains..............10,240,000
Total of bytes between domains (PD=350).....5,670,400,000
Total of bytes between domains (PD=3000)...15,422,400,000
(B02) Total number of messages / second.....................356
Total of bytes per second (PD=350)................196,889
Total of bytes per second (PD=3000)...............535,500
(B03) Total number of by msgs per user/day..................256
Total number of bytes per user/day (PD=350).......141,760
Total number of bytes per user/day (PD=3000)......385,560
]]></artwork></figure>
</section>
<section title="Dialog and NOTIFY optimizations used">
<t>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.</t>
<figure title="Dialog and NOTIFY optimizations used" anchor="fig04">
<artwork><![CDATA[
** Constants
(C01) Subscription lifetime (hours)...........................8
(C02) Presence state changes / hour...........................3
(C03) Subscription refresh interval / hour....................1
(C04) Total federated presentities per watcher................4
(C05) Number of dialogs to maintain per watcher...............1
(C06) Total number of watchers in domains................40,000
(C07) SUBSCRIBE message size in bytes.......................450
(C08) 200 OK for SUBSCRIBE message size in bytes............370
(C09) NOTIFY message size not including presence doc........500
(C10) 200 OK for NOTIFY message size in bytes...............370
(C11) Size of an average presence document..................350
(C13) Additional data per document in RLMI..................160
(C14) Multiparty boundary in RLMI document..................144
(C15) XML root node in RLMI document........................144
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher......................1
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1
(I03) Initial NOTIFY msgs per watcher.........................1
(I04) Initial 200 OK msgs (NOTIFY) per watcher................1
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................18,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................14,800,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers................40,000
Bytes for all watchers....................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
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
]]></artwork></figure>
</section>
<section title="Presence Federation Scenarios">
<t>While scalability issues exist in any large deployment, certain
deployments have characteristics that are conducive to the existing
optimizations, and others have characteristics that are not. What follows
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
characteristics can alter the overall effectiveness of existing
optimizations.</t>
<t>Note that the number of users considered is not the total number of users
in the domains but the number of actual logged-in users. As was mentioned before,
not all the domain users will use the presence service at the same
time. The numbers used for watchers and watched
presentities are for online users.</t>
<section title="Widely distributed inter-domain presence">
<t>In some environments, presence federation may be 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 because 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 domains, other ISVs,
etc). Common characteristics of this deployment are these:</t>
<t><list style="symbols">
<t>Federated subscriptions are the majority of subscription traffic.</t>
<t>Individual users are likely to subscribe to multiple users in any one
domain.</t>
<t>The intersection of users in the deployment watching the same
presentities is quite small (that is, the probability that multiple watchers in the
domain are subscribed to the same presentity is low).</t>
</list></t>
<t>To account for the extraordinarily high percentage of federation
traffic, the number of federated presentities is increased to 20. Although the
number of watchers in the domain could also be adjusted to allow for
an expected larger community of users being peered with, it is omitted
here for simplification.</t>
<t>The first table below provides the calculations without optimizations.
The second table provides the calculations with optimizations.</t>
<figure title="Widely distributed inter-domain with no optimizations" anchor="fig05">
<artwork><![CDATA[
** Constants
(C01) Subscription lifetime (hours)...........................8
(C02) Presence state changes / hour...........................3
(C03) Subscription refresh interval / hour....................1
(C04) Total federated presentities per watcher...............20
(C05) Number of dialogs to maintain per watcher..............20
(C06) Total number of watchers in domains................40,000
(C07) SUBSCRIBE message size in bytes.......................450
(C08) 200 OK for SUBSCRIBE message size in bytes............370
(C09) NOTIFY message size not including presence doc........500
(C10) 200 OK for NOTIFY message size in bytes...............370
(C11) Size of an average presence document..................350
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher.....................20
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher............20
(I03) Initial NOTIFY msgs per watcher........................20
(I04) Initial 200 OK msgs (NOTIFY) per watcher...............20
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers...............800,000
Bytes for all watchers....................360,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers...............800,000
Bytes for all watchers....................296,000,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers...............800,000
Bytes for all watchers....................680,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
Number of msgs for all watchers...............800,000
Bytes for all watchers....................296,000,000
(I09) Total number & bytes of initial messages per day
Number of msgs for all watchers.............3,200,000
Bytes for all watchers..................1,632,000,000
** Steady State Messages
(S01) NOTIFY msgs due to state change
per watched presentity per day.....................22
(S02) 200 (for NOTIFY due to state change) msgs
per watched presentity per day.....................22
(S03) Total number and size of msgs due to state change per day
Number of msgs for all watchers............35,200,000
Bytes for all watchers.................21,472,000,000
(S04) Number of SUBSCRIBE msgs for refreshes
per watcher per day...............................140
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
per watcher per day...............................140
(S06) Number of NOTIFY msgs for refreshes
per watcher per day...............................140
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
per watcher per day...............................140
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
Number of msgs for all watchers per day....22,400,000
Bytes for all watchers per day.........11,424,000,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers............57,600,000
Bytes for all watchers.................32,896,000,000
** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher.................20
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........20
(T03) Terminating NOTIFY msgs per watcher....................20
(T04) Terminating 200 OK msgs (NOTIFY) per watcher...........20
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
Number of msgs for all watchers...............800,000
Bytes for all watchers....................360,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers...............800,000
Bytes for all watchers....................296,000,000
(T07) Total number & bytes of terminating NOTIFY msgs
Number of msgs for all watchers...............800,000
Bytes for all watchers....................680,000,000
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
Number of msgs for all watchers...............800,000
Bytes for all watchers....................296,000,000
(T09) Total number & bytes of terminating messages per day
Number of msgs for all watchers.............3,200,000
Bytes for all watchers..................1,632,000,000
** Bottom Line
(B01) Total of messages between domains..............64,000,000
Total of bytes between domains (PD=350)....36,160,000,000
Total of bytes between domains (PD=3000)..101,880,000,000
(B02) Total number of messages / second...................2,222
Total of bytes per second (PD=350)..............1,255,556
Total of bytes per second (PD=3000).............3,537,500
(B03) Total number of by msgs per user/day................1,600
Total number of bytes per user/day (PD=350).......904,000
Total number of bytes per user/day (PD=3000)....2,547,000
]]></artwork></figure>
<figure title="Widely distributed inter-domain with optimizations" anchor="fig06">
<artwork><![CDATA[
** Constants
(C01) Subscription lifetime (hours)...........................8
(C02) Presence state changes / hour...........................3
(C03) Subscription refresh interval / hour....................1
(C04) Total federated presentities per watcher...............20
(C05) Number of dialogs to maintain per watcher...............1
(C06) Total number of watchers in domains................40,000
(C07) SUBSCRIBE message size in bytes.......................450
(C08) 200 OK for SUBSCRIBE message size in bytes............370
(C09) NOTIFY message size not including presence doc........500
(C10) 200 OK for NOTIFY message size in bytes...............370
(C11) Size of an average presence document..................350
(C13) Additional data per document in RLMI..................160
(C14) Multiparty boundary in RLMI document..................144
(C15) XML root node in RLMI document........................144
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher......................1
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1
(I03) Initial NOTIFY msgs per watcher.........................1
(I04) Initial 200 OK msgs (NOTIFY) per watcher................1
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................18,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................14,800,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers................40,000
Bytes for all watchers....................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
(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
]]></artwork></figure>
</section>
<section title="Associated inter-domain presence">
<t>In this type of environment, the domain is a collection of associated
users, such as an enterprise. Here, federation is once again
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 are watchers of the same presentity. This can
occur because of business relationships (for example, two co-workers on a project
federating with a partner company).</t>
<t>Common characteristics of this deployment are these:</t>
<t><list style="symbols">
<t>Federated subscriptions are large minority or small majority of
subscription traffic.</t>
<t>Individual users are likely to subscribe to multiple users in any one
domain, especially their own.</t>
<t>The intersection of users in the deployment watching the same
presentities increases.</t>
</list></t>
<t>This federation type has traffic rates similar to the previous examples
but with different levels of association of the users. </t>
</section>
<section title="Large network peering">
<t>In this environment, two or more Large networks create a peering
relationship, allowing their users to subscribe to presence in the other
domains. Whereas 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 instant messaging networks.</t>
<t>Common characteristics of this deployment are these:</t>
<t><list style="symbols">
<t>As users become accustomed to network
boundaries disappearing, federated subscriptions become as common as
subscriptions within the same domain.</t>
<t>Individual users are highly
likely to want to see presence of multiple presentities in the peer
network.</t>
<t>The intersection of users in the deployment watching the
same presentities is high (that is, two or more users in network A are
extremely likely to be watching a same user in network B).</t>
<t>Status
changes increase greatly due to typical observed consumer behavior.</t>
</list></t>
<t>The first table below provides the calculations without optimizations;
the second table provides the calculations with optimizations. Even
though the optimizations help a lot (cut the number of messages almost in
half), the numbers are still high. Note also that the bandwidth required is high.</t>
<figure title="Large network peering with no optimizations" anchor="fig07">
<artwork><![CDATA[
** Constants
(C01) Subscription lifetime (hours)...........................8
(C02) Presence state changes / hour...........................6
(C03) Subscription refresh interval / hour....................1
(C04) Total federated presentities per watcher...............10
(C05) Number of dialogs to maintain per watcher..............10
(C06) Total number of watchers in domains............20,000,000
(C07) SUBSCRIBE message size in bytes.......................450
(C08) 200 OK for SUBSCRIBE message size in bytes............370
(C09) NOTIFY message size not including presence doc........500
(C10) 200 OK for NOTIFY message size in bytes...............370
(C11) Size of an average presence document..................350
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher.....................10
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher............10
(I03) Initial NOTIFY msgs per watcher........................10
(I04) Initial 200 OK msgs (NOTIFY) per watcher...............10
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers.................90,000,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers.................74,000,000,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers................170,000,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers.................74,000,000,000
(I09) Total number & bytes of initial messages per day
Number of msgs for all watchers...........800,000,000
Bytes for all watchers................408,000,000,000
** Steady State Messages
(S01) NOTIFY msgs due to state change
per watched presentity per day.....................46
(S02) 200 (for NOTIFY due to state change) msgs
per watched presentity per day.....................46
(S03) Total number and size of msgs due to state change per day
Number of msgs for all watchers........18,400,000,000
Bytes for all watchers.............11,224,000,000,000
(S04) Number of SUBSCRIBE msgs for refreshes
per watcher per day................................70
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
per watcher per day................................70
(S06) Number of NOTIFY msgs for refreshes
per watcher per day................................70
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
per watcher per day................................70
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
Number of msgs for all watchers per day.5,600,000,000
Bytes for all watchers per day......2,856,000,000,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers........24,000,000,000
Bytes for all watchers.............14,080,000,000,000
** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher.................10
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........10
(T03) Terminating NOTIFY msgs per watcher....................10
(T04) Terminating 200 OK msgs (NOTIFY) per watcher...........10
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers.................90,000,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers.................74,000,000,000
(T07) Total number & bytes of terminating NOTIFY msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers................170,000,000,000
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers.................74,000,000,000
(T09) Total number & bytes of terminating messages per day
Number of msgs for all watchers...........800,000,000
Bytes for all watchers................408,000,000,000
** Bottom Line
(B01) Total of messages between domains..........25,600,000,000
Total of bytes bet. domains (PD=350)...14,896,000,000,000
Total of bytes bet. domains (PD=3000)..44,046,000,000,000
(B02) Total number of messages / second.................888,889
Total of bytes per second (PD=350)............517,222,222
Total of bytes per second (PD=3000).........1,529,375,000
(B03) Total number of by msgs per user/day................1,280
Total number of bytes per user/day (PD=350).......744,800
Total number of bytes per user/day (PD=3000)....2,202,300
]]></artwork></figure>
<figure title="Large network peering with optimizations" anchor="fig08">
<artwork><![CDATA[
** Constants
(C01) Subscription lifetime (hours)...........................8
(C02) Presence state changes / hour...........................6
(C03) Subscription refresh interval / hour....................1
(C04) Total federated presentities per watcher...............10
(C05) Number of dialogs to maintain per watcher...............1
(C06) Total number of watchers in domains............20,000,000
(C07) SUBSCRIBE message size in bytes.......................450
(C08) 200 OK for SUBSCRIBE message size in bytes............370
(C09) NOTIFY message size not including presence doc........500
(C10) 200 OK for NOTIFY message size in bytes...............370
(C11) Size of an average presence document..................350
(C13) Additional data per document in RLMI..................160
(C14) Multiparty boundary in RLMI document..................144
(C15) XML root node in RLMI document........................144
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher......................1
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1
(I03) Initial NOTIFY msgs per watcher.........................1
(I04) Initial 200 OK msgs (NOTIFY) per watcher................1
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers..................9,000,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers..................7,400,000,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers................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
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
]]></artwork></figure>
</section>
<section title="Intra-domain peering">
<t>Within a particular domain, multiple presence infrastructures are
deployed, with users split between them. 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 that has deployed multiple,
independent-vendor presence solutions (for example, a presence solution
for desktop messaging deployed alongside a presence solution for IP
telephony).</t>
<t>Common characteristics of this deployment are these:</t>
<t><list style="symbols">
<t>The differences between subscriptions to presentities in one system versus
the other are completely arbitrary. Any one presentity is as likely to
be homed on one infrastructure as on the other.</t>
<t>Active users are almost guaranteed to subscribe to many users in the
peer infrastructure.</t>
<t>The level of intersection of presentities is extremely high.</t>
</list></t>
<t>The first table below provides the calculations without optimizations.
The second table provides the calculations with optimization. Although
relatively conservative numbers are used, the number of
messages is still high even though optimization may cut the
traffic by more than half. </t>
<figure title="Intra-domain peering with no optimizations" anchor="fig09">
<artwork><![CDATA[
** Constants
(C01) Subscription lifetime (hours)...........................8
(C02) Presence state changes / hour...........................3
(C03) Subscription refresh interval / hour....................1
(C04) Total federated presentities per watcher...............10
(C05) Number of dialogs to maintain per watcher..............10
(C06) Total number of watchers in domains...............120,000
(C07) SUBSCRIBE message size in bytes.......................450
(C08) 200 OK for SUBSCRIBE message size in bytes............370
(C09) NOTIFY message size not including presence doc........500
(C10) 200 OK for NOTIFY message size in bytes...............370
(C11) Size of an average presence document..................350
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher.....................10
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher............10
(I03) Initial NOTIFY msgs per watcher........................10
(I04) Initial 200 OK msgs (NOTIFY) per watcher...............10
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers.............1,200,000
Bytes for all watchers....................540,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers.............1,200,000
Bytes for all watchers....................444,000,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers.............1,200,000
Bytes for all watchers..................1,020,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
Number of msgs for all watchers.............1,200,000
Bytes for all watchers....................444,000,000
(I09) Total number & bytes of initial messages per day
Number of msgs for all watchers.............4,800,000
Bytes for all watchers..................2,448,000,000
** Steady State Messages
(S01) NOTIFY msgs due to state change
per watched presentity per day.....................22
(S02) 200 (for NOTIFY due to state change) msgs
per watched presentity per day.....................22
(S03) Total number and size of msgs due to state change per day
Number of msgs for all watchers............52,800,000
Bytes for all watchers.................32,208,000,000
(S04) Number of SUBSCRIBE msgs for refreshes
per watcher per day................................70
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
per watcher per day................................70
(S06) Number of NOTIFY msgs for refreshes
per watcher per day................................70
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
per watcher per day................................70
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
Number of msgs for all watchers per day....33,600,000
Bytes for all watchers per day.........17,136,000,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers............86,400,000
Bytes for all watchers.................49,344,000,000
** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher.................10
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........10
(T03) Terminating NOTIFY msgs per watcher....................10
(T04) Terminating 200 OK msgs (NOTIFY) per watcher...........10
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
Number of msgs for all watchers.............1,200,000
Bytes for all watchers....................540,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers.............1,200,000
Bytes for all watchers....................444,000,000
(T07) Total number & bytes of terminating NOTIFY msgs
Number of msgs for all watchers.............1,200,000
Bytes for all watchers..................1,020,000,000
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
Number of msgs for all watchers.............1,200,000
Bytes for all watchers....................444,000,000
(T09) Total number & bytes of terminating messages per day
Number of msgs for all watchers.............4,800,000
Bytes for all watchers..................2,448,000,000
** Bottom Line
(B01) Total of messages between domains..............96,000,000
Total of bytes between domains (PD=350)....54,240,000,000
Total of bytes between domains (PD=3000)..152,820,000,000
(B02) Total number of messages / second...................3,333
Total of bytes per second (PD=350)..............1,883,333
Total of bytes per second (PD=3000).............5,306,250
B(03 )Total number of by msgs per user/day..................800
Total number of bytes per user/day (PD=350).......452,000
Total number of bytes per user/day (PD=3000)....1,273,500
]]></artwork></figure>
<figure title="Intra-domain peering with optimizations" anchor="fig10">
<artwork><![CDATA[
** 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
(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
]]></artwork></figure>
</section>
</section>
<section title="Partial Notifications Optimization">
<t>RFC 5263 <xref target="RFC5263"/> defines a way for the
watcher to request getting only what was changed in the presence document. The
following calculation shows the bandwidth saved in the large
peering network case when we add partial notification to the
dialog and NOTIFY optimizations. It is assumed that, except for the initial NOTIFY,
all 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.</t>
<figure title="Large networks peering with NOTIFY and partial optimizations" anchor="fig11">
<artwork><![CDATA[
** Constants
(C01) Subscription lifetime (hours)...........................8
(C02) Presence state changes / hour...........................6
(C03) Subscription refresh interval / hour....................1
(C04) Total federated presentities per watcher...............10
(C05) Number of dialogs to maintain per watcher..............10
(C06) Total number of watchers in domains............20,000,000
(C07) SUBSCRIBE message size in bytes.......................450
(C08) 200 OK for SUBSCRIBE message size in bytes............370
(C09) NOTIFY message size not including presence doc........500
(C10) 200 OK for NOTIFY message size in bytes...............370
(C11) Size of an average presence document..................350
(C12) Size of an average partial presence document..........200
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher.....................10
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher............10
(I03) Initial NOTIFY msgs per watcher........................10
(I04) Initial 200 OK msgs (NOTIFY) per watcher...............10
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers.................90,000,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers..................74,00,000,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers................170,000,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers..................74,000,000,000
(I09) Total number & bytes of initial messages per day
Number of msgs for all watchers...........800,000,000
Bytes for all watchers................408,000,000,000
** Steady State Messages
(S01) NOTIFY msgs due to state change
per watched presentity per day.....................46
(S02) 200 (for NOTIFY due to state change) msgs
per watched presentity per day.....................46
(S03) Total number and size of msgs due to state change per day
Number of msgs for all watchers........18,400,000,000
Bytes for all watchers..............9,844,000,000,000
(S04) Number of SUBSCRIBE msgs for refreshes
per watcher per day................................70
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
per watcher per day................................70
(S06) Number of NOTIFY msgs for refreshes
per watcher per day.................................0
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
per watcher per day.................................0
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
Number of msgs for all watchers per day.2,800,000,000
Bytes for all watchers per day......1,148,000,000,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers........21,200,000,000
Bytes for all watchers.............10,992,000,000,000
** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher.................10
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........10
(T03) Terminating NOTIFY msgs per watcher.....................0
(T04) Terminating 200 OK msgs (NOTIFY) per watcher............0
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers.................90,000,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers.................74,000,000,000
(T07) Total number & bytes of terminating NOTIFY msgs
Number of msgs for all watchers.....................0
Bytes for all watchers..............................0
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
Number of msgs for all watchers.....................0
Bytes for all watchers..............................0
(T09) Total number & bytes of terminating messages per day
Number of msgs for all watchers...........400,000,000
Bytes for all watchers................164.000,000,000
** Bottom Line
(B01) Total of messages between domains..........22,400,000,000
Total of bytes bet. domains (PD=350)...11,564,000,000,000
Total of bytes bet. domains (PD=3000)..12,094,000,000,000
(B02) Total number of messages / second.................777,778
Total of bytes per second (PD=350)............401,527,778
Total of bytes per second (PD=3000)...........419,930,556
(B03) Total number of by msgs per user/day................1,120
Total number of bytes per user/day (PD=350).......578,200
Total number of bytes per user/day (PD=3000)......604,700
]]></artwork></figure>
</section>
<section title="Extremely Optimized SIP">
<t>SIP is a network-agnostic protocol, therefore, the protocol carries
additional messages like "200 OK" that would be redundant in a
protocol that is TCP-based only.</t>
<t>The following calculation assumes an imaginary TCP-only version of SIP that optimizes the following:</t>
<t><list style="symbols">
<t>There is no "200 OK" for each message. because only TCP would be supported, there is no need to compensate
for issues arising with other transport protocols.</t>
<t>There is no refresh for subscriptions.</t>
<t>There is no NOTIFY upon termination of the subscription.</t>
<t>The size of each message is smaller, because there is no need for the various header fields that SIP uses for routing,
etc. So we need to assume smaller message sizes, while keeping the size of
the presence document the same.</t>
</list></t>
<t>As noted above, the calculations in this document do not assume offline
means of receiving presence information. Therefore, in addition
to the above optimizations, the other optimizations that were assumed in
the document are assumed here also. These includes partial
notifications and dialog optimizations. The NOTIFY optimization is not
relevant here, because there are no refreshes of subscriptions.</t>
<t>The following is a calculation for the large network peering scenario
assuming an imaginary TCP-only SIP. It is 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.</t>
<figure title="Large networks peering, TCP only SIP+Partial+Dialog optimizations" anchor="fig12">
<artwork><![CDATA[
** 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
(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
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
]]></artwork></figure>
<figure title="Large networks peering, TCP only SIP+Partial optimizations" anchor="fig18">
<artwork><![CDATA[
** Constants
(C01) Subscription lifetime (hours)...........................8
(C02) Presence state changes / hour...........................6
(C03) Subscription refresh interval / hour....................0
(C04) Total federated presentities per watcher...............10
(C05) Number of dialogs to maintain per watcher..............10
(C06) Total number of watchers in domains............20,000,000
(C07) SUBSCRIBE message size in bytes.......................150
(C08) 200 OK for SUBSCRIBE message size in bytes..............0
(C09) NOTIFY message size not including presence doc........150
(C10) 200 OK for NOTIFY message size in bytes.................0
(C11) Size of an average presence document..................350
(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
** 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
]]></artwork></figure>
</section>
</section>
<section title="State Management">
<t>In previous sections, we discussed the large number of messages that need to
be sent to/from a presence server. In this section, we will analyze the state that needs to be
maintained by a presence server and will show it to be far from
trivial.</t>
<t>The presence server has two parallel tasks:</t>
<t><list style="numbers">
<t>Maintain the state of the presentities to which watchers subscribe.</t>
<t>Maintain the state of the subscriptions of watchers and provide timely
updates to the watchers.</t>
</list></t>
<t>For a single subscription from a single watcher on a presentity, the presence
server has to maintain the following state:</t>
<t><list style="symbols">
<t>Subscription state, including all the parameters that are needed to
maintain the subscription as timers.</t>
<t>Optional filtering information that was requested by the watcher, which
includes information needed for filtering. If partial notification is supported for the subscription,
additional information has to be maintained.</t>
<t>Optional rate management information as throttling.</t>
<t>Watcher information (<xref target="RFC3857"/>, <xref target="RFC3858"/>) that
is the result of the subscription, in order to allow watched presentities to know
who is watching them.</t>
</list></t>
<t>For each presentity with subscriptions in the presence server, the presence server has to maintain the
following state:</t>
<t><list style="symbols">
<t>A list of the subscriptions for the presentity. Note that the size calculation
is already handled by the subscription state above.</t>
<t>Authorization information for the presentity.</t>
</list></t>
<t>For each presentity that has published a state other than a default value,
the presence server has to maintain the current value of the presentity's state.</t>
<section title="State Size Calculations">
<t>Let's assume the following sizes:</t>
<t><list style="symbols">
<t>Subscription size - 2K bytes. This includes watcher information that
the presence server creates for each subscription. This is
for every subscription created by a watcher to each presentity that
the watcher is watching. So, if we have 10K watchers, we should have 10K of
these.</t>
<t>Subscribed-to resource - 1K bytes for privacy information and other
management information. This is for each watched presentity, regardless of the number of its watchers.
The subscriptions themselves are
already calculated in the previous bullet.</t>
<t>Resource with a state - 6K bytes. This is a moderate assumption if we
consider the amount of data, including calendar and geographical information, placed in a presence
document by multiple devices. This
is for each presentity, watched or not, that has state other than the default empty state.
</t>
</list></t>
<section title="Tiny System">
<t><list style="symbols">
<t>10K subscriptions = 19M bytes.</t>
<t>5K subscribed-to presentities = 5M bytes.</t>
<t>10K presentities with state = 58M bytes.</t>
</list></t>
<t>Total is 82M bytes.</t>
</section>
<section title="Medium System">
<t><list style="symbols">
<t>100K subscriptions = 195M bytes.</t>
<t>50K subscribed-to presentities = 49M bytes.</t>
<t>100K presentities with state = 586M bytes.</t>
</list></t>
<t>Total is 830M bytes.</t>
</section>
<section title="Large System">
<t><list style="symbols">
<t>6M subscriptions = 11,718M bytes.</t>
<t>3M subscribed-to presentities = 2,929M bytes.</t>
<t>4M presentities with state = 23,437M bytes.</t>
</list></t>
<t>Total is 38G bytes.</t>
</section>
<section title="Larger System">
<t><list style="symbols">
<t>150M subscriptions = 292,969M bytes.</t>
<t>75M subscribed-to presentities = 73,242M bytes.</t>
<t>100M presentities with state = 585,937M bytes.</t>
</list></t>
<t>Total is 952G bytes, which is a large number for dynamic storage as needed by the presence server.</t>
</section>
<section title="Notes on the calculations">
<t>Although the numbers above may seem moderate enough for the sizes that the presence server is
handling, we should consider the following:</t>
<t><list style="symbols">
<t>Dynamic state - Although the state may not seem so large for databases, even for
the larger system, we need to remember that this state is dynamic.
Subscriptions come and go all the time, the statuses of presentities are being
updated, and so forth. This means that the presence server has to manage its
state in a dynamic medium, and for such large sizes, this task is not
trivial.</t>
<t>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 <xref target="RLS"/> about the
interlinkage that is created due to resource lists.</t>
<t>Moderate assumptions - The size assumptions that were made above are quite
moderate. Presence is becoming more a core middleware functionality that holds
much of the user's data. In real life, the numbers above may be even higher, and
the presence server can have additional overhead such as managing the SIP sessions,
networking, and more.</t>
</list></t>
<t>Although the above calculations do not show that there is a real issue with
state management of presence in medium systems or even in large systems, because
state could be divided among different machines, the state
size is still large. A bigger issue with the state involves resource lists,
which create an interlinked state between many servers. In that case, the division of large state to
multiple servers becomes less trivial.</t>
</section>
</section>
</section>
<section title="Processing complexities">
<t>The basic presence paradigm comprises a watcher and a presentity that the
watcher watches. It sounds simple enough, but the presence server has to manage many additions and extensions,
which makes processing complex.</t>
<t>In this section, we show that in addition to the large number of messages and the large state
that the presence server has to handle, it also has to handle quite intensive processing for aggregation,
partial notification and publish, filtering, and privacy. This adds complexity to the presence server on the CPU front in
addition to the network and memory fronts that were described before.</t>
<section title="Aggregation">
<t>A presence document may contain multiple resources. These resources can be devices of
the presentity, information from external providers of presence information such as geographical location, calendars, and more.</t>
<t>The presence server needs to receive the updates from all the resources and
to aggregate them correctly into a single presence document. Although this is just an "XML processing" task,
the number of updates that the presence server may receive, 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.</t>
</section>
<section title="Partial Publish and Notify">
<t>Partial notification <xref target="RFC5263"/> and partial publish <xref target="RFC5264"/>
define a way for the watcher to request
notification only on 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 reduce the amount
of the data that is sent from/to the presence server, these optimizations
create additional processing burden on the presence server.</t>
<t>When a partial publish arrives at the presence server, the presence
server has to be able to process the partial publish and change only what is
indicated in the partial publish, while keeping the presence document well-formed
according to the schema.</t>
<t>In partial notification the processing is even more complex, because each
watcher needs to get the partial update based on the last update that was
received by that watcher. Therefore, <xref target="RFC5263"/>
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 notification.</t>
</section>
<section title="Filtering">
<t>Filtering, as defined in RFCs <xref target="RFC4660"/> and <xref
target="RFC4661"/>, enables a watcher to request to be notified only when the
presence document fulfills certain conditions. Although this is a
convenient feature for watchers, the burden put on the presence server
is quite large. For each change in the presence document, the presence server
needs to compute the filtering expressions, which can be complex, and to decide
whether and what to send to the watcher that has requested filtering.</t>
</section>
<section title="Authorization">
<t>RFC <xref target="RFC5025"/> defines presence authorization rules
that allow presentities to specify what each watcher can see in their presence documents.
The processing that the presence server performs here is similar to filtering. When a
presence document with defined authorization rules changes, the presence server
creates different notifications for different watchers according to those rules.</t>
</section>
<section anchor="RLS" title="Resource List Service">
<t>RFC <xref target="RFC4662"/> defines a way to subscribe to a single URI
that represents a list of resources that are subscribed to by a
single subscription. Although this quite useful mechanism
significantly reduces 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 complicate the scaling of presence systems.</t>
<t>The reasons that resource lists may make the scaling of the
presence server even more complex are these:</t>
<t><list style="symbols">
<t>Subscriptions and state - The resource list may contain references 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
so that it can provide the full state of the presentities in the list
when needed. So in the overall system, the number of subscriptions reduced between
the watcher and the presence server is moved to the backend system, while state
is duplicated among the various presence servers that serve the various
presentities and the RLSs. This issue could have been mitigated if there were 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.</t>
<t>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 creates a complex linkage among the states of many
components. This linkage makes state management and other
maintenance of presence systems quite complex.</t>
<t>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 be cautious when creating public groups, this may
not be the case in real life. The connection between the size of the public
group and the load on the presence system may not be apparent to everyone.
Furthermore, many public groups may have been
created for other purposes, such as email systems (where the size of the lists is not
as important), and are now used in the presence systems. For example,
a public group including all the users in
the enterprise is used by many users in the enterprise, thus overwhelming
the presence server. Note that this is not a protocol or design
issue, but more a usage issue that may have a real impact on the presence
system.</t>
<t>Stopping notifications - A watcher may accidentally subscribe to an extensive list
and be overwhelmed by the number of NOTIFYs that it receives from the presence
server. There is no current way to stop this stream of NOTIFYs, and even
canceling the subscription may take time before being effective.</t>
</list></t>
<t>These issues show how an optimization can help in
one part of the system, but create even bigger problems in the overall system.
There is a need to think about the problems listed above, but, more than that,
there is a need to make sure that introducing an optimization does not
create issues in other places.</t>
</section>
</section>
<section title="Current Optimizations">
<t>This section highlights several optimizations that either are
already part of SIP or 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 <xref target="I-D.houri-simple-interdomain-scaling-optimizations" />
and in <xref target="I-D.ietf-simple-view-sharing"/>. Note that
trials with batched NOTIFYs optimization, described in <xref target="I-D.houri-simple-interdomain-scaling-optimizations" />,
showed an improvement
of 117% in the whole throughput of presence traffic.</t>
<t><list style="symbols">
<t>Subnot-etags - <xref target="I-D.ietf-sipcore-subnot-etags"/>. This draft
suggests ways to suppress the sending of unnecessary NOTIFYs when, for example, a
subscription is refreshed. This suggestion seems to be an efficient
optimization, because it reduces both the number of messages sent and the
processing time of the presence server.</t>
<t>Resource List Service - <xref target="RFC4662"/> enables creating a single subscription
session between the watcher and the presence server for subscribing to a list of users.
This reduces the number of sessions that are created between watchers and presence servers.
However, this mechanism enables creating large numbers of subscriptions in the
presence server/RLS system, thus enabling the creation of a 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 consolidated
subscriptions below.</t>
<t>Partial notify/publish - <xref target="RFC5263"/> and
<xref target="RFC5264"/> 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
reduce the amount of actual data sent from/to the presence server,
these optimizations create additional processing burden on the presence
server, as was discussed above.</t>
<t>Filtering, as defined in <xref target="RFC4660"/> and <xref
target="RFC4661"/>, enables a watcher to request to be notified only when the
presence document fulfills certain conditions. Although this optimization
reduces the number of messages that are sent from the presence server to the watcher, this
optimization burdens the processing time of the presence server, as
was discussed above.</t>
<t>Throttling - <xref target="I-D.ietf-sipcore-event-rate-control" /> defines a
mechanism by which a watcher requests updates only at certain intervals.
Although this mechanism may add some extra load on the
presence server, that load is negligible and the reduction of the number of
messages sent from the presence server to the watchers is significant. This
optimization is even more important with resource lists, which can contain many
resources, because the watcher may receive a large number of notifications
if the traffic caused by updates on resource list is not regulated.</t>
<t>Presence-specific SigComp dictionary - <xref target="RFC5112"/>
defines a SigComp <xref target="RFC3320"/> dictionary for
presence. This optimization reduces the number of bytes that are
transferred in presence systems by compressing the textual SIP messages. By using
the specialized presence dictionary, the compression may be more significant than
just using SigComp as-is. Note that number of actual messages will remain the
same, and a calculation of the number of bytes that will be saved may be
useful here.</t>
<t>Content Indirection - <xref target="RFC4483"/> enables the sending of only the URI of the
presence document to the watcher, thus relieving the presence server from sending the entire
presence document to the watcher. This optimization may be useful in some cases, especially when
a large number of users receive the same presence document.</t>
</list></t>
</section>
<section title="Summary">
<t>The following summary of the various calculations is provided here
to help support the conclusions listed below.</t>
<t>The following table summarizes the constants that are used in ALL calculations:</t>
<figure title="Constants in ALL calculations" anchor="fig13">
<artwork><![CDATA[
(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
]]></artwork></figure>
<t>The following table summarizes the results of various optimization factors for the basic use case.</t>
<figure title="Basic use case" anchor="fig14">
<artwork><![CDATA[
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
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
]]></artwork></figure>
<t>The following table summarizes the results of various optimization factors
for the widely distributed inter-domain use case.</t>
<figure title="Widely distributed inter-domain" anchor="fig15">
<artwork><![CDATA[
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
]]></artwork></figure>
<t>The following table summarizes the results of various optimization factors
for the intra-domain peering use case.</t>
<figure title="Inter-domain peering" anchor="fig16">
<artwork><![CDATA[
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
]]></artwork></figure>
<t>The following table summarizes the results of various optimization factors for the large-scale peering networks use case.</t>
<figure title="Large scale peering networks" anchor="fig17">
<artwork><![CDATA[
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
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
]]></artwork></figure>
</section>
<section title="Conclusions">
<t>The following conclusions can be drawn from the above numbers:</t>
<t><list style="symbols">
<t>Due to the overhead of RLMI, the dialog optimization does not help reduce the number of
bytes nor the number of the messages. It seems to be more important from the
point of view of the user, because it enables convenient management of
his/her watch list on, for example, a web page.</t>
<t>The notify optimization significantly reduces both the number of messages and the number
of bytes.</t>
<t>Partial notification saves a large number of bytes, especially when the
presence document is a rich presence document, which is relatively large.</t>
<t>Extremely optimized SIP (imaginary TCP-only SIP) cuts the
number of messages by about half. The number of bytes is also reduced
by about half.</t>
<t>From the perspective of the number of bytes that
a user "consumes" per day, the numbers may not look so large. Nevertheless, we
should remember that the overall effect on the network may be quite large, because
the network will have to convey dozens of gigabytes of presence traffic per day for the modest
use cases that are described in this document. Recalling
that presence is only an enabler for other media, these numbers are not so easy
to handle.</t>
</list></t>
<t>This document analyzes the scalability of presence systems in general and of SIP-based presence systems
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.</t>
<t>As part of the analysis, we assessed 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.</t>
<t>We have also computed the number of messages and bytes for a large-scale
peering network while assuming a protocol that has much less overhead than SIP.
Even with that protocol, we calculated relatively high numbers.</t>
<t>It is possible that the issues 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 large systems. However, it is apparent that not all the
possible optimizations have been done yet, and further work is needed in the IETF in
order to provide better scalability.</t>
<t> Nevertheless, we should remember that SIP was originally designed for end-to-end session creation, and that the number and size of messages are of secondary importance
for end-to-end session negotiation. For large scale and especially for
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 hard to scale.</t>
<t>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 extremely
optimized for the load and that can make some assumptions about the network (for example,
use only TCP, and not an unreliable protocol such as UDP).</t>
<t>When a server connects to another server using the current protocol, there
will be an extreme number of redundant messages due to the overhead of
supporting UDP and the need to send multiple presence documents for the same
watched user due to privacy issues. A server-to-server protocol will have to
address these issues. Some initial work to address these issues can be found in
<xref target="I-D.houri-simple-interdomain-scaling-optimizations" />, <xref
target="I-D.ietf-simple-view-sharing"/> and <xref target="I-D.ietf-simple-intradomain-federation"/></t>
<t>Another issue that concerns protocol design is whether NOTIFY
messages should be considered as media, the way audio, video and even text
messaging are considered. The SUBSCRIBE method can be extended to create a three-way
handshake similar to INVITE, and negotiate where the NOTIFY messages should go, rate, and
other parameters. This way, the load can be shifted to specialized NOTIFY
"relays", and taken off the control path of SIP. One of the possible ideas
(due to 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 (<xref target="RFC4975"/>,
<xref target="RFC4976"/>) protocol for the NOTIFYs.</t>
</section>
<section title="Security Considerations">
<t>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, many of the possible
optimizations that should emerge as a result of this document will have
security implications that will need to be solved.</t>
</section>
<section title="IANA Considerations">
<t>This document has no actions for IANA.</t>
</section>
<section title="Changes from Previous Versions">
<section title="Changes in version 07">
<t>Added clarifications, fixed typos and language usage issues raised during the IETF last call.</t>
</section>
<section title="Changes in version 06">
<t>Updated to conform with new IETF IPR boilerplate and updated references.</t>
</section>
<section title="Changes in version 05">
<t><list style="symbols">
<t>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.</t>
<t>Fixed nits that were referred to me by Robert Sparks</t>
</list></t>
</section>
<section title="Changes in version 04">
<t><list style="symbols">
<t>Fixed mistake in the formula of I07 and S08 (RLMI was not included).
Effect on total number of bytes was infitesimile.</t>
<t>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, because the
excel file calculations were done correctly.</t>
<t>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.</t>
<t>Several other editorial and clarification changes</t>
</list></t>
</section>
<section title="Changes in version 03">
<t><list style="symbols">
<t>Added some input from real life deployments and input on a test with batched notifies.</t>
<t>Added Calculations of messages and bytes per user.</t>
<t>Calculations are now done both for minimal size of presence document and for an average size of rich presence document.</t>
<t>Comparison with other protocol is now done using small, tiny and rich presence document sizes.</t>
<t>Removed dialog optimization with partial notification, because it is not relevant</t>
<t>Fixed a few issues in calculations that were found by Victoria Beltran-Martinez:</t>
<t><list style="symbols">
<t>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.</t>
<t>When NOTIFY optimizations are applied no need for final NOTIFY</t>
<t>The usage of RLS between domains was clarified.</t>
</list></t>
<t>Significantly enhanced the conclusions section</t>
<t>Several typo fixes</t>
</list></t>
</section>
<section title="Changes in version 02">
<t><list style="symbols">
<t>Fixed a bug in the calculations. Thanks to Marc Willekens for finding the bug.</t>
</list></t>
</section>
<section title="Changes in version 01">
<t><list style="symbols">
<t>Clarifications and corrections of the computation model and the computations.</t>
<t>Added several more computations to show the influence of different optimizations.</t>
<t>The requirements were moved to <xref target="I-D.ietf-sipcore-presence-scaling-requirements" /></t>
<t>The new suggestions for optimizations were moved to <xref target="I-D.houri-simple-interdomain-scaling-optimizations" /></t>
</list></t>
</section>
</section>
<section title="Acknowledgments">
<t>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. Additional special
thanks to A. Jean Mahoney, Joel M. Halpern and Barry Leiba, for their dedicated review as
part of the IETF last call.</t>
</section>
</middle>
<back>
<references title="Informational References">
<?rfc include="reference.RFC.3320" ?>
<?rfc include="reference.RFC.3857" ?>
<?rfc include="reference.RFC.3858" ?>
<?rfc include="reference.RFC.3863" ?>
<?rfc include="reference.RFC.4480" ?>
<?rfc include="reference.RFC.4483" ?>
<?rfc include="reference.RFC.4660" ?>
<?rfc include="reference.RFC.4661" ?>
<?rfc include="reference.RFC.4662" ?>
<?rfc include="reference.RFC.4975" ?>
<?rfc include="reference.RFC.4976" ?>
<?rfc include="reference.RFC.5263" ?>
<?rfc include="reference.RFC.5264" ?>
<?rfc include="reference.RFC.5025" ?>
<?rfc include="reference.RFC.5112" ?>
<?rfc include="reference.RFC.5367" ?>
<?rfc include="reference.I-D.ietf-sipcore-subnot-etags" ?>
<?rfc include="reference.I-D.ietf-sipcore-presence-scaling-requirements" ?>
<?rfc include="reference.I-D.houri-simple-interdomain-scaling-optimizations" ?>
<?rfc include="reference.I-D.ietf-sipcore-event-rate-control" ?>
<?rfc include="reference.I-D.ietf-simple-view-sharing" ?>
<?rfc include="reference.I-D.ietf-simple-intradomain-federation" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 04:38:15 |