bandwidth required is also very big.

   o  State management - Due to the nature of the service that the
      presence server provides, the presence server has to manage a
      relatively big and complex state and some computations are
      provided in the document.

   o  Processing complexities - The presence server maintains many small
      objects and has to do frequent operations on these objects.  We
      show that these operations and especially the optimizations that
      are intended to save on the amount of data that is being sent
      between watchers and presence servers, are not so simple and may
      create a very heavy processing load on the presence server.

   o  Groups - Resource List Servers [<A title='"A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists"' href="http://tools.ietf.org/html/draft-ietf-simple-interdomain-scaling-analysis-00#ref-12">12</A>] optimize the number of
      sessions that are created between the watchers and the presence
      server.  On the other hand, this optimization may create an



<SPAN class=grey>Houri, et al.            Expires August 30, 2007                [Page 5]</SPAN>
<A id=page-6 href="http://tools.ietf.org/html/draft-ietf-simple-interdomain-scaling-analysis-00#page-6" name=page-6><SPAN class=break> </SPAN></A>
<SPAN class=grey>Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007</SPAN>


      exponential size of subscription due to the unbearable ease of
      subscribing to large groups.

   The term presence domain or presence system appears in the document
   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.











































<SPAN class=grey>Houri, et al.            Expires August 30, 2007                [Page 6]</SPAN>
<A id=page-7 href="http://tools.ietf.org/html/draft-ietf-simple-interdomain-scaling-analysis-00#page-7" name=page-7><SPAN class=break> </SPAN></A>
<SPAN class=grey>Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007</SPAN>


<SPAN class=h2><A name=section-3>3</A>.  Message Load</SPAN>

   Even though some optimizations are approved or are being defined, we
   show in this section that a very large number of messages &amp; large
   bandwidth are needed in order to establish federation between
   presence systems of large communities.  Further thinking is needed in
   order to make large deployment of presence systems less resource
   demanding.

   Note that even though this document talks about inter domain traffic,
   the introduction of resource list servers (RLSs) [<A title='"A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists"' href="http://tools.ietf.org/html/draft-ietf-simple-interdomain-scaling-analysis-00#ref-12">12</A>] introduce very
   similar traffic pattern within a domain as between domains.  See
   detailed discussion on resource lists in section <A href="http://tools.ietf.org/html/draft-ietf-simple-interdomain-scaling-analysis-00#section-4">Section 4</A>.

<SPAN class=h3><A name=section-3.1>3.1</A>.  Known Optimizations</SPAN>

   The current optimizations that are approved or considered in the
   SIMPLE group can be divided into two categories:

   o  Dialogs saving optimization - Here we refer to optimizations as
      the resource list RFC [<A title='"A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists"' href="http://tools.ietf.org/html/draft-ietf-simple-interdomain-scaling-analysis-00#ref-12">12</A>] or to the Uri list subscriptions draft
      [<A title='"Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)"' href="http://tools.ietf.org/html/draft-ietf-simple-interdomain-scaling-analysis-00#ref-18">18</A>].  These documents define ways to reduce the number of dialogs
      that are required between the subscriber and the presence system.

   o  Notification optimizations - Here we refer to the optimizations
      that are suggested in the subnot-etags draft [<A title='"An Extension to Session Initiation Protocol (SIP) Events for Issuing Conditional Subscriptions"' href="http://tools.ietf.org/html/draft-ietf-simple-interdomain-scaling-analysis-00#ref-20">20</A>].  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 &amp;
      bandwidth.

<SPAN class=h3><A name=section-3.2>3.2</A>.  Assumptions</SPAN>

   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.

   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



<SPAN class=grey>Houri, et al.            Expires August 30, 2007                [Page 7]</SPAN>
<A id=page-8 href="http://tools.ietf.org/html/draft-ietf-simple-interdomain-scaling-analysis-00#page-8" name=page-8><SPAN class=break> </SPAN></A>
<SPAN class=grey>Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007</SPAN>


   from consumer networks show that the frequency here is much bigger
   and especially with the younger generation.  In an environment where
   a user may have several devices and other resources for presence
   information as geographical location and calendar the frequency of
   presence state changes will be much higher.

   It is very hard to measure presence load since the behavior of users
   is very different.  Some users will have a very small number of
   presentities in their watch list while others may have hundreds.
   Some users will change their state a lot and have many sources of
   presence information while other may have very small number of
   changes during the day.  In addition there that "rush hour"
   calculation that was not included 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.

   Saying the above, there are still several things to be done to create
   a more complete picture:

   o  Get rigorous statistical data that can be formally published from
      real presence systems

   o  Add to the model the possibility of having multiple sources of
      presence data per presentity and change calculations accordingly

   o  Add "rush hour" calculations for the end and the beginning of the
      day

   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.

<SPAN class=h3><A name=section-3.3>3.3</A>.  Analysis</SPAN>

   The basic SIMPLE subscription dialog involves the following message-
   transfer:

   o  SUBSCRIBE/200

   o  Initial NOTIFY/200

   o  (j) NOTIFY/200 where 'j' is the number of presence changes seen by
      the watcher

   o  (k) SUBSCRIBE/200 where 'k' is the number of subscription dialog
      refresh periods



<SPAN class=grey>Houri, et al.            Expires August 30, 2007                [Page 8]</SPAN>
<A id=page-9 href="http://tools.ietf.org/html/draft-ietf-simple-interdomain-scaling-analysis-00#page-9" name=page-9><SPAN class=break> </SPAN></A>
<SPAN class=grey>Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007</SPAN>


   o  SUBSCRIBE/200 with Expires = 0 to terminate the dialog

   o  NOTIFY/200 ending the dialog

   An individual watcher will generate X number of SIMPLE subscription
   dialogs corresponding to the number of presentities it chooses to
   watch.  The amount of traffic generated is significantly affected by
   several factors:

   o  Number of watchers connected to the system

   o  Number of presentities connected to the system

   o  Frequency of changes to presence information

   This document contains several calculations that show the expected
   message rate and bandwidth between presence domains.  The following
   explains the assumptions and methods behind the calculations:

   o  (A01) Subscription lifetime (hours)- The assumed lifetime of a
      subscription in hours.  Here we assume 8 hours for all
      calculations.

   o  (A02) 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.

   o  (A03) Subscription refresh interval / hour - The duration of the
      SUBSCRIBE session after which it needs to be refreshed.  We
      assumed that the duration is one hour.

   o  (A04) Total federated presentities per watcher - The number of
      presentities that the watcher is watching.  The number here
      changes in this document according to the type of the specific