One document matched: draft-ietf-simple-interdomain-scaling-analysis-02.xml
<?xml version="1.0" encoding="UTF-8"?>
<rfc category="info" ipr="full3978" docName="draft-ietf-simple-interdomain-scaling-analysis-02.txt">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="no" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<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
Building 18/D</street> <city>Rehovot</city> <region></region> <code></code>
<country>Israel</country> </postal> <email>avshalom@il.ibm.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="E." surname="Aoki" fullname="Edwin Aoki">
<organization>AOL LLC</organization> <address> <postal> <street>360 W. Caribbean
Drive</street> <city>Sunnyvale</city> <region>CA</region> <code>94089</code>
<country>USA</country> </postal> <email>aoki@aol.net</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="July" year="2007"/> <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>The document analyses the traffic that is generated due to presence
subscriptions between domains. It is shown that the amount of traffic can be
extremely big. In addition to the very large traffic the document also analyses
the affects of a large presence system on the memory footprint and the CPU load.
Current approved and in work optimizations to the SIMPLE protocol are analysed with the
possible impact on the load. Separate documents contain the requirements for optimizations and suggestions
for new optimizations.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The document analyses the traffic that is generated due to presence
subscriptions between domains. It is shown that the amount of traffic can be
extremely big. In addition to the very large traffic the document also analyses
the affects of a large presence system on the memory footprint and the CPU load.
Current approved and in work optimizations to the SIMPLE protocol are analysed
with the possible impact on the load. Separate documents contain the
requirements for optimizations <xref target="I-D.houri-sipping-presence-scaling-requirements" />
and suggestions for new optimizations <xref target="I-D.houri-simple-interdomain-scaling-optimizations" />.</t>
<t>This document is intended to be used by the SIMPLE WG in order to work on
possible solutions that will make the deployment of a presence server more
reasonable task. Note that the document does not try to compare the SIP based
presence server to other types of presence servers but only analyses the SIP
based presence server. It is very likely that similar scalability issues are
inherent to the deployment of presence systems and not to a certain
protocol.</t>
<t>The document discusses the following areas. In each area we try to show the
complexity and the load that the presence server has to handle in order to
provide its service.</t>
<t><list style="symbols">
<t>Messages load - By computing the number of messages that are required for
connecting presence systems the document shows that the number of messages is
very big and it is quite obvious that some optimizations are needed. In addition
we also show that the bandwidth required is also very big.</t>
<t>State management - Due to the nature of the service that the presence server
provides, the presence server has to manage a relatively big and complex state
and some computations are provided in the document.</t>
<t>Processing complexities - The presence server maintains many small objects
and has to do frequent operations on these objects. We show that these
operations and especially the optimizations that are intended to save on the
amount of data that is being sent between watchers and presence servers, are not
so simple and may create a very heavy processing load on the presence
server.</t>
<t>Groups - Resource List Servers <xref target="RFC4662"/> optimize the number
of sessions that are created between the watchers and the presence server. On
the other hand, this optimization may create an exponential size of subscription
due to the unbearable ease of subscribing to large groups.</t>
</list></t>
<t>The term presence domain or presence system appears in the document several
time. By this term we refer to a presence server that provides presence
subscription and notification services to its users. The system can be a system
that is deployed in a small enterprise or in a very large consumer network.</t>
</section>
<section title="Message Load">
<t>Even though some optimizations are approved or are being defined, we show in
this section that a very large number of messages & large bandwidth are needed
in order to establish federation between presence systems of large communities.
Further thinking is needed in order to make large deployment of presence systems
less resource demanding.</t>
<t>Note that even though this document talks about inter domain traffic, the
introduction of resource list servers (RLSs) <xref target="RFC4662"/> introduce
very similar traffic pattern within a domain as between domains. See detailed
discussion on resource lists in <xref target="RLS"/>.</t>
<section title="Known Optimizations">
<t>The current optimizations that are approved or are approved as working group items
in the SIMPLE working group can be divided into two categories:</t>
<t><list style="symbols">
<t>Dialogs saving optimization - Here we refer to optimizations as the
resource list RFC <xref target="RFC4662"/> or to the Uri list subscriptions
draft <xref target="I-D.ietf-sipping-uri-list-subscribe"/>. These documents
define ways to reduce the number of dialogs that are required between the
subscriber and the presence system.</t>
<t>Notification optimizations - Here we refer to the optimizations that are
suggested in the subnot-etags draft <xref target="I-D.ietf-sip-subnot-etags"/>.
This draft suggests ways to suppress the sending of unnecessary
notifies when for example a subscription is refreshed. There are other drafts
that reduce the size of messages as partial notifies or filtering but in this
document we mostly care about the amount of messages & bandwidth so the partial
optimizations can help a bit in the bandwidth but will not help in the number of messages.</t>
</list></t>
</section>
<section title="Assumptions">
<t>In the document we have several assumptions regarding size of messages, rate
of presence change and more. It should be noted that these assumptions are not
directly based on rigorous statistics that was done on actual SIP based messages
but more from experience on other types of presence based systems.</t>
<t>Even though the assumptions in this document are not based on rigorous
statistical data the target here is not to analyse specific system but show that
even with VERY moderate assumptions, the number of messages, the network
bandwidth, the required state management and the load on the CPU is very high.
Real life systems should have a much bigger scalability requirements. for
example the presence state change that we assumed (one presence state change
per hour) is maybe one of the most moderate assumptions that we have taken.
Experience from consumer networks show that the frequency here is much bigger
and especially with the younger generation. In an environment where a user
may have several devices and other resources for
presence information as geographical location and calendar the frequency of
presence state changes will be much higher.</t>
<t>It is very hard to measure presence load since the behavior of users is very
different. Some users will have a very small number of presentities in their
watch list while others may have hundreds. Some users will change their state a
lot and have many sources of presence information while others may have very
small number of changes during the day. In addition the "rush hour"
calculation of when the day starts and ends was not included yet in this document yet (to be added). Rush hour
differs between different enterprises and is still different in the consumer
presence systems. It is very hard if not impossible to take into a static model
all the possible combinations.</t>
<t>Saying the above, there are still several things to be done to create a more
complete picture:</t>
<t><list style="symbols">
<t>Get rigorous statistical data that can be formally published from real presence systems.</t>
<t>Add to the model the possibility of having multiple sources of presence data per presentity and change calculations accordingly</t>
<t>Add "rush hour" calculations for the end and the beginning of the day</t>
</list></t>
<t>The authors will especially appreciate any input in this area that will help
us to create a more real life model. We intend to try and gather more data and
improve the assumptions and the model in the next revisions of this
document.</t>
</section>
<section title="Analysis">
<t>The basic SIMPLE 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 SIMPLE 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 number of "constants" that we use in the calculations. Some of the
constants are used throughout the calculation while other 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.</t>
<t>(C02) Presence state changes / hour - The average time that a presentity
changes his/hers status in one hour. We assumed 3 times per hour for most
calculations. Note that for some users in consumer messaging systems, the actual
number of changes is likely to be much higher.</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 A04, 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 SUBSCIRBE 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. The size is assumed to be 3000
bytes based on sizes from examples in RFCs. Note that assuming 3000 bytes for
presence document is relatively modest if we take into account multiple devices
and location information. When there will be multiple presentities in the same
NOTIFY as in the initial NOTIFY for a resource list <xref target="RFC4662"/> or
there is less information in the presence document due to partial notifications
these factors will be taken into account.</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 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, Bytes - (I03*C06*C09)+((C04/C05)*C11). The calculation of the
size is a bit complicates since it takes into account the case where the
optimization of resource lists is used and there is a single NOTIFY with all the
presentities for the single subscription.</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 the steady state messages. In steady state
we mean the time between the initial subscription and the tear down of the
subscription. It contains the notifies due to state change and the subscription refreshes.</t>
<t><list style="symbols">
<t>(S01) NOTIFY messages due to state change per watched presentity per day
(less 2 since the NOTIFY for initial and terminating state is calculated
in the initial and terminating calculations) = (C02*C01-2).</t>
<t>(S02) 200 (for NOTIFY due to state change) messages per watched presentity
per day (less 2 since the NOTIFY for initial and terminating state is calculated
in the initial and terminating calculations) = (C02*C01-2).</t>
<t>(S03) Total number and size of messages due to state change per day = Number
- (S01+S02)*C06*C04, Bytes - ((S01*C06*C04*(C09+C11)) + (S02*C06* C04*C10)).</t>
<t>(S04) Number of SUBSCRIBE messages for refreshes per watcher per day =
((C01/C03)-1)*C05. One is subtracted since the termination is calculated
separately. for example if there are 8 hours in the day and a refresh should
occur every hour, there are 7 refreshes during the day and not 8.</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.</t>
<t>(S07) Number of 200 OK messages for NOTIFY messages for refreshes per watcher per day =
((C01/C03)-1)*C05.</t>
<t>(S08) Total number and size of messages due to SUBSCRIBE refreshes per day =
Number - (S04+S05+S06+S07)*C06, Size - SUBSCIRBE bytes (S04*C06*C07) +
OK for SUBSCRIBE bytes (S05*C06*C08) + NOTIFY bytes
(S06*C06*(C09+((C04/C05)*C11))) + OK for NOTIFY (S07*C06*C08). The
calculation of the size is a bit complicates since it takes into account the
case where the optimization of resource lists is used and there is a single
NOTIFY with all the presentities for the single subscription. Note that a full
state should be given in SUBSCRIBE refreshes in resource lists. See section 4.5
in <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>
<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 of the subscriptions. The calculations contain both 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.</t>
<t>(T04) Number of terminating 200 OK messages for NOTIFY messages per watcher = C05.</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, Bytes - (T03*C06*(C09+C11). It is assumed that there will be
a single presence document in the terminating NOTIFY.</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 the total number of messages and bytes
per day and per second that will be sent on the link between the federating
domains.</t>
<t><list style="symbols">
<t>(B01) Total number of message and bytes during the day = Number - numbers in
I09+S09+T09, Bytes - sizes in I09+S09+T09.</t>
<t>(B02) Total number of message and bytes per second = Number - number in
B01/(C01*3600) Bytes - size in B01/(C01*3600).</t>
</list></t>
</section>
<section title="Rush Hour Calculations">
<t>The way that the calculations are built it is relatively easy to see the
affect of rush hours at the beginning and the end of the day. for the beginning
of the day we should look at the numbers of "(I09) Total number and bytes of
initial messages per day" and for the end of the day we should look at the
number of "(T09) Total number and bytes of terminating messages per day". Taking
these numbers with some assumed percentage of the numbers of users that log in
at the same hour should give good indication for the rush hour load.</t>
</section>
</section>
<section title="SIMPLE with no optimizations">
<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 SIMPLE protocols without any proposed
optimizations. In this example, there are two presence domains with total of 40,000
federating users with an average of 4 contacts in the peer domain</t>
<figure title="SIMPLE with no optimizations"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................3,000
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher......................4
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............4
(I03) Initial NOTIFY msgs per watcher.........................4
(I04) Initial 200 OK msgs (NOTIFY) per watcher................4
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers.....................72,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers.....................59,200,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers....................560,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers.....................59,200,000
(I09) Total number & bytes of initial messages per day
Number of msgs for all watchers...............640,000
Bytes for all watchers....................750,400,000
** Steady State Messages
(S01) NOTIFY msgs due to state change
per watched presentity per day.....................22
(S02) 200 (for NOTIFY due to state change) msgs
per watched presentity per day.....................22
(S03) Total number and size of msgs due to state change per day
Number of msgs for all watchers.............7,040,000
Bytes for all watchers.................13,622,400,000
(S04) Number of SUBSCRIBE msgs for refreshes
per watcher per day................................28
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
per watcher per day................................28
(S06) Number of NOTIFY msgs for refreshes
per watcher per day................................28
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
per watcher per day................................28
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
Number of msgs for all watchers per day.....4,480,000
Bytes for all watchers per day..........5,252,800,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers............11,520,000
Bytes for all watchers.................18,875,200,000
** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher..................4
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........4
(T03) Terminating NOTIFY msgs per watcher.....................4
(T04) Terminating 200 OK msgs (NOTIFY) per watcher............4
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
Number of msgs for all watchers.............. 160,000
Bytes for all watchers.....................72,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers.....................59,200,000
(T07) Total number & bytes of terminating NOTIFY msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers....................560,000,000
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers.....................59,200,000
(T09) Total number & bytes of terminating messages per day
Number of msgs for all watchers...............640,000
Bytes for all watchers....................750,400,000
** Bottom Line
(B01) Total number of message & bytes during the day
Number of msgs.............................12,800,000
Bytes..................................20,376,000,000
(B02) Total number of message & bytes per second
Number of msgs....................................444
Bytes.........................................707,500
]]></artwork></figure>
</section>
<section title="SIMPLE with dialog optimization">
<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 messages flows are positively affected, the steady state
rates are not.</t>
<figure title="SIMPLE with Dialog optimizations" 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................3,000
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher......................1
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1
(I03) Initial NOTIFY msgs per watcher.........................1
(I04) Initial 200 OK msgs (NOTIFY) per watcher................1
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................18,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................14,800,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers................40,000
Bytes for all watchers....................500,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................14,800,000
(I09) Total number & bytes of initial messages per day
Number of msgs for all watchers...............160,000
Bytes for all watchers....................547,600,000
** Steady State Messages
(S01) NOTIFY msgs due to state change
per watched presentity per day.....................22
(S02) 200 (for NOTIFY due to state change) msgs
per watched presentity per day.....................22
(S03) Total number and size of msgs due to state change per day
Number of msgs for all watchers.............7,040,000
Bytes for all watchers.................13,622,400,000
(S04) Number of SUBSCRIBE msgs for refreshes
per watcher per day.................................7
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
per watcher per day.................................7
(S06) Number of NOTIFY msgs for refreshes
per watcher per day.................................7
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
per watcher per day.................................7
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
Number of msgs for all watchers per day.....1,120,000
Bytes for all watchers per day..........3,833,200,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers.............8,160,000
Bytes for all watchers.................17,455,600,000
** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher..................1
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1
(T03) Terminating NOTIFY msgs per watcher.....................1
(T04) Terminating 200 OK msgs (NOTIFY) per watcher............1
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................18,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................14,800,000
(T07) Total number & bytes of terminating NOTIFY msgs
Number of msgs for all watchers................40,000
Bytes for all watchers....................140,000,000
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................14,800,000
(T09) Total number & bytes of terminating messages per day
Number of msgs for all watchers...............160,000
Bytes for all watchers....................187,600,000
** Bottom Line
(B01) Total number of message & bytes during the day
Number of msgs..............................8,480,000
Bytes..................................18,190,800,000
(B02) Total number of message & bytes per second
Number of msgs....................................294
Bytes.........................................631,625
]]></artwork></figure>
</section>
<section title="SIMPLE with NOTIFY optimization">
<t>The initial analysis of analysis provided in <xref target='fig01'/> is
repeated here with the assumption that the notify optimization is applied.
The optimization saves the need for NOTIFY upon refreshing a SUBSCRIBE if
there was no change since the last NOTIFY. It is assumed here that there
will be no NOTIFY message for a SUBSCRIBE refreshes. As should be expected
this optimization affects the steady state and does not affect the initial
and termination messages.</t>
<figure title="SIMPLE with NOTIFY optimizations" 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................3,000
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher......................4
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............4
(I03) Initial NOTIFY msgs per watcher.........................4
(I04) Initial 200 OK msgs (NOTIFY) per watcher................4
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers.....................72,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers.....................59,200,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers....................560,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers.....................59,200,000
(I09) Total number & bytes of initial messages per day
Number of msgs for all watchers...............640,000
Bytes for all watchers....................750,400,000
** Steady State Messages
(S01) NOTIFY msgs due to state change
per watched presentity per day.....................22
(S02) 200 (for NOTIFY due to state change) msgs
per watched presentity per day.....................22
(S03) Total number and size of msgs due to state change per day
Number of msgs for all watchers.............7,040,000
Bytes for all watchers.................13,622,400,000
(S04) Number of SUBSCRIBE msgs for refreshes
per watcher per day................................28
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
per watcher per day................................28
(S06) Number of NOTIFY msgs for refreshes
per watcher per day.................................0
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
per watcher per day.................................0
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
Number of msgs for all watchers per day.....2,240,000
Bytes for all watchers per day............918,400,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers.............9,280,000
Bytes for all watchers.................14,540,800,000
** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher..................4
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........4
(T03) Terminating NOTIFY msgs per watcher.....................4
(T04) Terminating 200 OK msgs (NOTIFY) per watcher............4
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
Number of msgs for all watchers.............. 160,000
Bytes for all watchers.....................72,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers.....................59,200,000
(T07) Total number & bytes of terminating NOTIFY msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers....................560,000,000
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
Number of msgs for all watchers...............160,000
Bytes for all watchers.....................59,200,000
(T09) Total number & bytes of terminating messages per day
Number of msgs for all watchers...............640,000
Bytes for all watchers....................750,400,000
** Bottom Line
(B01) Total number of message & bytes during the day
Number of msgs.............................10,560,000
Bytes..................................16,041,600,000
(B02) Total number of message & bytes per second
Number of msgs....................................367
Bytes.........................................557,000
]]></artwork></figure>
</section>
<section title="SIMPLE with Dialog & NOTIFY optimizations">
<t>Here both optimizations are combined. In all the other use cases we will show
only the analysis with no optimizations and with both optimizations combined.</t>
<figure title="SIMPLE with Dialog & NOTIFY optimizations" 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................3,000
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher......................1
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1
(I03) Initial NOTIFY msgs per watcher.........................1
(I04) Initial 200 OK msgs (NOTIFY) per watcher................1
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................18,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................14,800,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers................40,000
Bytes for all watchers....................500,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................14,800,000
(I09) Total number & bytes of initial messages per day
Number of msgs for all watchers...............160,000
Bytes for all watchers....................547,600,000
** Steady State Messages
(S01) NOTIFY msgs due to state change
per watched presentity per day.....................22
(S02) 200 (for NOTIFY due to state change) msgs
per watched presentity per day.....................22
(S03) Total number and size of msgs due to state change per day
Number of msgs for all watchers.............7,040,000
Bytes for all watchers.................13,622,400,000
(S04) Number of SUBSCRIBE msgs for refreshes
per watcher per day.................................7
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
per watcher per day.................................7
(S06) Number of NOTIFY msgs for refreshes
per watcher per day.................................0
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
per watcher per day.................................0
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
Number of msgs for all watchers per day.......560,000
Bytes for all watchers per day............229,600,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers.............7,600,000
Bytes for all watchers.................13,852,000,000
** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher..................1
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1
(T03) Terminating NOTIFY msgs per watcher.....................1
(T04) Terminating 200 OK msgs (NOTIFY) per watcher............1
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................18,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................14,800,000
(T07) Total number & bytes of terminating NOTIFY msgs
Number of msgs for all watchers................40,000
Bytes for all watchers....................140,000,000
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................14,800,000
(T09) Total number & bytes of terminating messages per day
Number of msgs for all watchers...............160,000
Bytes for all watchers....................187,600,000
** Bottom Line
(B01) Total number of message & bytes during the day
Number of msgs..............................7,920,000
Bytes..................................14,587,200,000
(B02) Total number of message & bytes per second
Number of msgs....................................275
Bytes.........................................506,500
]]></artwork></figure>
</section>
<section title="Presence Federations">
<t>While these scalability issues exist in any large deployment, certain
characteristics make the deployment conducive to the existing resource-
list optimizations, and others have characteristics that cannot be
exploited with the existing SIMPLE model. Following is a list of
federation relationships that have varying usage characteristics. For
each, a message rate and bandwidth table is provided reflecting typical changes
message rates. Those characteristics can alter the overall
effectiveness of existing optimizations.</t>
<section title="Widely distributed inter-domain presence">
<t>In some environments presence federation may be very common, perhaps
even more common than intra-domain presence. An example of this type of
environment is a small ISV or public server. Users in that small ISV
are not likely to subscribe to the presence of other users in the their
server since they do not necessarily have any relationship with each
other aside from receiving service from the same provider. They are
much more likely to be subscribed to the presence of users in one of the
federated domains (whether in consumer domains, academic, other ISVs,
etc). Common characteristics of this deployment are:</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 (i.e., probability that watchers in the
domain subscribe 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. The
number of watchers in the domain could also be adjusted to account for
an expected larger community of users being peered with, it is omitted
here for simplification</t>
<t>The first table below provides the calculations without optimizations
the second table provides the calculations with optimization. Note that
the number of messages per second decreases by a quarter with the
optimizations but it is still quite big. It is interesting to see that the bandwidth
is almost the quarter of the bandwidth when optimizations are applied.</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................3,000
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher.....................20
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher............20
(I03) Initial NOTIFY msgs per watcher........................20
(I04) Initial 200 OK msgs (NOTIFY) per watcher...............20
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers...............800,000
Bytes for all watchers....................360,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers...............800,000
Bytes for all watchers....................296,000,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers...............800,000
Bytes for all watchers..................2,800,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
Number of msgs for all watchers...............800,000
Bytes for all watchers....................296,000,000
(I09) Total number & bytes of initial messages per day
Number of msgs for all watchers.............3,200,000
Bytes for all watchers..................3,752,000,000
** Steady State Messages
(S01) NOTIFY msgs due to state change
per watched presentity per day.....................22
(S02) 200 (for NOTIFY due to state change) msgs
per watched presentity per day.....................22
(S03) Total number and size of msgs due to state change per day
Number of msgs for all watchers............35,200,000
Bytes for all watchers.................68,112,000,000
(S04) Number of SUBSCRIBE msgs for refreshes
per watcher per day...............................140
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
per watcher per day...............................140
(S06) Number of NOTIFY msgs for refreshes
per watcher per day...............................140
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
per watcher per day...............................140
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
Number of msgs for all watchers per day....22,400,000
Bytes for all watchers per day.........26,264,000,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers............57,600,000
Bytes for all watchers.................94,376,000,000
** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher.................20
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........20
(T03) Terminating NOTIFY msgs per watcher....................20
(T04) Terminating 200 OK msgs (NOTIFY) per watcher...........20
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
Number of msgs for all watchers...............800,000
Bytes for all watchers....................360,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers...............800,000
Bytes for all watchers....................296,000,000
(T07) Total number & bytes of terminating NOTIFY msgs
Number of msgs for all watchers...............800,000
Bytes for all watchers..................2,800,000,000
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
Number of msgs for all watchers...............800,000
Bytes for all watchers....................296,000,000
(T09) Total number & bytes of terminating messages per day
Number of msgs for all watchers.............3,200,000
Bytes for all watchers..................3,752,000,000
** Bottom Line
(B01) Total number of message & bytes during the day
Number of msgs.............................65,000,000
Bytes.................................101,880,000,000
(B02) Total number of message & bytes per second
Number of msgs..................................2,222
Bytes.......................................3,537,500
]]></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................3,000
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher......................1
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1
(I03) Initial NOTIFY msgs per watcher.........................1
(I04) Initial 200 OK msgs (NOTIFY) per watcher................1
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................18,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................14,800,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers................40,000
Bytes for all watchers..................2,420,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................14,800,000
(I09) Total number & bytes of initial messages per day
Number of msgs for all watchers...............160,000
Bytes for all watchers..................2,467,600,000
** Steady State Messages
(S01) NOTIFY msgs due to state change
per watched presentity per day.....................22
(S02) 200 (for NOTIFY due to state change) msgs
per watched presentity per day.....................22
(S03) Total number and size of msgs due to state change per day
Number of msgs for all watchers............35,200,000
Bytes for all watchers.................68,112,000,000
(S04) Number of SUBSCRIBE msgs for refreshes
per watcher per day.................................7
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
per watcher per day.................................7
(S06) Number of NOTIFY msgs for refreshes
per watcher per day.................................0
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
per watcher per day.................................0
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
Number of msgs for all watchers per day.......560,000
Bytes for all watchers per day............229,600,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers............35,760,000
Bytes for all watchers.................68,341,600,000
** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher..................1
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1
(T03) Terminating NOTIFY msgs per watcher.....................1
(T04) Terminating 200 OK msgs (NOTIFY) per watcher............1
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................18,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................14,800,000
(T07) Total number & bytes of terminating NOTIFY msgs
Number of msgs for all watchers................40,000
Bytes for all watchers....................140,000,000
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
Number of msgs for all watchers................40,000
Bytes for all watchers.....................14,800,000
(T09) Total number & bytes of terminating messages per day
Number of msgs for all watchers...............160,000
Bytes for all watchers....................187,600,000
** Bottom Line
(B01) Total number of message & bytes during the day
Number of msgs.............................36,080,000
Bytes..................................70,996,800,000
(B02) Total number of message & bytes per second
Number of msgs..................................1,253
Bytes.......................................2,465,167
]]></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 very
common. However, there is also a strong association between some users
in the deployment. These associations make it somewhat more likely that
users in that domain will be watchers of the same presentity. This can
occur because of business relationships (e.g. two co-workers on a project
federating with a partner company).</t>
<t>Common characteristics of this deployment are:</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="Very large network peering">
<t>In this environment, two or more very large networks create a peering
relationship allowing their users to subscribe to presence in the other
domains. Where as the number of users in other deployment types ranges
from hundreds to several hundred thousand, these large networks host up
to hundreds of millions of users. Examples of these networks are large
wireless carriers and consumer IM networks.</t>
<t>Common characteristics of this deployment are:</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 very high (i.e., 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 (almost cut the number of messages by
half), the numbers are still very high. Note also that the bandwidth required is very high (almost 1GB per second).</t>
<figure title="Very 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................3,000
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher.....................10
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher............10
(I03) Initial NOTIFY msgs per watcher........................10
(I04) Initial 200 OK msgs (NOTIFY) per watcher...............10
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers.................90,000,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers.................74,000,000,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers................700,000,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers.................74,000,000,000
(I09) Total number & bytes of initial messages per day
Number of msgs for all watchers...........800,000,000
Bytes for all watchers................938,000,000,000
** Steady State Messages
(S01) NOTIFY msgs due to state change
per watched presentity per day.....................46
(S02) 200 (for NOTIFY due to state change) msgs
per watched presentity per day.....................46
(S03) Total number and size of msgs due to state change per day
Number of msgs for all watchers........18,400,000,000
Bytes for all watchers.............35,604,000,000,000
(S04) Number of SUBSCRIBE msgs for refreshes
per watcher per day................................70
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
per watcher per day................................70
(S06) Number of NOTIFY msgs for refreshes
per watcher per day................................70
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
per watcher per day................................70
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
Number of msgs for all watchers per day.5,600,000,000
Bytes for all watchers per day......6,566,000,000,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers........24,000,000,000
Bytes for all watchers.............42,170,000,000,000
** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher.................10
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........10
(T03) Terminating NOTIFY msgs per watcher....................10
(T04) Terminating 200 OK msgs (NOTIFY) per watcher...........10
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers.................90,000,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers.................74,000,000,000
(T07) Total number & bytes of terminating NOTIFY msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers................700,000,000,000
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers.................74,000,000,000
(T09) Total number & bytes of terminating messages per day
Number of msgs for all watchers...........800,000,000
Bytes for all watchers................938,002,000,000
** Bottom Line
(B01) Total number of message & bytes during the day
Number of msgs.........................25,600,000,000
Bytes..............................44,046,000,000,000
(B02) Total number of message & bytes per second
Number of msgs................................888,889
Bytes...................................1,529,375,333
]]></artwork></figure>
<figure title="Very 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................3,000
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher......................1
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1
(I03) Initial NOTIFY msgs per watcher.........................1
(I04) Initial 200 OK msgs (NOTIFY) per watcher................1
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers..................9,000,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers..................7,400,000,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers................610,000,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers..................7,400,000,000
(I09) Total number & bytes of initial messages per day
Number of msgs for all watchers............80,000,000
Bytes for all watchers................663,800,000,000
** Steady State Messages
(S01) NOTIFY msgs due to state change
per watched presentity per day.....................46
(S02) 200 (for NOTIFY due to state change) msgs
per watched presentity per day.....................46
(S03) Total number and size of msgs due to state change per day
Number of msgs for all watchers........18,400,000,000
Bytes for all watchers.............35,604,000,000,000
(S04) Number of SUBSCRIBE msgs for refreshes
per watcher per day.................................7
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
per watcher per day.................................7
(S06) Number of NOTIFY msgs for refreshes
per watcher per day.................................0
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
per watcher per day.................................0
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
Number of msgs for all watchers per day...280,000,000
Bytes for all watchers per day........114,800,000,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers........18,680,000,000
Bytes for all watchers.............35,718,800,000,000
** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher..................1
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1
(T03) Terminating NOTIFY msgs per watcher.....................1
(T04) Terminating 200 OK msgs (NOTIFY) per watcher............1
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers..................9,000,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers..................7,400,000,000
(T07) Total number & bytes of terminating NOTIFY msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers.................70,000,000,000
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers..................7,400,000,000
(T09) Total number & bytes of terminating messages per day
Number of msgs for all watchers............80,000,000
Bytes for all watchers.................93,800,000,000
** Bottom Line
(B01) Total number of message & bytes during the day
Number of msgs.........................18,840,000,000
Bytes..............................36,446,400,000,000
(B02) Total number of message & bytes per second
Number of msgs................................654,167
Bytes...................................1,265,500,000
]]></artwork></figure>
</section>
<section title="Intra-domain peering">
<t>Within a particular domain, multiple presence infrastructures are
deployed with users split between the two. This scenario is unique in
that federated messages do not pass outside the administrative domain's
network. The two infrastructures peer directly inside the domain. A
common example of this is an enterprise IT system with multiple
independent vendor presence solutions deployed(e.g., a presence solution
for desktop messaging deployed alongside a presence solution for IP
telephony).</t>
<t>Common characteristics of this deployment are</t>
<t><list style="symbols">
<t>The difference between subscriptions to presentities in one system vs.
the other are completely arbitrary. Any one presentity is as likely to
be homed on one infrastructure as the other</t>
<t>Active users are almost guaranteed of subscribing 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. Even
though the relatively conservative numbers are used, the amount of
messages is still very high even though optimization may cut the
traffic by more then half </t>
<figure title="Inter-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................3,000
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher.....................10
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher............10
(I03) Initial NOTIFY msgs per watcher........................10
(I04) Initial 200 OK msgs (NOTIFY) per watcher...............10
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers.............1,200,000
Bytes for all watchers....................540,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers.............1,200,000
Bytes for all watchers....................444,000,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers.............1,200,000
Bytes for all watchers..................4,200,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
Number of msgs for all watchers.............1,200,000
Bytes for all watchers....................444,000,000
(I09) Total number & bytes of initial messages per day
Number of msgs for all watchers.............4,800,000
Bytes for all watchers..................5,628,000,000
** Steady State Messages
(S01) NOTIFY msgs due to state change
per watched presentity per day.....................22
(S02) 200 (for NOTIFY due to state change) msgs
per watched presentity per day.....................22
(S03) Total number and size of msgs due to state change per day
Number of msgs for all watchers............52,800,000
Bytes for all watchers................102,168,000,000
(S04) Number of SUBSCRIBE msgs for refreshes
per watcher per day................................70
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
per watcher per day................................70
(S06) Number of NOTIFY msgs for refreshes
per watcher per day................................70
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
per watcher per day................................70
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
Number of msgs for all watchers per day....33,600,000
Bytes for all watchers per day.........39,396,000,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers............86,400,000
Bytes for all watchers................141,564,000,000
** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher.................10
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........10
(T03) Terminating NOTIFY msgs per watcher....................10
(T04) Terminating 200 OK msgs (NOTIFY) per watcher...........10
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
Number of msgs for all watchers.............1,200,000
Bytes for all watchers....................540,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers.............1,200,000
Bytes for all watchers....................444,000,000
(T07) Total number & bytes of terminating NOTIFY msgs
Number of msgs for all watchers.............1,200,000
Bytes for all watchers..................4,200,000,000
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
Number of msgs for all watchers.............1,200,000
Bytes for all watchers....................444,000,000
(T09) Total number & bytes of terminating messages per day
Number of msgs for all watchers.............4,800,000
Bytes for all watchers..................5,628,000,000
** Bottom Line
(B01) Total number of message & bytes during the day
Number of msgs.............................96,000,000
Bytes.................................152,820,000,000
(B02) Total number of message & bytes per second
Number of msgs..................................3,333
Bytes.......................................5,306,250
]]></artwork></figure>
<figure title="Inter-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................3,000
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher......................1
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1
(I03) Initial NOTIFY msgs per watcher.........................1
(I04) Initial 200 OK msgs (NOTIFY) per watcher................1
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers...............120,000
Bytes for all watchers.....................54,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers...............120,000
Bytes for all watchers.....................44,400,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers...............120,000
Bytes for all watchers..................3,660,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
Number of msgs for all watchers...............120,000
Bytes for all watchers.....................44,400,000
(I09) Total number & bytes of initial messages per day
Number of msgs for all watchers...............480,000
Bytes for all watchers..................3,802,800,000
** Steady State Messages
(S01) NOTIFY msgs due to state change
per watched presentity per day.....................22
(S02) 200 (for NOTIFY due to state change) msgs
per watched presentity per day.....................22
(S03) Total number and size of msgs due to state change per day
Number of msgs for all watchers............52,800,000
Bytes for all watchers................102,168,000,000
(S04) Number of SUBSCRIBE msgs for refreshes
per watcher per day.................................7
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
per watcher per day.................................7
(S06) Number of NOTIFY msgs for refreshes
per watcher per day.................................0
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
per watcher per day.................................0
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
Number of msgs for all watchers per day.....1,680,000
Bytes for all watchers per day............668,800,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers............54,480,000
Bytes for all watchers................102,856,800,000
** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher..................1
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1
(T03) Terminating NOTIFY msgs per watcher.....................1
(T04) Terminating 200 OK msgs (NOTIFY) per watcher............1
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
Number of msgs for all watchers...............120,000
Bytes for all watchers.....................54,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers...............120,000
Bytes for all watchers.....................44,400,000
(T07) Total number & bytes of terminating NOTIFY msgs
Number of msgs for all watchers...............120,000
Bytes for all watchers....................420,000,000
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
Number of msgs for all watchers...............120,000
Bytes for all watchers.....................44,400,000
(T09) Total number & bytes of terminating messages per day
Number of msgs for all watchers...............480,000
Bytes for all watchers....................562.800,000
** Bottom Line
(B01) Total number of message & bytes during the day
Number of msgs.............................55,440,000
Bytes.................................107,222,400,000
(B02) Total number of message & bytes per second
Number of msgs..................................1,925
Bytes.......................................3,723,417
]]></artwork></figure>
</section>
</section>
<section title="Partial Notifications Optimization">
<t>Draft <xref target="I-D.ietf-simple-partial-notify"/> define a way for the
watcher to request getting only what was changed in the presence document. The
following is a calculation of the bandwidth that is saved in the very large
peering network case, when we add the partial notification optimization to the
dialog and NOTIFY optimization. It is assumed that except for the initial NOTIFY
all the other NOTIFY messages will be partial and the size of the partial presence document is 200 bytes</t>
<figure title="Very large networks peering with dialog, 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...............1
(C06) Total number of watchers in domains............20,000,000
(C07) SUBSCRIBE message size in bytes.......................450
(C08) 200 OK for SUBSCRIBE message size in bytes............370
(C09) NOTIFY message size not including presence doc........500
(C10) 200 OK for NOTIFY message size in bytes...............370
(C11) Size of an average presence document................3,000
(C12) Size of an average partial presence document..........200
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher......................1
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1
(I03) Initial NOTIFY msgs per watcher.........................1
(I04) Initial 200 OK msgs (NOTIFY) per watcher................1
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers..................9,000,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers..................7,400,000,000
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers................610,000,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers..................7,400,000,000
(I09) Total number & bytes of initial messages per day
Number of msgs for all watchers............80,000,000
Bytes for all watchers................663,800,000,000
** Steady State Messages
(S01) NOTIFY msgs due to state change
per watched presentity per day.....................46
(S02) 200 (for NOTIFY due to state change) msgs
per watched presentity per day.....................46
(S03) Total number and size of msgs due to state change per day
Number of msgs for all watchers........18,400,000,000
Bytes for all watchers..............9,844,000,000,000
(S04) Number of SUBSCRIBE msgs for refreshes
per watcher per day.................................7
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
per watcher per day.................................7
(S06) Number of NOTIFY msgs for refreshes
per watcher per day.................................0
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
per watcher per day.................................0
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
Number of msgs for all watchers per day...280,000,000
Bytes for all watchers per day........114,800,000,000
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers........18,680,000,000
Bytes for all watchers..............9,958,800,000,000
** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher..................1
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1
(T03) Terminating NOTIFY msgs per watcher.....................1
(T04) Terminating 200 OK msgs (NOTIFY) per watcher............1
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers..................9,000,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers..................7,400,000,000
(T07) Total number & bytes of terminating NOTIFY msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers.................70,000,000,000
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
Number of msgs for all watchers............20,000,000
Bytes for all watchers..................7,400,000,000
(T09) Total number & bytes of terminating messages per day
Number of msgs for all watchers............80,000,000
Bytes for all watchers.................93,800,000,000
** Bottom Line
(B01) Total number of message & bytes during the day
Number of msgs.........................18,840,000,000
Bytes..............................10,630,400,000,000
(B02) Total number of message & bytes per second
Number of msgs................................654,167
Bytes.....................................369,111,111
]]></artwork></figure>
<t>Compared to the numbers we got for optimized very large peering networks
(36,446,400,000,000 bytes per day, it seems that the partial notify can save
a lot in the bandwidth.</t>
</section>
<section title="Other Protocols">
<t>In SIP there are several differences from other protocols of presence as XMPP
<xref target="RFC3923"/> and the proprietary protocols of the consumer domains.
The differences are:</t>
<t><list style="symbols">
<t>There is no 200 OK for each message. These protocols support only TCP and they do not compensate for network
issues.</t>
<t>There is no refresh for subscription.</t>
<t>There is no NOTIFY upon termination of SUBSCRIPTION</t>
<t>The size of each message of these protocol is smaller since they are either
binary and/or there is no need for the various headers that SIP uses for routing
etc. So we need to assume smaller message sizes while we will keep the size of
the presence document the same.</t>
</list></t>
<t>The following is an analysis of the very large networks peering assuming all
the changes in other protocols with respect to SIP.</t>
<figure title="Very large networks peering in other protocols" 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..............10
(C06) Total number of watchers in domains............20,000,000
(C07) SUBSCRIBE message size in bytes.......................150
(C08) 200 OK for SUBSCRIBE message size in bytes..............0
(C09) NOTIFY message size not including presence doc........150
(C10) 200 OK for NOTIFY message size in bytes.................0
(C11) Size of an average presence document................3,000
** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher.....................10
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............0
(I03) Initial NOTIFY msgs per watcher........................10
(I04) Initial 200 OK msgs (NOTIFY) per watcher................0
(I05) Total number & bytes of initial SUBSCRIBE msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers.................30,000,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers.....................0
Bytes for all watchers..............................0
(I07) Total number & bytes of initial NOTIFY msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers....................630,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
Number of msgs for all watchers.....................0
Bytes for all watchers..............................0
(I09) Total number & bytes of initial messages per day
Number of msgs for all watchers...........400,000,000
Bytes for all watchers.................660,00,000,000
** Steady State Messages
(S01) NOTIFY msgs due to state change
per watched presentity per day.....................46
(S02) 200 (for NOTIFY due to state change) msgs
per watched presentity per day......................0
(S03) Total number and size of msgs due to state change per day
Number of msgs for all watchers.........9,200,000,000
Bytes for all watchers.............28,980,000,000,000
(S04) Number of SUBSCRIBE msgs for refreshes
per watcher per day.................................0
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
per watcher per day.................................0
(S06) Number of NOTIFY msgs for refreshes
per watcher per day.................................0
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
per watcher per day.................................0
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
Number of msgs for all watchers per day.............0
Bytes for all watchers per day......................0
(S09) Total number & bytes of steady messages per day
Number of msgs for all watchers.........9,200,480,000
Bytes for all watchers.............28,980,000,000,000
** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher.................10
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........0
(T03) Terminating NOTIFY msgs per watcher.....................0
(T04) Terminating 200 OK msgs (NOTIFY) per watcher............0
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
Number of msgs for all watchers...........200,000,000
Bytes for all watchers.................30,000,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
Number of msgs for all watchers.....................0
Bytes for all watchers..............................0
(T07) Total number & bytes of terminating NOTIFY msgs
Number of msgs for all watchers.....................0
Bytes for all watchers..............................0
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
Number of msgs for all watchers.....................0
Bytes for all watchers..............................0
(T09) Total number & bytes of terminating messages per day
Number of msgs for all watchers...........200,000,000
Bytes for all watchers.................30,000,000,000
** Bottom Line
(B01) Total number of message & bytes during the day
Number of msgs..........................9,800,000,000
Bytes..............................29,670,000,000,000
(B02) Total number of message & bytes per second
Number of msgs................................340,278
Bytes...................................1,030,208,333
]]></artwork></figure>
<t>Compared to the numbers we got for optimized very large peering networks
(18,840,000,000 messages per day and 10,630,400,000,000 bytes per day, the
numbers of message with other protocols are only about half and with due to the
partial notification optimization we get even less bytes per day. It seems that
this shows that the scalability issue of presence is less due to some protocol
choice but more an inherent issue with presence.</t>
</section>
</section>
<section title="State Management">
<t>In previous sections we have discussed the big amount of messages that need to
be sent to/from a presence server In this section the state that needs to be
maintained by a presence server will be analysed and shown to be far from
trivial.</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 in order to
maintain the subscription as timers.</t>
<t>Optional filtering information that was requested by the watcher. This
includes enough information that is needed for doing the filtering. In addition
additional information has to be maintained if partial notification is being
supported for the subscription</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 enable watched presentities to see
who is watching them.</t>
</list></t>
<t>For each presentity that has been subscribed to 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 this is already taken care of from the size calculation
point of view by the subscription state above.</t>
<t>Authorization information for the presentity.</t>
</list></t>
<t>For each presentity for which there was any publication and the presentity has a state other then a default value,
the presence server has to maintain the current value of the presentity.</t>
<section title="State Size Calculations">
<t>Lets assume the following sizes:</t>
<t><list style="symbols">
<t>Subscription size - 2K bytes. This includes watcher information that need to
be created by the presence server for each subscription.</t>
<t>Subscribed to resource - 1K bytes (for privacy information and other
management info). 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 take
into account the amount of data that is being put in a presence document as
multiple devices, calendar and geographical information.</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 = 23437M bytes.</t>
</list></t>
<t>Total is 38G bytes.</t>
</section>
<section title="Very Large 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 very big number for a very dynamic storage as needed by the presence server.</t>
</section>
<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 seem not so big for databases even for
the very large system, we need to remember that this state is a very dynamic
state. Subscriptions come and go all the time, the status of presentities is being
updated and so forth. This means that the presence server has to manage its
state in a medium that is very dynamic and for such large sizes this task is not
trivial.</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. As presence is becoming more a core middleware functionality that holds
a lot of data on the user. In real-life the numbers above may be even higher and
the presence server can have additional overhead as managing the SIP sessions,
networking and more.</t>
</list></t>
<t>Although the calculations above do not show that there is a real issue with
state management of presence in medium systems or even in big systems since it
should be possible to divide the state between different machines, the state
size is still very big. A bigger issue with the state is more when resource lists are involved
and create an interlinked state between many servers. In that case the division of very big state to
multiple servers becomes less trivial...</t>
</section>
</section>
<section title="Processing complexities">
<t>The basic presence paradigm consists from a watcher and a presentity to which the
watcher watches. It sounds simple enough but there are many additions and extensions
that the presence server has to manage that make the processing of the presence server very complex.</t>
<t>In this section we show that in addition to the large amount of messages and the big state
that the presence server has to handle, it has also to handle quite intensive processing for aggregation,
partial notify and publish, filtering and privacy. This adds another complexity to the presence server in the CPU front in
addition to the network and memory fronts that were described before.</t>
<section title="Aggregation">
<t>A presence document may contain multiple resources. These resources can be devices of
the presentity, information that is received form external providers of presence information for the presentity as geographical
and calendar information and more.</t>
<t>The presence server needs to be able to get the updates from all the resources and
aggregate them correctly into a single presence document. Although this is just "XML processing" task,
the amount of updates that the presence server may get, the need to keep the presence document
aligned with its schema and the need to notify the users as soon as possible create a significant
processing burden on the presence server</t>
</section>
<section title="Partial Publish and Notify">
<t>Drafts <xref target="I-D.ietf-simple-partial-notify"/>, <xref target="I-D.ietf-simple-partial-publish"/>
define a way for the watcher to request
getting only what was changed in the presence document and for the publisher of
presence information to publish only what was changed in the presence document
since the last publish. Although these optimizations help in reducing the amount
of the data that is sent from/to the presence server, these optimizations
create additional processing burden on the presence server.</t>
<t>When a partial publish is arriving to the presence server, the presence
server has to be able to process the partial publish, change only what is
indicated in the partial publish while keeping the presence document in a well
formed shape according to the schema.</t>
<t>In partial notify the processing is even more complex since each
watcher needs to get the partial update based on the last update that was
received by that watcher. Therefore <xref target="I-D.ietf-simple-partial-notify"/>
specifies a versioning mechanism that enables the watcher to get the
updates based on the previous state that it has seen. This versioning
mechanism has to be maintained by the presence server for each watcher that is
subscribed to a presentity and requires partial notify.</t>
</section>
<section title="Filtering">
<t>Filtering as defined in RFCs <xref target="RFC4660"/>, <xref
target="RFC4661"/> enables a watcher to request to be notified only when the
presence document fulfills certain conditions. Although this is a very
convenient feature for watchers, the burden that is put on the presence server
is quite big. For each change in the presence document, the presence server
needs to compute the filtering expressions which can be very complex, decide
whether and what to send to the watcher that have requested filtering.</t>
</section>
<section title="Authorization">
<t>Draft <xref target="I-D.ietf-simple-presence-rules"/> defines presence authorization rules
that can be used by presentities to define who can see what from their presence documents.
The processing that the presence server has to do here is very similar to filtering. When there
is a change to any presence document that has privacy defined for it, the presence server needs to
create different notification for different watchers according to what is defined in the authorization rules.</t>
</section>
<section anchor="RLS" title="Resource List Service">
<t>RFC <xref target="RFC4662"/> defines a way to subscribe on a single URI while
that URI is actually a list of resources that are being subscribed to by a
single subscription. Although this is quite useful mechanism and it
significantly saves on the number of sessions between the watcher and the
presence server (as we show in the calculations of messages), this feature has
the potential to make the scalability issue of presence systems harder and more
complex.</t>
<t>The reasons that resource lists may make the scalability problem of the
presence server even more complex are:</t>
<t><list style="symbols">
<t>Subscriptions and state - The resource list may contain reference to many
other presence servers in many other domains. This requires the RLS to create
subscriptions to other presence servers and buffer the state of all presentities
in order to be able to provide the full state of the presentities in the list
when needed. So in the overall system, the subscriptions that were saved between
the watcher and the presence server are moved to the backend system while state
has been duplicated between the various presence servers that serve the various
presentities and the RLSs. This issue could have been mitigated if there was a
way for the RLS to retrieve the presence information for many watchers while
adhering to privacy when sending the actual notifications to the watchers.</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 way a complex linkage between the state of many
components is created. This linkage makes state management and other
maintenance of a presence systems quite complex.</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 take caution when creating public groups, this may
be not the case in real life. The connection between the size of the public
group and the load on the presence server system may not apparent to everyone.
Furthermore many public groups that are used in presence systems may have been
created for other purposes as email systems (where the size of the lists was not
so important) and are taken as they are to presence systems. So for example we
may very easily find that a public group that actually covers all the users in
the enterprise are used by many users in the enterprise thus creating unbearable
load on the presence server. Note that this issue is not a protocol or design
issue but more a usage issue that may have a real impact on the presence
system.</t>
<t>Stopping notifications - A watcher may accidentally subscribe to a very big list
and be overwhelmed by the amount of notifies that it receives from the presence
server. There is no current way to stop this stream of notifies and even
canceling the subscription may take time until being affective.</t>
</list></t>
<t>The issues mentioned above are one example of an optimization that helps in
one part of the system but creates even bigger problems in the overall system.
There is a need to think about the problems listed above but more then that
there is a need to make sure that when an optimization is introduced it does not
create issues in other places.</t>
</section>
</section>
<section title="Current Optimizations">
<t>This section lists and discusses several optimizations that are either
already part of the SIP protocol or they have been suggested in various
drafts. Several other optimizations that have been suggested but have not been discussed in the working group yet are
summarized in <xref target="I-D.houri-simple-interdomain-scaling-optimizations" />.</t>
<t><list style="symbols">
<t>Subnot-etags - Draft <xref target="I-D.ietf-sip-subnot-etags"/>. This draft
suggests ways to suppress the sending of unnecessary notifies when for example a
subscription is refreshed. This suggestion seems to be an efficient
optimization since it saves both the number of messages sent and on the
processing time of the presence server.</t>
<t>Resource List Service - <xref target="RFC4662"/> enable creating a single subscription
session between the watcher and the presence server for subscribing on a list of users.
This saves the amount of sessions that are created between watchers and presence servers.
On the other hand, this mechanism enables creating very large amount of subscriptions in the
presence server/RLS system thus enabling the creation of a very large number of subscriptions
between presence servers and RLSs with relatively few clients especially if large public groups
are used. It seems that in order to really optimize in this area, the usage of large public
groups should not be considered as BCP and there should be a way for an RLS to create a single
subscription for multiple occurrences of the same resource in resource lists. See consolidates
subscriptions below.</t>
<t>Partial notify/publish - Drafts <xref target="I-D.ietf-simple-partial-notify"/>,
<xref target="I-D.ietf-simple-partial-publish"/> define a way for the
subscriber to request getting only what was changed in the presence document and
for the publisher of presence information to publish only what was changed in
the presence document since the last publish. Although these optimizations help
in reducing the amount of actual data that is sent from/to the presence server,
these optimizations create additional processing burden on the presence
server as was discussed above.</t>
<t>Filtering as defined in RFCs <xref target="RFC4660"/>, <xref
target="RFC4661"/> enables a watcher to request to be notified only when the
presence document fulfills certain conditions. Although this optimization
enables saving on the amount of messages that are sent from the presence server to the watcher, this
optimization puts more burden on the processing time of the presence server as
was discussed above.</t>
<t>Throttling <xref target="I-D.niemi-sipping-event-throttle" /> defines a
mechanism in which a watcher requires to be updated only in certain intervals.
Although this mechanism may give some extra load on the processing time of the
presence server, that load is negligible and the reduction on the amount of
messages sent from the presence server to the watchers is significant. This
optimization is even more important with resource lists where there can be many
resources in the resource lists and if the traffic of updates on resource list
is not regulated, the watcher may get very large amount of notifications.</t>
<t>Presence specific sigcomp dictionary <xref target="I-D.garcia-simple-presence-dictionary"/>
defines a SIGCOMP <xref target="RFC3320"/> dictionary for
presence. This optimization will enable to reduce the number of bytes that are
transferred in presence systems by compressing the textual SIP messages and using
the specialized presence dictionary the compression may be more significant then
just using SIGCOMP as is. Note that number of actual messages will remain the
same and a calculation of the amount of bytes that will be saved may be
useful here.</t>
<t>Content Indirection <xref target="RFC4483"/> enables sending only the URI of the
presence document to the watcher thus offloading the presence server from sending the
presence document to the watcher. This optimization may be useful in some cases especially where there is
a big number of users that get the same presence document.</t>
</list></t>
</section>
<section title="Conclusions">
<t>The document analyses the scalability of presence systems and of the SIP based
in particular. It is apparent that the scalability of these systems is far from
being trivial from several perspectives: number of messages, network bandwidth,
state management and CPU load.</t>
<t>As part of the analysis we have analysed several optimizations and showed the
effect of these optimizations on the number of messages and the number of bytes
that are sent between the federating domains.</t>
<t>We have also computed the number of messages and bytes for a very large
number while assuming a protocol that has much less "overhead" then SIP. Even in
that protocol we got relatively high numbers.</t>
<t>It is very possible that the issues that are described in this document are
inherent to presence systems in general and not specific to the SIMPLE protocol.
Organizations need to be prepared to invest a lot in network and hardware in
order to create real big systems. However, it is apparent that not all the
possible optimizations were done yet and further work is needed in the IETF in
order to provide better scalability</t>
<t>It seems that we need to think about the problem in a different way. We need
to think about scalability as part of the protocol design. The IETF tends not to
think about actual deployments when designing a protocol but in this case it
seems that if we do not think about scalability with the protocol design it will
not be very hard to scale.</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 very
optimized for the load and can assume some assumptions about the network (e.g.
do not use unreliable protocol as UDP but only TCP).</t>
<t>Another issue that is more concerning protocol design is whether NOTIFY
messages should not be considered as media as the audio, video and even text
messaging are considered? The SUBSCRIBE can be extended to do similar three way
handshake as INVITE and negotiate where the notify messages should go, rate and
other parameters. This way the load can be offloaded to specialized NOTIFY
"relays" thus not loading the control path of SIP.</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, a lot of the possible
optimizations that should emerge as a result of this document will have
security implications that will need to be solved.</t>
</section>
<section title="Changes from Previous Versions">
<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.houri-sipping-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, Markus Isomaki
Piotr Boni, David Viamonte and Aki Niemi for ideas and input. Special thanks to Marc Willekens for
finding a bug in the calculations.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
</references>
<references title="Informational References">
<?rfc include="reference.RFC.3265" ?>
<?rfc include="reference.RFC.3320" ?>
<?rfc include="reference.RFC.3857" ?>
<?rfc include="reference.RFC.3858" ?>
<?rfc include="reference.RFC.3923" ?>
<?rfc include="reference.RFC.4483" ?>
<?rfc include="reference.RFC.4660" ?>
<?rfc include="reference.RFC.4661" ?>
<?rfc include="reference.RFC.4662" ?>
<?rfc include="reference.I-D.ietf-simple-partial-notify" ?>
<?rfc include="reference.I-D.ietf-simple-partial-publish" ?>
<?rfc include="reference.I-D.ietf-simple-presence-rules" ?>
<?rfc include="reference.I-D.garcia-simple-presence-dictionary" ?>
<?rfc include="reference.I-D.ietf-sipping-uri-list-subscribe" ?>
<?rfc include="reference.I-D.ietf-sip-subnot-etags" ?>
<?rfc include="reference.I-D.houri-sipping-presence-scaling-requirements" ?>
<?rfc include="reference.I-D.houri-simple-interdomain-scaling-optimizations" ?>
<?rfc include="reference.I-D.niemi-sipping-event-throttle" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 23:51:51 |