[Search] [txt|html|xml|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08                                    
SIMPLE WG                                                       A. Houri
Internet-Draft                                                       IBM
Intended status: Informational                                   E. Aoki
Expires: April 25, 2009                                         AOL  LLC
                                                           S. Parameswar
                                                                 T. Rang
                                                   Microsoft Corporation
                                                                V. Singh
                                                          H. Schulzrinne
                                                             Columbia U.
                                                        October 22, 2008


          Presence Interdomain Scaling Analysis for SIP/SIMPLE
         draft-ietf-simple-interdomain-scaling-analysis-05.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 25, 2009.

Abstract

   The document analyzes the traffic that is generated due to presence
   subscriptions between domains.  It is shown that the amount of
   traffic can be extremely big.  In addition to the very large traffic
   the document also analyzes the affects of a large presence system on
   the memory footprint and the CPU load.  Current approved and in work



Houri, et al.            Expires April 25, 2009                 [Page 1]


Internet-Draft          Presence Scaling Analysis           October 2008


   optimizations to the SIP protocol are analyzed with the possible
   impact on the load.  Separate documents contain the requirements for
   optimizations and suggestions for new optimizations.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Message Load . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Known Optimizations  . . . . . . . . . . . . . . . . . . .  5
     2.2.  Assumptions  . . . . . . . . . . . . . . . . . . . . . . .  6
     2.3.  Analysis . . . . . . . . . . . . . . . . . . . . . . . . .  8
       2.3.1.  Constants  . . . . . . . . . . . . . . . . . . . . . .  8
       2.3.2.  Initial Messages . . . . . . . . . . . . . . . . . . . 10
       2.3.3.  Steady State Messages  . . . . . . . . . . . . . . . . 10
       2.3.4.  Termination Messages . . . . . . . . . . . . . . . . . 12
       2.3.5.  Bottom Line  . . . . . . . . . . . . . . . . . . . . . 12
       2.3.6.  Rush Hour Calculations . . . . . . . . . . . . . . . . 13
     2.4.  No optimizations used  . . . . . . . . . . . . . . . . . . 13
     2.5.  Dialog optimization used . . . . . . . . . . . . . . . . . 15
     2.6.  NOTIFY optimization used . . . . . . . . . . . . . . . . . 17
     2.7.  Dialog & NOTIFY optimizations used . . . . . . . . . . . . 19
     2.8.  Presence Federation Scenarios  . . . . . . . . . . . . . . 21
       2.8.1.  Widely distributed inter-domain presence . . . . . . . 22
       2.8.2.  Associated inter-domain presence . . . . . . . . . . . 26
       2.8.3.  Very large network peering . . . . . . . . . . . . . . 27
       2.8.4.  Intra-domain peering . . . . . . . . . . . . . . . . . 31
     2.9.  Partial Notifications Optimization . . . . . . . . . . . . 36
     2.10. Very Optimized SIP . . . . . . . . . . . . . . . . . . . . 38
   3.  State Management . . . . . . . . . . . . . . . . . . . . . . . 42
     3.1.  State Size Calculations  . . . . . . . . . . . . . . . . . 43
       3.1.1.  Tiny System  . . . . . . . . . . . . . . . . . . . . . 44
       3.1.2.  Medium System  . . . . . . . . . . . . . . . . . . . . 44
       3.1.3.  Large System . . . . . . . . . . . . . . . . . . . . . 44
       3.1.4.  Very Large System  . . . . . . . . . . . . . . . . . . 44
   4.  Processing complexities  . . . . . . . . . . . . . . . . . . . 45
     4.1.  Aggregation  . . . . . . . . . . . . . . . . . . . . . . . 45
     4.2.  Partial Publish and Notify . . . . . . . . . . . . . . . . 46
     4.3.  Filtering  . . . . . . . . . . . . . . . . . . . . . . . . 46
     4.4.  Authorization  . . . . . . . . . . . . . . . . . . . . . . 46
     4.5.  Resource List Service  . . . . . . . . . . . . . . . . . . 47
   5.  Current Optimizations  . . . . . . . . . . . . . . . . . . . . 48
   6.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
   7.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 55
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 56
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 57
   10. Changes from Previous Versions . . . . . . . . . . . . . . . . 57
     10.1. Changes in version 05  . . . . . . . . . . . . . . . . . . 57



Houri, et al.            Expires April 25, 2009                 [Page 2]


Internet-Draft          Presence Scaling Analysis           October 2008


     10.2. Changes in version 04  . . . . . . . . . . . . . . . . . . 57
     10.3. Changes in version 03  . . . . . . . . . . . . . . . . . . 57
     10.4. Changes in version 02  . . . . . . . . . . . . . . . . . . 58
     10.5. Changes in version 01  . . . . . . . . . . . . . . . . . . 58
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 58
   12. Informational References . . . . . . . . . . . . . . . . . . . 58
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60
   Intellectual Property and Copyright Statements . . . . . . . . . . 62











































Houri, et al.            Expires April 25, 2009                 [Page 3]


Internet-Draft          Presence Scaling Analysis           October 2008


1.  Introduction

   The document analyzes the SIP protocol for presence (AKA SIMPLE but
   SIMPLE is not a different protocol then SIP but the name of the
   working group).  It analyses the traffic that is generated due to
   presence subscriptions between domains.  It is shown that the number
   of messages and the amount of data can be extremely big.  In addition
   to the very large traffic the document also analysis the affects of a
   large presence system on the memory footprint and the CPU load.
   Current approved and in work optimizations to the SIP protocol are
   analyzed with the possible impact on the load.  Another document
   provides requirements for optimizations [18] while other documents
   contain suggestions for new optimizations: [19].  [21]

   This document is intended to be drive work on possible solutions that
   will make the deployment of a SIP based presence server less
   challenging task.  Deployment of highly scalable presence systems is
   challenging by its nature and each protocol developers design their
   own technique for optimizing their protocol.  This document does not
   try to compare between protocols and it is behind the scope of this
   document.

   The document discusses the following areas.  In each area we try to
   show the complexity and the load that the presence server has to
   handle in order to provide its service.

   o  Messages load - By computing the number of messages that are
      required for connecting presence systems the document shows that
      the number of messages is very big and it is quite obvious that
      some optimizations are needed.  In addition we also show that the
      bandwidth required is also very big.
   o  State management - Due to the nature of the service that the
      presence server provides, the presence server has to manage a
      relatively big and complex state and some computations are
      provided in the document.
   o  Processing complexities - The presence server maintains many small
      objects and has to do frequent operations on these objects.  We
      show that these operations and especially the optimizations that
      are intended to save on the amount of data that is being sent
      between watchers and presence servers, are not so simple and may
      create a very heavy processing load on the presence server.
   o  Groups - Resource List Servers [9] optimize the number of sessions
      that are created between the watchers and the presence server.  On
      the other hand, this optimization may create an exponential size
      of subscription due to the unbearable ease of subscribing to large
      groups.

   The term presence domain or presence system appears in the document



Houri, et al.            Expires April 25, 2009                 [Page 4]


Internet-Draft          Presence Scaling Analysis           October 2008


   several time.  By this term we refer to a SIP based presence server
   that provides presence subscription and notification services to its
   users.  The system can be a system that is deployed in a small
   enterprise or in a very large consumer network.


2.  Message Load

   Some optimizations are approved or are being defined for the SIP
   presence protocol, but even with these optimizations a very large
   number of messages & large bandwidth are needed in order to establish
   federation between presence systems of large communities.  Further
   thinking is needed in order to make large deployment of presence
   systems less resource demanding.

   Note that even though this document talks about inter domain traffic,
   the introduction of resource list servers (RLSs) [9] introduce very
   similar traffic pattern in intra-domain and in inter-domain.  See
   detailed discussion on resource lists in Section 4.5.

2.1.  Known Optimizations

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

   o  Dialogs saving optimization - Here we refer to optimizations as
      the resource list RFC [9] or to the URI list subscriptions draft
      [16].  These documents define ways to reduce the number of dialogs
      that are required between the subscriber and the presence system.

         Note that dialog optimization or RLS usage as it is used in
         this document refers to the usage of a URI that represents a
         list of a URI list between domains and not within the same
         domain.  An example is a user Alice in domain example.org that
         subsides to URI of e.g. external-reps-list at example.com or
         uses a URI list to subscribe at on her watch list in
         example.com.  Note also that when calculating the traffic that
         is due to RLS within a domain the traffic between the RLS and
         the presence agents should also be taken into account.
         However, since in this document we are mostly dealing with
         inter- domain traffic, the traffic between the RLS and the
         presence agents was not taken into account.
   o
      Notification optimizations - Here we refer to the optimizations
      that are suggested in the subnot-etags draft [17].  This draft
      suggests ways to suppress the sending of unnecessary notifies when
      for example a subscription is refreshed.  There are other drafts



Houri, et al.            Expires April 25, 2009                 [Page 5]


Internet-Draft          Presence Scaling Analysis           October 2008


      that reduce the size of messages as partial notifications or
      filtering but in this document we mostly care about the amount of
      messages & bandwidth so the partial optimizations can help a bit
      in the bandwidth but will not help in the number of messages.

   In addition to the above optimizations another optimization could
   have been considered but it is not taken into account in the
   computations in this document.  This optimization is the ability to
   have some of the presence information received not by the SIP
   protocol but by offline means as downloading some persistent presence
   information directly from a web site or by some other offline means.
   The calculations here are based on the assumption that all data is
   carried in-bound of the protocol and no optimizations that enable
   getting the presence information via out bound means are taken into
   account.  These optimizations may improve the number of messages and
   number of bytes significantly but they are out of scope for this
   document

2.2.  Assumptions

   In the document several assumptions are used regarding size of
   messages, rate of presence change and more.  It should be noted that
   these assumptions are not directly based on rigorous statistics that
   was done on actual SIP based deployments of presence systems but more
   from some experience on other types of presence based systems.

   The following numbers are given more as examples from real
   deployments and they are not intended to be complete

   In a large consumer network we have seen the following patterns:

   o  Approximately 110 users in the watch list in average.
   o  There are approximately 12 billion status changes a day (139k/
      second) across the network.  Of these, when a proprietary binary
      protocol is used to convey the status changes the average of the
      message is about 188 bytes.  When SIP NOTIFY is used the average
      is about 1228 bytes for the message.
   o  The average of logins/logouts in the system is about 2000 logins
      per second and about 4000 logouts per second.  When something
      happens - either a promotion, contest, or a network hiccup that
      causes many users to login and logout simultaneously, there are
      about 20,000 logins per second.
   o  The peak of the instant messages sent is about 50,000 messages per
      second.

   In a deployment in enterprises we have seen the following patterns:





Houri, et al.            Expires April 25, 2009                 [Page 6]


Internet-Draft          Presence Scaling Analysis           October 2008


   o  Averages watch list size was 200 users.
   o  About half of the registered users were online at peak time
   o  Status change per hour was 2 changes per hour.
   o  The average logins/logouts in the system was about 5 logins per
      second with additional 15 logins/logouts during start/end of day
      rush hours.

   Even though the assumptions in this document are not based on
   rigorous statistical data the target here is not to analyze specific
   system but show that even with VERY moderate assumptions (which are
   even less then the observations mentioned above), the number of
   messages, the network bandwidth, the required state management and
   the load on the CPU are very high.  Real life systems should have a
   much bigger scalability challenges. for example the presence state
   change that we assumed (one presence state change per hour) is maybe
   one of the most moderate assumptions that we have taken.  Experience
   from consumer networks show that the frequency here is much bigger
   and especially with the younger generation that use more presence
   attributes like mood etc..  In an environment where a user may have
   several devices and other resources for presence information as
   geographical location and calendar the frequency of presence state
   changes will be much higher.

   It is very hard to measure presence load since it is very much
   dependent on the behavior of users and behavior of users differs a
   lot.  Some users will have a very small number of presentities in
   their watch list while others may have hundreds if not thousands.
   Some users will change their state a lot and have many sources of
   presence information while others may have very small number of
   changes during the day.  In addition the "rush hour" calculations of
   when the day starts and ends were not included yet in this document.
   Rush hour differs between different enterprises and is still
   different in the consumer presence systems.  It is very hard if not
   impossible to take into a static document all the possible
   combinations.

   Throughout the calculations certain number of users are assumed for
   the different models.  It does not mean that in actual deployments
   all the users of the domain actually subscribed to presence documents
   and/or publish their presence document.  Observing actual deployments
   shows that in the consumer market the number of users that use
   presence services may be 10 percent or less of the registered users.
   In the enterprise market numbers tend to be around 50 percent of the
   actual enterprise registered users.

   The same is correct for the number for of watched presentities per
   watcher. if only some percent of the domain users are online at a
   given time then this number should have been that percentage.



Houri, et al.            Expires April 25, 2009                 [Page 7]


Internet-Draft          Presence Scaling Analysis           October 2008


   However, trying to add this assumption to the calculations will make
   the calculations more complex then they are since the affect of the
   watched presentities that are not online will need to be taken into
   account.  This means that empty notify should be sent for those when
   the subscription is created and there is no updates on them.  In
   order to make the computations less complex (they are complex enough
   as they are), the number of the watched presentities that is used in
   the calculations is the number of the federated presentities from the
   watcher list that are online.

2.3.  Analysis

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

   o  SUBSCRIBE/200
   o  Initial NOTIFY/200
   o  (j) NOTIFY/200 where 'j' is the number of presence changes seen by
      the watcher
   o  (k) SUBSCRIBE/200 where 'k' is the number of subscription dialog
      refresh periods
   o  SUBSCRIBE/200 with Expires = 0 to terminate the dialog
   o  NOTIFY/200 ending the dialog

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

   o  Number of watchers connected to the system
   o  Number of presentities connected to the system
   o  Frequency of changes to presence information

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

2.3.1.  Constants

   The following are number of "constants" that we use in the
   calculations.  Some of the constants are used throughout the
   calculation while other change between use cases

   o  (C01) Subscription lifetime (hours)- The assumed lifetime of a
      subscription in hours.  We assume 8 hours for all calculations.
   o  (C02) Presence state changes / hour - The average time that a
      presentity changes his/hers status in one hour.  We assumed 3
      times per hour for most calculations.  Note that for some users in



Houri, et al.            Expires April 25, 2009                 [Page 8]


Internet-Draft          Presence Scaling Analysis           October 2008


      consumer messaging systems, the actual number of changes is likely
      to be much higher.
   o  (C03) Subscription refresh interval / hour - The duration of the
      SUBSCRIBE session after which it needs to be refreshed.  We
      assumed that the duration is one hour.
   o  (C04) Total federated presentities per watcher - The number of
      presentities that the watcher is watching.  The number here
      changes in this document according to the type of the specific
      deployment.
   o  (C05) Number of dialogs to maintain per watcher - The number of
      the SUBSCRIBE dialogs that are maintained per watcher. if a dialog
      optimization is not assumed this number is equal to A04, otherwise
      it is 1.
   o  (C06) Total number of watchers in the federated presence domains.
      The number here is the number of all watchers in all the federated
      domains.
   o  (C07) SUBSCRIBE message size in bytes.  We assume 450 bytes in all
      calculations.  The size is based on a typical SUBSCIRBE taken from
      RFCs.
   o  (C08) 200 OK for SUBSCRIBE message size in bytes.  We assume 370
      bytes in all calculations.  The size is based on a typical 200 OK
      taken from RFCs.
   o  (C09) NOTIFY message size not including the presence document.
      The size of this message for a single presentity is assumed to be
      500 bytes for the NOTIFY message itself (based on sizes from
      examples in RFCs).
   o  (C10) 200 OK for NOTIFY message size in bytes.  We assume 370
      bytes in all calculations.  The size is based on a typical 200 OK
      taken from RFCs.
   o  (C11) Size of an average presence document.  In the previous
      version of this document we have used only the size of 3000 bytes
      for a presence document.  This number was calculated based on
      examples of rich presence document in RFCs.  Due to discussion in
      the SIMPLE list where it was claimed that it may be too big and
      due to the fact that we are talking here about federation between
      communities where the rich presence document may be of less use,
      we have done all the calculations with two sizes of presence
      document.  One size is the minimal size of the PIDF [4] document
      which was taken to be 350 bytes based on examples from RFCs and
      the other size is the 3000 bytes for rich presence document [5].
      It should be noted that assuming 3000 bytes for presence document
      is relatively modest if we take into account multiple devices and
      location information.
   o  (C12) The size of NOTIFY when partial [12] notification is being
      done.  We have taken this size to be 200 bytes.  The size is much
      smaller then the example that is given in [12] but the example
      given there assumes multiple changes in the presence document and
      here we assume a single change.



Houri, et al.            Expires April 25, 2009                 [Page 9]


Internet-Draft          Presence Scaling Analysis           October 2008



         When dialog optimization [9] is used, an RLMI document is being
         sent and that document contains the presence documents for the
         users that are in the watch list.  In previous version of this
         document we have omitted the overhead of the RLMI document.
         This "bug" was found by Victoria Beltran-Martinez and is being
         fixed in this document by adding the constants C13, C14 and C15
         to the calculations
   o
      (C13) Item size per each contact in RLMI document, 160 bytes.
   o  (C14) The size of the multipart boundary in RLMI notifications,
      144 bytes.
   o  (C15) The size of the XML root node in RLMI document (once per
      notification), 144 bytes.

2.3.2.  Initial Messages

   The following are the calculations for the messages in the initial
   phase of the establishment of the subscriptions.  The calculations
   contain both number of messages and the number of bytes.

   o  (I01) Number of initial SUBSCRIBE messages per watcher = C05.
   o  (I02) Number of initial 200 OK messages for SUBSCRIBE messages per
      watcher = C05.
   o  (I03) Number of initial NOTIFY messages per watcher = C05.
   o  (I04) Number of initial 200 OK messages for NOTIFY messages per
      watcher = C05.
   o  (I05) Total number and bytes of initial SUBSCRIBE messages for all
      watchers = Number - I01*C06, Bytes - I01*C06*C07.
   o  (I06) Total number and bytes of initial 200 OK for SUBSCRIBE
      messages for all watchers = Number - I01*C06, Bytes - I01*C06*C08.
   o  (I07) Total number and bytes of initial NOTIFY messages for all
      watchers = Number - I01*C06, The calculation for the number of
      bytes is different when dialog optimization is used or not.  When
      dialog optimization is not applied the number of bytes will be
      calculated by: (I01*C06*C09)+(I01*C06*C11) and when dialog
      optimization is applied the number of bytes will be calculated by
      (I01*C06*(C09+C14+C15))+(I01*C06*C04*(C11+C13+C14)).
   o  (I08) Total number and bytes of initial 200 OK for NOTIFY messages
      for all watchers = Number - I04*C06, Bytes - I04*C06*C10.
   o  (I09) Total number and bytes of initial messages per day = Number
      - numbers in I05+I06+I07+I08, Size -sizes in I05+I06+I07+I08.

2.3.3.  Steady State Messages

   Here we describe the calculations for the steady state messages.
   Steady state is the time between the initial subscription and the
   tear down of the subscription.  It contains the notifies due to state



Houri, et al.            Expires April 25, 2009                [Page 10]


Internet-Draft          Presence Scaling Analysis           October 2008


   change and the subscription refreshes.

   o  (S01) NOTIFY messages due to state change per watched presentity
      per day (less 2 since the NOTIFY for initial and terminating state
      is calculated in the initial and terminating calculations) =
      (C02*C01-2).
   o  (S02) 200 (for NOTIFY due to state change) messages per watched
      presentity per day (less 2 since the NOTIFY for initial and
      terminating state is calculated in the initial and terminating
      calculations) = (C02*C01-2).
   o  (S03) Total number and size of messages due to state change per
      day = Number - (S01+S02)*C06*C04.  The calculation for the number
      of bytes is different when dialog optimization is used or not.
      When dialog optimization is not applied the number of bytes will
      be calculated by: (C06*C04)*((S01*(C09+C11))+(S02*C10)) and when
      dialog optimization is applied the number of bytes will be
      calculated by (C06*C04)*((S01*(C09+C11+C13+C14+C15+C14))+
      (S02*C10)).  This includes the the multipart boundary of the
      resource list.  Note that for dialog optimization it is assumed
      that only a single presentity is changed and partial state
      notification is used.
   o  (S04) Number of SUBSCRIBE messages for refreshes per watcher per
      day = ((C01/C03)-1)*C05.  One is subtracted since the termination
      is calculated separately. for example if there are 8 hours in the
      day and a refresh should occur every hour, there are 7 refreshes
      during the day and not 8.
   o  (S05) Number of 200 OK messages for SUBSCRIBE messages for
      refreshes per watcher per day = ((C01/C03)-1)*C05.
   o  (S06) Number of NOTIFY messages for refreshes per watcher per day
      = ((C01/C03)-1)*C05.  Since when NOTIFY optimization is used [17]
      there is no need to send NOTIFY for refreshes, S06 will be zero
      when NOTIFY optimizations is used.
   o  (S07) Number of 200 OK messages for NOTIFY messages for refreshes
      per watcher per day = ((C01/C03)-1)*C05.  Since when NOTIFY
      optimization is used [17] there is no need to send NOTIFY for
      refreshes, S07 will be zero when NOTIFY optimizations is used.
   o  (S08) Total number and size of messages due to SUBSCRIBE refreshes
      per day = Number - (S04+S05+S06+S07)*C06.  The number of bytes is
      calculated by adding the SUBSCIRBE bytes (S04*C06*C07), the OK for
      SUBSCRIBE bytes (S05*C06*C08), the NOTIFY bytes C06*(S06*(C09+
      C11)) and the OK for NOTIFY (S07*C06*C10).  Note that the formula
      for the notify bytes is for the dialog optimization is not used
      and when it used the formula will be: C06*(S06*((C09+C14+C15)+
      (C04*(C11+C13+C14)))).  Note that a full state should be given in
      SUBSCRIBE refreshes in resource lists.  See section 5.2 in [9].
      The fact that the full state needs to be returned in a NOTIFY
      response to refresh makes the NOTIFY optimization more efficient
      in conjunction with the dialog optimization.



Houri, et al.            Expires April 25, 2009                [Page 11]


Internet-Draft          Presence Scaling Analysis           October 2008


   o  (S09) Total number and bytes of steady messages per day = Number -
      numbers in S03+S08, Bytes - sizes in S03+S08.

2.3.4.  Termination Messages

   The following are the calculations for the messages in the
   termination phase of the of the subscriptions.  The calculations
   contain both number of messages and the number of bytes.

   o  (T01) Number of terminating SUBSCRIBE messages per watcher = C05.
   o  (T02) Number of terminating 200 OK messages for SUBSCRIBE messages
      per watcher = C05.
   o  (T03) Number of terminating NOTIFY messages per watcher = C05.
      Since when NOTIFY optimization is used [17] there is no need to
      send NOTIFY for terminations, T03 will be zero when NOTIFY
      optimization is used.
   o  (T04) Number of terminating 200 OK messages for NOTIFY messages
      per watcher = C05.  Since when NOTIFY optimization is used [17]
      there is no need to send NOTIFY for terminations, T04 will be zero
      when NOTIFY optimization is used.
   o  (T05) Total number and bytes of terminating SUBSCRIBE messages for
      all watchers = Number - T01*C06, Bytes - T01*C06*C07.
   o  (T06) Total number and bytes of terminating 200 OK for SUBSCRIBE
      messages for all watchers = Number - T01*C06, Bytes - T01*C06*C08.
   o  (T07) Total number and bytes of terminating NOTIFY messages for
      all watchers = Number - T01*C06, The number of bytes is calculated
      to be: (T03*C06*(C09+C11) when dialog optimization is not used
      and: (T03*C06*(C09+C14+C15))+(T03*C06*C04*(C11+C13+C14)) when
      dialog optimization is used.  Note that a full state should be
      given in SUBSCRIBE refreshes in resource lists.  See section 5.2
      in [9].
   o  (T08) Total number and bytes of terminating 200 OK for NOTIFY
      messages for all watchers = Number - T04*C06, Bytes - T04*C06*C10.
   o  (T09) Total number and bytes of terminating messages per day =
      Number - numbers in T05+T06+T07+T08, Size -sizes in T05+T06+T07+
      T08.

2.3.5.  Bottom Line

   The following are the calculations of several totals that are based
   on the above calculations.

   o  (B01) Total number of messages and bytes during the day = Messages
      - Number of messages in I09+S09+T09, Bytes - Number of bytes in
      I09+S09+T09.
   o  (B02) Total number of messages and bytes per second = Messages -
      Number of messages in B01/(C01*3600) Bytes - Number of bytes in
      B01/(C01*3600).



Houri, et al.            Expires April 25, 2009                [Page 12]


Internet-Draft          Presence Scaling Analysis           October 2008


   o  (B02) Total number of message and bytes per user per day =
      Messages - number of messages in B01/C06 Bytes - Number of bytes
      in B01/C06.

2.3.6.  Rush Hour Calculations

   With the way that the calculations are built, it is relatively easy
   to see the affect of rush hours at the beginning and the end of the
   day. for the beginning of the day we should look at the numbers of
   "(I09) Total number and bytes of initial messages per day" and for
   the end of the day we should look at the number of "(T09) Total
   number and bytes of terminating messages per day".  Taking these
   numbers with some assumed percentage of the numbers of users that log
   in at the same hour should give good indication for the rush hour
   load.

2.4.  No optimizations used

   The following table uses some common presence characteristics to
   demonstrate the effect these factors have on state and message rate
   within a presence domain using base SIP protocols without any
   proposed optimizations.  In this example, there are two presence
   domains with total of 40,000 federating users with an average of 4
   contacts in the peer domain.  Note that the main calculation is done
   for a presence document size of 350 bytes which is the base PIDF [4]
   document size but the bottom line calculation is also given for a
   presence document size for rich presence [5] which is assumed to be
   3000 bytes based on the examples given in the RFCs.  This two folded
   calculation is done for every use case in this document.

   ** Constants
   (C01) Subscription lifetime (hours)...........................8
   (C02) Presence state changes / hour...........................3
   (C03) Subscription refresh interval / hour....................1
   (C04) Total federated presentities per watcher................4
   (C05) Number of dialogs to maintain per watcher...............4
   (C06) Total number of watchers in domains................40,000
   (C07) SUBSCRIBE message size in bytes.......................450
   (C08) 200 OK for SUBSCRIBE message size in bytes............370
   (C09) NOTIFY message size not including presence doc........500
   (C10) 200 OK for NOTIFY message size in bytes...............370
   (C11) Size of an average presence document..................350

   ** Initial Messages
   (I01) Initial SUBSCRIBE msgs per watcher......................4
   (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............4
   (I03) Initial NOTIFY msgs per watcher.........................4
   (I04) Initial 200 OK msgs (NOTIFY) per watcher................4



Houri, et al.            Expires April 25, 2009                [Page 13]


Internet-Draft          Presence Scaling Analysis           October 2008


   (I05) Total number & bytes of initial SUBSCRIBE msgs
             Number of msgs for all watchers...............160,000
             Bytes for all watchers.....................72,000,000
   (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers...............160,000
             Bytes for all watchers.....................59,200,000
   (I07) Total number & bytes of initial NOTIFY msgs
             Number of msgs for all watchers...............160,000
             Bytes for all watchers....................136,000,000
   (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
             Number of msgs for all watchers...............160,000
             Bytes for all watchers.....................59,200,000
   (I09) Total number & bytes of initial messages per day
             Number of msgs for all watchers...............640,000
             Bytes for all watchers....................326,400,000

   ** Steady State Messages
   (S01) NOTIFY msgs due to state change
             per watched presentity per day.....................22
   (S02) 200 (for NOTIFY due to state change) msgs
             per watched presentity per day.....................22
   (S03) Total number and size of msgs due to state change per day
             Number of msgs for all watchers.............7,040,000
             Bytes for all watchers..................4,294,400,000
   (S04) Number of SUBSCRIBE msgs for refreshes
             per watcher per day................................28
   (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
             per watcher per day................................28
   (S06) Number of NOTIFY msgs for refreshes
             per watcher per day................................28
   (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
             per watcher per day................................28
   (S08) Total number and size of msgs due to SUBSCRIBE refreshes
             Number of msgs for all watchers per day.....4,480,000
             Bytes for all watchers per day..........2,284,800,000
   (S09) Total number & bytes of steady messages per day
             Number of msgs for all watchers............11,520,000
             Bytes for all watchers..................6,579,200,000

   ** Termination Messages
   (T01) Terminating SUBSCRIBE msgs per watcher..................4
   (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........4
   (T03) Terminating NOTIFY msgs per watcher.....................4
   (T04) Terminating 200 OK msgs (NOTIFY) per watcher............4
   (T05) Total number & bytes of Terminating SUBSCRIBE msgs
             Number of msgs for all watchers.............. 160,000
             Bytes for all watchers.....................72,000,000
   (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs



Houri, et al.            Expires April 25, 2009                [Page 14]


Internet-Draft          Presence Scaling Analysis           October 2008


             Number of msgs for all watchers...............160,000
             Bytes for all watchers.....................59,200,000
   (T07) Total number & bytes of terminating NOTIFY msgs
             Number of msgs for all watchers...............160,000
             Bytes for all watchers....................136,000,000
   (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
             Number of msgs for all watchers...............160,000
             Bytes for all watchers.....................59,200,000
   (T09) Total number & bytes of terminating messages per day
             Number of msgs for all watchers...............640,000
             Bytes for all watchers....................326,400,000

   ** Bottom Line
   (B01) Total of messages between domains..............12,800,000
         Total of bytes between domains (PD=350).....7,232,000,000
         Total of bytes between domains (PD=3000)...20,376,000,000
   (B02) Total number of messages / second.. ..................444
         Total of bytes per second (PD=350)................251,111
         Total of bytes per second (PD=3000)...............707,500
   (B03) Total number of by msgs per user/day......... ........320
         Total number of bytes per user/day (PD=350).......180,800
         Total number of bytes per user/day (PD=3000)......509,400

                      Figure 1: No optimizations used

2.5.  Dialog optimization used

   The same analysis provided above is repeated here with the assumption
   that the dialog optimization is applied.  Note that while the sign-in
   (ramp up) and sign-out messages flows are positively affected, the
   steady state rates are not.

   ** Constants
   (C01) Subscription lifetime (hours)...........................8
   (C02) Presence state changes / hour...........................3
   (C03) Subscription refresh interval / hour....................1
   (C04) Total federated presentities per watcher................4
   (C05) Number of dialogs to maintain per watcher...............1
   (C06) Total number of watchers in domains................40,000
   (C07) SUBSCRIBE message size in bytes.......................450
   (C08) 200 OK for SUBSCRIBE message size in bytes............370
   (C09) NOTIFY message size not including presence doc........500
   (C10) 200 OK for NOTIFY message size in bytes...............370
   (C11) Size of an average presence document..................350
   (C13) Additional data per document in RLMI..................160
   (C14) Multiparty boundary in RLMI document..................144
   (C15) XML root node in RLMI document........................144




Houri, et al.            Expires April 25, 2009                [Page 15]


Internet-Draft          Presence Scaling Analysis           October 2008


   ** Initial Messages
   (I01) Initial SUBSCRIBE msgs per watcher......................1
   (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1
   (I03) Initial NOTIFY msgs per watcher.........................1
   (I04) Initial 200 OK msgs (NOTIFY) per watcher................1
   (I05) Total number & bytes of initial SUBSCRIBE msgs
             Number of msgs for all watchers................40,000
             Bytes for all watchers.....................18,000,000
   (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers................40,000
             Bytes for all watchers.....................14,800,000
   (I07) Total number & bytes of initial NOTIFY msgs
             Number of msgs for all watchers................40,000
             Bytes for all watchers....................136,160,000
   (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
             Number of msgs for all watchers................40,000
             Bytes for all watchers.....................14,800,000
   (I09) Total number & bytes of initial messages per day
             Number of msgs for all watchers...............160,000
             Bytes for all watchers....................183,760,000

   ** Steady State Messages
   (S01) NOTIFY msgs due to state change
             per watched presentity per day.....................22
   (S02) 200 (for NOTIFY due to state change) msgs
             per watched presentity per day.....................22
   (S03) Total number and size of msgs due to state change per day
             Number of msgs for all watchers.............7,040,000
             Bytes for all watchers..................6,378,240,000
   (S04) Number of SUBSCRIBE msgs for refreshes
             per watcher per day.................................7
   (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
             per watcher per day.................................7
   (S06) Number of NOTIFY msgs for refreshes
             per watcher per day.................................7
   (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
             per watcher per day.................................7
   (S08) Total number and size of msgs due to SUBSCRIBE refreshes
             Number of msgs for all watchers per day.....1,120,000
             Bytes for all watchers per day..........1,286,320,000
   (S09) Total number & bytes of steady messages per day
             Number of msgs for all watchers.............8,160,000
             Bytes for all watchers..................7,664,560,000

   ** Termination Messages
   (T01) Terminating SUBSCRIBE msgs per watcher..................1
   (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1
   (T03) Terminating NOTIFY msgs per watcher.....................1



Houri, et al.            Expires April 25, 2009                [Page 16]


Internet-Draft          Presence Scaling Analysis           October 2008


   (T04) Terminating 200 OK msgs (NOTIFY) per watcher............1
   (T05) Total number & bytes of Terminating SUBSCRIBE msgs
             Number of msgs for all watchers................40,000
             Bytes for all watchers.....................18,000,000
   (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers................40,000
             Bytes for all watchers.....................14,800,000
   (T07) Total number & bytes of terminating NOTIFY msgs
             Number of msgs for all watchers................40,000
             Bytes for all watchers....................136,160,000
   (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
             Number of msgs for all watchers................40,000
             Bytes for all watchers.....................14,800,000
   (T09) Total number & bytes of terminating messages per day
             Number of msgs for all watchers...............160,000
             Bytes for all watchers....................183,760,000

   ** Bottom Line
   (B01) Total of messages between domains...............8,480,000
         Total of bytes between domains (PD=350).....8,032,080,000
         Total of bytes between domains (PD=3000)...21,176,080,000
   (B02) Total number of messages / second.....................294
         Total of bytes per second (PD=350)................278,892
         Total of bytes per second (PD=3000)...............735,281
   (B03) Total number of by msgs per user/day..................212
         Total number of bytes per user/day (PD=350).......200,802
         Total number of bytes per user/day (PD=3000)......529,042

                    Figure 2: Dialog optimization used

2.6.  NOTIFY optimization used

   The initial analysis of analysis provided in Figure 1 is repeated
   here with the assumption that the notify optimization is applied.
   The optimization saves the need for NOTIFY upon refreshing a
   SUBSCRIBE if there was no change since the last NOTIFY.  It is
   assumed here that there will be no NOTIFY message for a SUBSCRIBE
   refreshes and terminations.  As should be expected this optimization
   affects the steady and termination state and does not affect the
   initial state.

   ** Constants
   (C01) Subscription lifetime (hours)...........................8
   (C02) Presence state changes / hour...........................3
   (C03) Subscription refresh interval / hour....................1
   (C04) Total federated presentities per watcher................4
   (C05) Number of dialogs to maintain per watcher...............4
   (C06) Total number of watchers in domains................40,000



Houri, et al.            Expires April 25, 2009                [Page 17]


Internet-Draft          Presence Scaling Analysis           October 2008


   (C07) SUBSCRIBE message size in bytes.......................450
   (C08) 200 OK for SUBSCRIBE message size in bytes............370
   (C09) NOTIFY message size not including presence doc........500
   (C10) 200 OK for NOTIFY message size in bytes...............370
   (C11) Size of an average presence document..................350

   ** Initial Messages
   (I01) Initial SUBSCRIBE msgs per watcher......................4
   (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............4
   (I03) Initial NOTIFY msgs per watcher.........................4
   (I04) Initial 200 OK msgs (NOTIFY) per watcher................4
   (I05) Total number & bytes of initial SUBSCRIBE msgs
             Number of msgs for all watchers...............160,000
             Bytes for all watchers.....................72,000,000
   (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers...............160,000
             Bytes for all watchers.....................59,200,000
   (I07) Total number & bytes of initial NOTIFY msgs
             Number of msgs for all watchers...............160,000
             Bytes for all watchers....................136,000,000
   (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
             Number of msgs for all watchers...............160,000
             Bytes for all watchers.....................59,200,000
   (I09) Total number & bytes of initial messages per day
             Number of msgs for all watchers...............640,000
             Bytes for all watchers....................326,400,000

   ** Steady State Messages
   (S01) NOTIFY msgs due to state change
             per watched presentity per day.....................22
   (S02) 200 (for NOTIFY due to state change) msgs
             per watched presentity per day.....................22
   (S03) Total number and size of msgs due to state change per day
             Number of msgs for all watchers.............7,040,000
             Bytes for all watchers..................4,294,400,000
   (S04) Number of SUBSCRIBE msgs for refreshes
             per watcher per day................................28
   (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
             per watcher per day................................28
   (S06) Number of NOTIFY msgs for refreshes
             per watcher per day.................................0
   (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
             per watcher per day.................................0
   (S08) Total number and size of msgs due to SUBSCRIBE refreshes
             Number of msgs for all watchers per day.....2,240,000
             Bytes for all watchers per day............918,400,000
   (S09) Total number & bytes of steady messages per day
             Number of msgs for all watchers.............9,280,000



Houri, et al.            Expires April 25, 2009                [Page 18]


Internet-Draft          Presence Scaling Analysis           October 2008


             Bytes for all watchers..................5,212,800,000

   ** Termination Messages
   (T01) Terminating SUBSCRIBE msgs per watcher..................4
   (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........4
   (T03) Terminating NOTIFY msgs per watcher.....................0
   (T04) Terminating 200 OK msgs (NOTIFY) per watcher............0
   (T05) Total number & bytes of Terminating SUBSCRIBE msgs
             Number of msgs for all watchers.............. 160,000
             Bytes for all watchers.....................72,000,000
   (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers...............160,000
             Bytes for all watchers.....................59,200,000
   (T07) Total number & bytes of terminating NOTIFY msgs
             Number of msgs for all watchers.....................0
             Bytes for all watchers..............................0
   (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
             Number of msgs for all watchers.....................0
             Bytes for all watchers..............................0
   (T09) Total number & bytes of terminating messages per day
             Number of msgs for all watchers...............320,000
             Bytes for all watchers....................131,200,000

   ** Bottom Line
   (B01) Total of messages between domains..............10,240,000
         Total of bytes between domains (PD=350).....5,670,400,000
         Total of bytes between domains (PD=3000)...15,422,400,000
   (B02) Total number of messages / second.....................356
         Total of bytes per second (PD=350)................196,889
         Total of bytes per second (PD=3000)...............535,500
   (B03) Total number of by msgs per user/day..................256
         Total number of bytes per user/day (PD=350).......141,760
         Total number of bytes per user/day (PD=3000)......385,560

                    Figure 3: NOTIFY optimization used

2.7.  Dialog & NOTIFY optimizations used

   Here both optimizations are combined.  In all the subsequent use
   cases we will show only the analysis with no optimizations and with
   both optimizations combined.

   ** Constants
   (C01) Subscription lifetime (hours)...........................8
   (C02) Presence state changes / hour...........................3
   (C03) Subscription refresh interval / hour....................1
   (C04) Total federated presentities per watcher................4
   (C05) Number of dialogs to maintain per watcher...............1



Houri, et al.            Expires April 25, 2009                [Page 19]


Internet-Draft          Presence Scaling Analysis           October 2008


   (C06) Total number of watchers in domains................40,000
   (C07) SUBSCRIBE message size in bytes.......................450
   (C08) 200 OK for SUBSCRIBE message size in bytes............370
   (C09) NOTIFY message size not including presence doc........500
   (C10) 200 OK for NOTIFY message size in bytes...............370
   (C11) Size of an average presence document..................350
   (C13) Additional data per document in RLMI..................160
   (C14) Multiparty boundary in RLMI document..................144
   (C15) XML root node in RLMI document........................144

   ** Initial Messages
   (I01) Initial SUBSCRIBE msgs per watcher......................1
   (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1
   (I03) Initial NOTIFY msgs per watcher.........................1
   (I04) Initial 200 OK msgs (NOTIFY) per watcher................1
   (I05) Total number & bytes of initial SUBSCRIBE msgs
             Number of msgs for all watchers................40,000
             Bytes for all watchers.....................18,000,000
   (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers................40,000
             Bytes for all watchers.....................14,800,000
   (I07) Total number & bytes of initial NOTIFY msgs
             Number of msgs for all watchers................40,000
             Bytes for all watchers....................136,160,000
   (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
             Number of msgs for all watchers................40,000
             Bytes for all watchers.....................14,800,000
   (I09) Total number & bytes of initial messages per day
             Number of msgs for all watchers...............160,000
             Bytes for all watchers....................183,760,000

   ** Steady State Messages
   (S01) NOTIFY msgs due to state change
             per watched presentity per day.....................22
   (S02) 200 (for NOTIFY due to state change) msgs
             per watched presentity per day.....................22
   (S03) Total number and size of msgs due to state change per day
             Number of msgs for all watchers.............7,040,000
             Bytes for all watchers..................6,378,240,000
   (S04) Number of SUBSCRIBE msgs for refreshes
             per watcher per day.................................7
   (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
             per watcher per day.................................7
   (S06) Number of NOTIFY msgs for refreshes
             per watcher per day.................................0
   (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
             per watcher per day.................................0
   (S08) Total number and size of msgs due to SUBSCRIBE refreshes



Houri, et al.            Expires April 25, 2009                [Page 20]


Internet-Draft          Presence Scaling Analysis           October 2008


             Number of msgs for all watchers per day.......560,000
             Bytes for all watchers per day............229,600,000
   (S09) Total number & bytes of steady messages per day
             Number of msgs for all watchers.............7,600,000
             Bytes for all watchers..................6,607,840,000

   ** Termination Messages
   (T01) Terminating SUBSCRIBE msgs per watcher..................1
   (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1
   (T03) Terminating NOTIFY msgs per watcher.....................0
   (T04) Terminating 200 OK msgs (NOTIFY) per watcher............0
   (T05) Total number & bytes of Terminating SUBSCRIBE msgs
             Number of msgs for all watchers................40,000
             Bytes for all watchers.....................18,000,000
   (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers................40,000
             Bytes for all watchers.....................14,800,000
   (T07) Total number & bytes of terminating NOTIFY msgs
             Number of msgs for all watchers.....................0
             Bytes for all watchers..............................0
   (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
             Number of msgs for all watchers.....................0
             Bytes for all watchers..............................0
   (T09) Total number & bytes of terminating messages per day
             Number of msgs for all watchers................80,000
             Bytes for all watchers.....................32,800,000

   ** Bottom Line
   (B01) Total of messages between domains...............7,840,000
         Total of bytes between domains (PD=350).....6,824,400,000
         Total of bytes between domains (PD=3000)...16,576,400,000
   (B02) Total number of messages / second.....................272
         Total of bytes per second (PD=350)................236,958
         Total of bytes per second (PD=3000)...............575,569
   (B03) Total number of by msgs per user/day..................196
         Total number of bytes per user/day (PD=350).......170,610
         Total number of bytes per user/day (PD=3000)......414,410

               Figure 4: Dialog & NOTIFY optimizations used

2.8.  Presence Federation Scenarios

   While scalability issues exist in any large deployment, certain
   characteristics make the deployment conducive to the existing
   optimizations, and others have characteristics that do not.
   Following is a list of federation scenarios that have varying usage
   characteristics.  For each, a message rate and bandwidth table is
   provided reflecting typical changes message rates.  Those



Houri, et al.            Expires April 25, 2009                [Page 21]


Internet-Draft          Presence Scaling Analysis           October 2008


   characteristics can alter the overall effectiveness of existing
   optimizations.

   Note that the number of users used is not the number of the users in
   the domains but the actual logged in users.  As was mentioned before
   not all the domain users will use the presence service at the same
   time.  The number used for number of watchers and number of watched
   presentities are for online users.

2.8.1.  Widely distributed inter-domain presence

   In some environments presence federation may be very common, perhaps
   even more common than intra-domain presence.  An example of this type
   of environment is a small ISV or public server.  Users in that small
   ISV are not likely to subscribe to the presence of other users in the
   their server since they do not necessarily have any relationship with
   each other aside from receiving service from the same provider.  They
   are much more likely to be subscribed to the presence of users in one
   of the federated domains (whether in consumer domains, academic,
   other ISVs, etc).  Common characteristics of this deployment are:

   o  Federated subscriptions are the majority of subscription traffic
   o  Individual users are likely to subscribe to multiple users in any
      one domain
   o  The intersection of users in the deployment watching the same
      presentities is quite small (i.e., probability that watchers in
      the domain subscribe to the same presentity is low)

   To account for the extraordinarily high percentage of federation
   traffic, the number of federated presentities is increased to 20.
   The number of watchers in the domain could also be adjusted to
   account for an expected larger community of users being peered with,
   it is omitted here for simplification

   The first table below provides the calculations without optimizations
   the second table provides the calculations with optimization.

   ** Constants
   (C01) Subscription lifetime (hours)...........................8
   (C02) Presence state changes / hour...........................3
   (C03) Subscription refresh interval / hour....................1
   (C04) Total federated presentities per watcher...............20
   (C05) Number of dialogs to maintain per watcher..............20
   (C06) Total number of watchers in domains................40,000
   (C07) SUBSCRIBE message size in bytes.......................450
   (C08) 200 OK for SUBSCRIBE message size in bytes............370
   (C09) NOTIFY message size not including presence doc........500
   (C10) 200 OK for NOTIFY message size in bytes...............370



Houri, et al.            Expires April 25, 2009                [Page 22]


Internet-Draft          Presence Scaling Analysis           October 2008


   (C11) Size of an average presence document..................350

   ** Initial Messages
   (I01) Initial SUBSCRIBE msgs per watcher.....................20
   (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher............20
   (I03) Initial NOTIFY msgs per watcher........................20
   (I04) Initial 200 OK msgs (NOTIFY) per watcher...............20
   (I05) Total number & bytes of initial SUBSCRIBE msgs
             Number of msgs for all watchers...............800,000
             Bytes for all watchers....................360,000,000
   (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers...............800,000
             Bytes for all watchers....................296,000,000
   (I07) Total number & bytes of initial NOTIFY msgs
             Number of msgs for all watchers...............800,000
             Bytes for all watchers....................680,000,000
   (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
             Number of msgs for all watchers...............800,000
             Bytes for all watchers....................296,000,000
   (I09) Total number & bytes of initial messages per day
             Number of msgs for all watchers.............3,200,000
             Bytes for all watchers..................1,632,000,000

   ** Steady State Messages
   (S01) NOTIFY msgs due to state change
             per watched presentity per day.....................22
   (S02) 200 (for NOTIFY due to state change) msgs
             per watched presentity per day.....................22
   (S03) Total number and size of msgs due to state change per day
             Number of msgs for all watchers............35,200,000
             Bytes for all watchers.................21,472,000,000
   (S04) Number of SUBSCRIBE msgs for refreshes
             per watcher per day...............................140
   (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
             per watcher per day...............................140
   (S06) Number of NOTIFY msgs for refreshes
             per watcher per day...............................140
   (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
             per watcher per day...............................140
   (S08) Total number and size of msgs due to SUBSCRIBE refreshes
             Number of msgs for all watchers per day....22,400,000
             Bytes for all watchers per day.........11,424,000,000
   (S09) Total number & bytes of steady messages per day
             Number of msgs for all watchers............57,600,000
             Bytes for all watchers.................32,896,000,000

   ** Termination Messages
   (T01) Terminating SUBSCRIBE msgs per watcher.................20



Houri, et al.            Expires April 25, 2009                [Page 23]


Internet-Draft          Presence Scaling Analysis           October 2008


   (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........20
   (T03) Terminating NOTIFY msgs per watcher....................20
   (T04) Terminating 200 OK msgs (NOTIFY) per watcher...........20
   (T05) Total number & bytes of Terminating SUBSCRIBE msgs
             Number of msgs for all watchers...............800,000
             Bytes for all watchers....................360,000,000
   (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers...............800,000
             Bytes for all watchers....................296,000,000
   (T07) Total number & bytes of terminating NOTIFY msgs
             Number of msgs for all watchers...............800,000
             Bytes for all watchers....................680,000,000
   (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
             Number of msgs for all watchers...............800,000
             Bytes for all watchers....................296,000,000
   (T09) Total number & bytes of terminating messages per day
             Number of msgs for all watchers.............3,200,000
             Bytes for all watchers..................1,632,000,000

   ** Bottom Line
   (B01) Total of messages between domains..............64,000,000
         Total of bytes between domains (PD=350)....36,160,000,000
         Total of bytes between domains (PD=3000)..101,880,000,000
   (B02) Total number of messages / second...................2,222
         Total of bytes per second (PD=350)..............1,255,556
         Total of bytes per second (PD=3000).............3,537,500
   (B03) Total number of by msgs per user/day................1,600
         Total number of bytes per user/day (PD=350).......904,000
         Total number of bytes per user/day (PD=3000).....,547,000

      Figure 5: Widely distributed inter-domain with no optimizations


   ** Constants
   (C01) Subscription lifetime (hours)...........................8
   (C02) Presence state changes / hour...........................3
   (C03) Subscription refresh interval / hour....................1
   (C04) Total federated presentities per watcher...............20
   (C05) Number of dialogs to maintain per watcher...............1
   (C06) Total number of watchers in domains................40,000
   (C07) SUBSCRIBE message size in bytes.......................450
   (C08) 200 OK for SUBSCRIBE message size in bytes............370
   (C09) NOTIFY message size not including presence doc........500
   (C10) 200 OK for NOTIFY message size in bytes...............370
   (C11) Size of an average presence document..................350
   (C13) Additional data per document in RLMI..................160
   (C14) Multiparty boundary in RLMI document..................144
   (C15) XML root node in RLMI document........................144



Houri, et al.            Expires April 25, 2009                [Page 24]


Internet-Draft          Presence Scaling Analysis           October 2008


   ** Initial Messages
   (I01) Initial SUBSCRIBE msgs per watcher......................1
   (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1
   (I03) Initial NOTIFY msgs per watcher.........................1
   (I04) Initial 200 OK msgs (NOTIFY) per watcher................1
   (I05) Total number & bytes of initial SUBSCRIBE msgs
             Number of msgs for all watchers................40,000
             Bytes for all watchers.....................18,000,000
   (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers................40,000
             Bytes for all watchers.....................14,800,000
   (I07) Total number & bytes of initial NOTIFY msgs
             Number of msgs for all watchers................40,000
             Bytes for all watchers....................554,720,000
   (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
             Number of msgs for all watchers................40,000
             Bytes for all watchers.....................14,800,000
   (I09) Total number & bytes of initial messages per day
             Number of msgs for all watchers...............160,000
             Bytes for all watchers....................602,320,000

   ** Steady State Messages
   (S01) NOTIFY msgs due to state change
             per watched presentity per day.....................22
   (S02) 200 (for NOTIFY due to state change) msgs
             per watched presentity per day.....................22
   (S03) Total number and size of msgs due to state change per day
             Number of msgs for all watchers............35,200,000
             Bytes for all watchers.................31,891,200,000
   (S04) Number of SUBSCRIBE msgs for refreshes
             per watcher per day.................................7
   (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
             per watcher per day.................................7
   (S06) Number of NOTIFY msgs for refreshes
             per watcher per day.................................0
   (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
             per watcher per day.................................0
   (S08) Total number and size of msgs due to SUBSCRIBE refreshes
             Number of msgs for all watchers per day.......560,000
             Bytes for all watchers per day............229,600,000
   (S09) Total number & bytes of steady messages per day
             Number of msgs for all watchers............35,760,000
             Bytes for all watchers.................32,120,800,000

   ** Termination Messages
   (T01) Terminating SUBSCRIBE msgs per watcher..................1
   (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1
   (T03) Terminating NOTIFY msgs per watcher.....................0



Houri, et al.            Expires April 25, 2009                [Page 25]


Internet-Draft          Presence Scaling Analysis           October 2008


   (T04) Terminating 200 OK msgs (NOTIFY) per watcher............0
   (T05) Total number & bytes of Terminating SUBSCRIBE msgs
             Number of msgs for all watchers................40,000
             Bytes for all watchers.....................18,000,000
   (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers................40,000
             Bytes for all watchers.....................14,800,000
   (T07) Total number & bytes of terminating NOTIFY msgs
             Number of msgs for all watchers.....................0
             Bytes for all watchers..............................0
   (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
             Number of msgs for all watchers.....................0
             Bytes for all watchers..............................0
   (T09) Total number & bytes of terminating messages per day
             Number of msgs for all watchers................80,000
             Bytes for all watchers.....................32,800,000

   ** Bottom Line
   (B01) Total of messages between domains..............36,000,000
         Total of bytes between domains (PD=350)....32,755,920,000
         Total of bytes between domains (PD=3000)...81,515,920,000
   (B02) Total number of messages / second...................1,250
         Total of bytes per second (PD=350)..............1,137,358
         Total of bytes per second (PD=3000).............2,830,414
   (B03) Total number of by msgs per user/day..................900
         Total number of bytes per user/day (PD=350).......818,898
         Total number of bytes per user/day (PD=3000)....2,037,898

       Figure 6: Widely distributed inter-domain with optimizations

2.8.2.  Associated inter-domain presence

   In this type of environment, the domain is a collection of associated
   users such as an enterprise.  Here, federation is once again very
   common.  However, there is also a strong association between some
   users in the deployment.  These associations make it somewhat more
   likely that users in that domain will be watchers of the same
   presentity.  This can occur because of business relationships (e.g.
   two co-workers on a project federating with a partner company).

   Common characteristics of this deployment are:

   o  Federated subscriptions are large minority or small majority of
      subscription traffic
   o  Individual users are likely to subscribe to multiple users in any
      one domain, especially their own





Houri, et al.            Expires April 25, 2009                [Page 26]


Internet-Draft          Presence Scaling Analysis           October 2008


   o  The intersection of users in the deployment watching the same
      presentities increases

   This federation type has traffic rates similar to the previous
   examples but with different levels of association of the users.

2.8.3.  Very large network peering

   In this environment, two or more very large networks create a peering
   relationship allowing their users to subscribe to presence in the
   other domains.  Where as the number of users in other deployment
   types ranges from hundreds to several hundred thousand, these large
   networks host up to hundreds of millions of users.  Examples of these
   networks are large wireless carriers and consumer IM networks.

   Common characteristics of this deployment are:

   o  As users become accustomed to network boundaries disappearing,
      federated subscriptions become as common as subscriptions within
      the same domain
   o  Individual users are highly likely to want to see presence of
      multiple presentities in the peer network
   o  The intersection of users in the deployment watching the same
      presentities is very high (i.e., two or more users in network A
      are extremely likely to be watching a same user in network B)
   o  Status changes increase greatly due to typical observed consumer
      behavior

   The first table below provides the calculations without optimizations
   the second table provides the calculations with optimizations.  Even
   though the optimizations help a lot (almost cut the number of
   messages by half), the numbers are still very high.  Note also that
   the bandwidth required is very high.

   ** Constants
   (C01) Subscription lifetime (hours)...........................8
   (C02) Presence state changes / hour...........................6
   (C03) Subscription refresh interval / hour....................1
   (C04) Total federated presentities per watcher...............10
   (C05) Number of dialogs to maintain per watcher..............10
   (C06) Total number of watchers in domains............20,000,000
   (C07) SUBSCRIBE message size in bytes.......................450
   (C08) 200 OK for SUBSCRIBE message size in bytes............370
   (C09) NOTIFY message size not including presence doc........500
   (C10) 200 OK for NOTIFY message size in bytes...............370
   (C11) Size of an average presence document..................350

   ** Initial Messages



Houri, et al.            Expires April 25, 2009                [Page 27]


Internet-Draft          Presence Scaling Analysis           October 2008


   (I01) Initial SUBSCRIBE msgs per watcher.....................10
   (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher............10
   (I03) Initial NOTIFY msgs per watcher........................10
   (I04) Initial 200 OK msgs (NOTIFY) per watcher...............10
   (I05) Total number & bytes of initial SUBSCRIBE msgs
             Number of msgs for all watchers...........200,000,000
             Bytes for all watchers.................90,000,000,000
   (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers...........200,000,000
             Bytes for all watchers.................74,000,000,000
   (I07) Total number & bytes of initial NOTIFY msgs
             Number of msgs for all watchers...........200,000,000
             Bytes for all watchers................170,000,000,000
   (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
             Number of msgs for all watchers...........200,000,000
             Bytes for all watchers.................74,000,000,000
   (I09) Total number & bytes of initial messages per day
             Number of msgs for all watchers...........800,000,000
             Bytes for all watchers................408,000,000,000

   ** Steady State Messages
   (S01) NOTIFY msgs due to state change
             per watched presentity per day.....................46
   (S02) 200 (for NOTIFY due to state change) msgs
             per watched presentity per day.....................46
   (S03) Total number and size of msgs due to state change per day
             Number of msgs for all watchers........18,400,000,000
             Bytes for all watchers.............11,224,000,000,000
   (S04) Number of SUBSCRIBE msgs for refreshes
             per watcher per day................................70
   (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
             per watcher per day................................70
   (S06) Number of NOTIFY msgs for refreshes
             per watcher per day................................70
   (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
             per watcher per day................................70
   (S08) Total number and size of msgs due to SUBSCRIBE refreshes
             Number of msgs for all watchers per day.5,600,000,000
             Bytes for all watchers per day......2,856,000,000,000
   (S09) Total number & bytes of steady messages per day
             Number of msgs for all watchers........24,000,000,000
             Bytes for all watchers.............14,080,000,000,000

   ** Termination Messages
   (T01) Terminating SUBSCRIBE msgs per watcher.................10
   (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........10
   (T03) Terminating NOTIFY msgs per watcher....................10
   (T04) Terminating 200 OK msgs (NOTIFY) per watcher...........10



Houri, et al.            Expires April 25, 2009                [Page 28]


Internet-Draft          Presence Scaling Analysis           October 2008


   (T05) Total number & bytes of Terminating SUBSCRIBE msgs
             Number of msgs for all watchers...........200,000,000
             Bytes for all watchers.................90,000,000,000
   (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers...........200,000,000
             Bytes for all watchers.................74,000,000,000
   (T07) Total number & bytes of terminating NOTIFY msgs
             Number of msgs for all watchers...........200,000,000
             Bytes for all watchers................170,000,000,000
   (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
             Number of msgs for all watchers...........200,000,000
             Bytes for all watchers.................74,000,000,000
   (T09) Total number & bytes of terminating messages per day
             Number of msgs for all watchers...........800,000,000
             Bytes for all watchers................408,000,000,000

   ** Bottom Line
   (B01) Total of messages between domains..........25,600,000,000
         Total of bytes bet. domains (PD=350)...14,896,000,000,000
         Total of bytes bet. domains (PD=3000)..44,046,000,000,000
   (B02) Total number of messages / second.................888,889
         Total of bytes per second (PD=350)............517,222,222
         Total of bytes per second (PD=3000).........1,529,375,000
   (B03) Total number of by msgs per user/day................1,280
         Total number of bytes per user/day (PD=350).......744,800
         Total number of bytes per user/day (PD=3000)....2,202,300

        Figure 7: Very large network peering with no optimizations


   ** Constants
   (C01) Subscription lifetime (hours)...........................8
   (C02) Presence state changes / hour...........................6
   (C03) Subscription refresh interval / hour....................1
   (C04) Total federated presentities per watcher...............10
   (C05) Number of dialogs to maintain per watcher...............1
   (C06) Total number of watchers in domains............20,000,000
   (C07) SUBSCRIBE message size in bytes.......................450
   (C08) 200 OK for SUBSCRIBE message size in bytes............370
   (C09) NOTIFY message size not including presence doc........500
   (C10) 200 OK for NOTIFY message size in bytes...............370
   (C11) Size of an average presence document..................350
   (C13) Additional data per document in RLMI..................160
   (C14) Multiparty boundary in RLMI document..................144
   (C15) XML root node in RLMI document........................144

   ** Initial Messages
   (I01) Initial SUBSCRIBE msgs per watcher......................1



Houri, et al.            Expires April 25, 2009                [Page 29]


Internet-Draft          Presence Scaling Analysis           October 2008


   (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1
   (I03) Initial NOTIFY msgs per watcher.........................1
   (I04) Initial 200 OK msgs (NOTIFY) per watcher................1
   (I05) Total number & bytes of initial SUBSCRIBE msgs
             Number of msgs for all watchers............20,000,000
             Bytes for all watchers..................9,000,000,000
   (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers............20,000,000
             Bytes for all watchers..................7,400,000,000
   (I07) Total number & bytes of initial NOTIFY msgs
             Number of msgs for all watchers............20,000,000
             Bytes for all watchers................146,560,000,000
   (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
             Number of msgs for all watchers............20,000,000
             Bytes for all watchers..................7,400,000,000
   (I09) Total number & bytes of initial messages per day
             Number of msgs for all watchers............80,000,000
             Bytes for all watchers................170,360,000,000

   ** Steady State Messages
   (S01) NOTIFY msgs due to state change
             per watched presentity per day.....................46
   (S02) 200 (for NOTIFY due to state change) msgs
             per watched presentity per day.....................46
   (S03) Total number and size of msgs due to state change per day
             Number of msgs for all watchers........18,400,000,000
             Bytes for all watchers.............16,670,400,000,000
   (S04) Number of SUBSCRIBE msgs for refreshes
             per watcher per day.................................7
   (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
             per watcher per day.................................7
   (S06) Number of NOTIFY msgs for refreshes
             per watcher per day.................................0
   (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
             per watcher per day.................................0
   (S08) Total number and size of msgs due to SUBSCRIBE refreshes
             Number of msgs for all watchers per day...280,000,000
             Bytes for all watchers per day........114,800,000,000
   (S09) Total number & bytes of steady messages per day
             Number of msgs for all watchers........18,680,000,000
             Bytes for all watchers.............16,785,200,000,000

   ** Termination Messages
   (T01) Terminating SUBSCRIBE msgs per watcher..................1
   (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1
   (T03) Terminating NOTIFY msgs per watcher.....................0
   (T04) Terminating 200 OK msgs (NOTIFY) per watcher............0
   (T05) Total number & bytes of Terminating SUBSCRIBE msgs



Houri, et al.            Expires April 25, 2009                [Page 30]


Internet-Draft          Presence Scaling Analysis           October 2008


             Number of msgs for all watchers............20,000,000
             Bytes for all watchers..................9,000,000,000
   (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers............20,000,000
             Bytes for all watchers..................7,400,000,000
   (T07) Total number & bytes of terminating NOTIFY msgs
             Number of msgs for all watchers.....................0
             Bytes for all watchers..............................0
   (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
             Number of msgs for all watchers.....................0
             Bytes for all watchers..............................0
   (T09) Total number & bytes of terminating messages per day
             Number of msgs for all watchers............40,000,000
             Bytes for all watchers.................16,400,000,000

   ** Bottom Line
   (B01) Total of messages between domains..........18,800,000,000
         Total of bytes bet. domains (PD=350)...16,971,960,000,000
         Total of bytes bet. domains (PD=3000)..41,881,960,000,000
   (B02) Total number of messages / second.................652,778
         Total of bytes per second (PD=350)............589,304,167
         Total of bytes per second (PD=3000).........1,454,234,722
   (B03) Total number of by msgs per user/day..................940
         Total number of bytes per user/day (PD=350).......848,598
         Total number of bytes per user/day (PD=3000)....2,094,098


          Figure 8: Very large network peering with optimizations

2.8.4.  Intra-domain peering

   Within a particular domain, multiple presence infrastructures are
   deployed with users split between the two.  This scenario is unique
   in that federated messages do not pass outside the administrative
   domain's network.  The two infrastructures peer directly inside the
   domain.  A common example of this is an enterprise IT system with
   multiple independent vendor presence solutions deployed (e.g., a
   presence solution for desktop messaging deployed alongside a presence
   solution for IP telephony).

   Common characteristics of this deployment are

   o  The difference between subscriptions to presentities in one system
      vs. the other are completely arbitrary.  Any one presentity is as
      likely to be homed on one infrastructure as the other.
   o  Active users are almost guaranteed of subscribing to many users in
      the peer infrastructure.




Houri, et al.            Expires April 25, 2009                [Page 31]


Internet-Draft          Presence Scaling Analysis           October 2008


   o  The level of intersection of presentities is extremely high.

   The first table below provides the calculations without optimizations
   the second table provides the calculations with optimization.  Even
   though the relatively conservative numbers are used, the amount of
   messages is still very high even though optimization may cut the
   traffic by more then half

   ** Constants
   (C01) Subscription lifetime (hours)...........................8
   (C02) Presence state changes / hour...........................3
   (C03) Subscription refresh interval / hour....................1
   (C04) Total federated presentities per watcher...............10
   (C05) Number of dialogs to maintain per watcher..............10
   (C06) Total number of watchers in domains...............120,000
   (C07) SUBSCRIBE message size in bytes.......................450
   (C08) 200 OK for SUBSCRIBE message size in bytes............370
   (C09) NOTIFY message size not including presence doc........500
   (C10) 200 OK for NOTIFY message size in bytes...............370
   (C11) Size of an average presence document..................350

   ** Initial Messages
   (I01) Initial SUBSCRIBE msgs per watcher.....................10
   (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher............10
   (I03) Initial NOTIFY msgs per watcher........................10
   (I04) Initial 200 OK msgs (NOTIFY) per watcher...............10
   (I05) Total number & bytes of initial SUBSCRIBE msgs
             Number of msgs for all watchers.............1,200,000
             Bytes for all watchers....................540,000,000
   (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers.............1,200,000
             Bytes for all watchers....................444,000,000
   (I07) Total number & bytes of initial NOTIFY msgs
             Number of msgs for all watchers.............1,200,000
             Bytes for all watchers..................1,020,000,000
   (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
             Number of msgs for all watchers.............1,200,000
             Bytes for all watchers....................444,000,000
   (I09) Total number & bytes of initial messages per day
             Number of msgs for all watchers.............4,800,000
             Bytes for all watchers..................2,448,000,000

   ** Steady State Messages
   (S01) NOTIFY msgs due to state change
             per watched presentity per day.....................22
   (S02) 200 (for NOTIFY due to state change) msgs
             per watched presentity per day.....................22
   (S03) Total number and size of msgs due to state change per day



Houri, et al.            Expires April 25, 2009                [Page 32]


Internet-Draft          Presence Scaling Analysis           October 2008


             Number of msgs for all watchers............52,800,000
             Bytes for all watchers.................32,208,000,000
   (S04) Number of SUBSCRIBE msgs for refreshes
             per watcher per day................................70
   (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
             per watcher per day................................70
   (S06) Number of NOTIFY msgs for refreshes
             per watcher per day................................70
   (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
             per watcher per day................................70
   (S08) Total number and size of msgs due to SUBSCRIBE refreshes
             Number of msgs for all watchers per day....33,600,000
             Bytes for all watchers per day.........17,136,000,000
   (S09) Total number & bytes of steady messages per day
             Number of msgs for all watchers............86,400,000
             Bytes for all watchers.................49,344,000,000

   ** Termination Messages
   (T01) Terminating SUBSCRIBE msgs per watcher.................10
   (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........10
   (T03) Terminating NOTIFY msgs per watcher....................10
   (T04) Terminating 200 OK msgs (NOTIFY) per watcher...........10
   (T05) Total number & bytes of Terminating SUBSCRIBE msgs
             Number of msgs for all watchers.............1,200,000
             Bytes for all watchers....................540,000,000
   (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers.............1,200,000
             Bytes for all watchers....................444,000,000
   (T07) Total number & bytes of terminating NOTIFY msgs
             Number of msgs for all watchers.............1,200,000
             Bytes for all watchers..................1,020,000,000
   (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
             Number of msgs for all watchers.............1,200,000
             Bytes for all watchers....................444,000,000
   (T09) Total number & bytes of terminating messages per day
             Number of msgs for all watchers.............4,800,000
             Bytes for all watchers..................2,448,000,000

   ** Bottom Line
   (B01) Total of messages between domains..............96,000,000
         Total of bytes between domains (PD=350)....54,240,000,000
         Total of bytes between domains (PD=3000)..152,820,000,000
   (B02) Total number of messages / second...................3,333
         Total of bytes per second (PD=350)..............1,883,333
         Total of bytes per second (PD=3000).............5,306,250
   B(03 )Total number of by msgs per user/day..................800
         Total number of bytes per user/day (PD=350).......452,000
         Total number of bytes per user/day (PD=3000)....1,273,500



Houri, et al.            Expires April 25, 2009                [Page 33]


Internet-Draft          Presence Scaling Analysis           October 2008


           Figure 9: Intra-domain peering with no optimizations


   ** Constants
   (C01) Subscription lifetime (hours)...........................8
   (C02) Presence state changes / hour...........................3
   (C03) Subscription refresh interval / hour....................1
   (C04) Total federated presentities per watcher...............10
   (C05) Number of dialogs to maintain per watcher...............1
   (C06) Total number of watchers in domains...............120,000
   (C07) SUBSCRIBE message size in bytes.......................450
   (C08) 200 OK for SUBSCRIBE message size in bytes............370
   (C09) NOTIFY message size not including presence doc........500
   (C10) 200 OK for NOTIFY message size in bytes...............370
   (C11) Size of an average presence document..................350
   (C13) Additional data per document in RLMI..................160
   (C14) Multiparty boundary in RLMI document..................144
   (C15) XML root node in RLMI document........................144

   ** Initial Messages
   (I01) Initial SUBSCRIBE msgs per watcher......................1
   (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1
   (I03) Initial NOTIFY msgs per watcher.........................1
   (I04) Initial 200 OK msgs (NOTIFY) per watcher................1
   (I05) Total number & bytes of initial SUBSCRIBE msgs
             Number of msgs for all watchers...............120,000
             Bytes for all watchers.....................54,000,000
   (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers...............120,000
             Bytes for all watchers.....................44,400,000
   (I07) Total number & bytes of initial NOTIFY msgs
             Number of msgs for all watchers...............120,000
             Bytes for all watchers....................879,360,000
   (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
             Number of msgs for all watchers...............120,000
             Bytes for all watchers.....................44,400,000
   (I09) Total number & bytes of initial messages per day
             Number of msgs for all watchers...............480,000
             Bytes for all watchers..................1,022,160,000

   ** Steady State Messages
   (S01) NOTIFY msgs due to state change
             per watched presentity per day.....................22
   (S02) 200 (for NOTIFY due to state change) msgs
             per watched presentity per day.....................22
   (S03) Total number and size of msgs due to state change per day
             Number of msgs for all watchers............52,800,000
             Bytes for all watchers.................47,836,800,000



Houri, et al.            Expires April 25, 2009                [Page 34]


Internet-Draft          Presence Scaling Analysis           October 2008


   (S04) Number of SUBSCRIBE msgs for refreshes
             per watcher per day.................................7
   (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
             per watcher per day.................................7
   (S06) Number of NOTIFY msgs for refreshes
             per watcher per day.................................0
   (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
             per watcher per day.................................0
   (S08) Total number and size of msgs due to SUBSCRIBE refreshes
             Number of msgs for all watchers per day.....1,680,000
             Bytes for all watchers per day............688,800,000
   (S09) Total number & bytes of steady messages per day
             Number of msgs for all watchers............54,480,000
             Bytes for all watchers.................48,525,600,000

   ** Termination Messages
   (T01) Terminating SUBSCRIBE msgs per watcher..................1
   (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1
   (T03) Terminating NOTIFY msgs per watcher.....................1
   (T04) Terminating 200 OK msgs (NOTIFY) per watcher............1
   (T05) Total number & bytes of Terminating SUBSCRIBE msgs
             Number of msgs for all watchers...............120,000
             Bytes for all watchers.....................54,000,000
   (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers...............120,000
             Bytes for all watchers.....................44,400,000
   (T07) Total number & bytes of terminating NOTIFY msgs
             Number of msgs for all watchers.....................0
             Bytes for all watchers..............................0
   (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
             Number of msgs for all watchers...............120,000
             Bytes for all watchers.....................44,400,000
   (T09) Total number & bytes of terminating messages per day
             Number of msgs for all watchers...............240,000
             Bytes for all watchers.....................98.400,000

   ** Bottom Line
   (B01) Total of messages between domains..............55,200,000
         Total of bytes between domains (PD=350)....49,646,160,000
         Total of bytes between domains (PD=3000)..122,796,160,000
   (B02) Total number of messages / second...................1,917
         Total of bytes per second (PD=350)..............1,723,825
         Total of bytes per second (PD=3000).............4,263,408
   (B03) Total number of by msgs per user/day..................460
         Total number of bytes per user/day (PD=350).......413,718
         Total number of bytes per user/day (PD=3000)....1,023,218

            Figure 10: Intra-domain peering with optimizations



Houri, et al.            Expires April 25, 2009                [Page 35]


Internet-Draft          Presence Scaling Analysis           October 2008


2.9.  Partial Notifications Optimization

   Draft [12] define a way for the watcher to request getting only what
   was changed in the presence document.  The following is a calculation
   of the bandwidth that is saved in the very large peering network
   case, when we add the partial notification optimization to the dialog
   and NOTIFY optimization.  It is assumed that except for the initial
   NOTIFY all the other NOTIFY messages will be partial.  It is also
   assumed that only a single attribute in the presence document will be
   changed each time, thus the size of the partial presence document is
   assumed to be 200 bytes.

   ** Constants
   (C01) Subscription lifetime (hours)...........................8
   (C02) Presence state changes / hour...........................6
   (C03) Subscription refresh interval / hour....................1
   (C04) Total federated presentities per watcher...............10
   (C05) Number of dialogs to maintain per watcher..............10
   (C06) Total number of watchers in domains............20,000,000
   (C07) SUBSCRIBE message size in bytes.......................450
   (C08) 200 OK for SUBSCRIBE message size in bytes............370
   (C09) NOTIFY message size not including presence doc........500
   (C10) 200 OK for NOTIFY message size in bytes...............370
   (C11) Size of an average presence document..................350
   (C12) Size of an average partial presence document..........200

   ** Initial Messages
   (I01) Initial SUBSCRIBE msgs per watcher.....................10
   (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher............10
   (I03) Initial NOTIFY msgs per watcher........................10
   (I04) Initial 200 OK msgs (NOTIFY) per watcher...............10
   (I05) Total number & bytes of initial SUBSCRIBE msgs
             Number of msgs for all watchers...........200,000,000
             Bytes for all watchers.................90,000,000,000
   (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers...........200,000,000
             Bytes for all watchers..................74,00,000,000
   (I07) Total number & bytes of initial NOTIFY msgs
             Number of msgs for all watchers...........200,000,000
             Bytes for all watchers................170,000,000,000
   (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
             Number of msgs for all watchers...........200,000,000
             Bytes for all watchers..................74,000,000,000
   (I09) Total number & bytes of initial messages per day
             Number of msgs for all watchers...........800,000,000
             Bytes for all watchers................408,000,000,000

   ** Steady State Messages



Houri, et al.            Expires April 25, 2009                [Page 36]


Internet-Draft          Presence Scaling Analysis           October 2008


   (S01) NOTIFY msgs due to state change
             per watched presentity per day.....................46
   (S02) 200 (for NOTIFY due to state change) msgs
             per watched presentity per day.....................46
   (S03) Total number and size of msgs due to state change per day
             Number of msgs for all watchers........18,400,000,000
             Bytes for all watchers..............9,844,000,000,000
   (S04) Number of SUBSCRIBE msgs for refreshes
             per watcher per day................................70
   (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
             per watcher per day................................70
   (S06) Number of NOTIFY msgs for refreshes
             per watcher per day.................................0
   (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
             per watcher per day.................................0
   (S08) Total number and size of msgs due to SUBSCRIBE refreshes
             Number of msgs for all watchers per day.2,800,000,000
             Bytes for all watchers per day......1,148,000,000,000
   (S09) Total number & bytes of steady messages per day
             Number of msgs for all watchers........21,200,000,000
             Bytes for all watchers.............10,992,000,000,000

   ** Termination Messages
   (T01) Terminating SUBSCRIBE msgs per watcher.................10
   (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........10
   (T03) Terminating NOTIFY msgs per watcher.....................0
   (T04) Terminating 200 OK msgs (NOTIFY) per watcher............0
   (T05) Total number & bytes of Terminating SUBSCRIBE msgs
             Number of msgs for all watchers...........200,000,000
             Bytes for all watchers.................90,000,000,000
   (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers...........200,000,000
             Bytes for all watchers.................74,000,000,000
   (T07) Total number & bytes of terminating NOTIFY msgs
             Number of msgs for all watchers.....................0
             Bytes for all watchers..............................0
   (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
             Number of msgs for all watchers.....................0
             Bytes for all watchers..............................0
   (T09) Total number & bytes of terminating messages per day
             Number of msgs for all watchers...........400,000,000
             Bytes for all watchers................164.000,000,000

   ** Bottom Line
   (B01) Total of messages between domains..........22,400,000,000
         Total of bytes bet. domains (PD=350)...11,564,000,000,000
         Total of bytes bet. domains (PD=3000)..12,094,000,000,000
   (B02) Total number of messages / second.................777,778



Houri, et al.            Expires April 25, 2009                [Page 37]


Internet-Draft          Presence Scaling Analysis           October 2008


         Total of bytes per second (PD=350)............401,527,778
         Total of bytes per second (PD=3000)...........419,930,556
   (B03) Total number of by msgs per user/day................1,120
         Total number of bytes per user/day (PD=350).......578,200
         Total number of bytes per user/day (PD=3000)......604,700

      Figure 11: Very large networks peering with NOTIFY and partial
                               optimizations

2.10.  Very Optimized SIP

   SIP is network agnostic protocol, therefore, the protocol carries
   additional messages like 200 OK that would have been redundant in a
   protocol that is TCP based only.

   The following calculation assumes an imaginary TCP only based version
   of SIP that optimizes the following:

   o  There is no 200 OK for each message.  Since only TCP has to be
      supported, there is not need to compensate for network issues.
   o  There is no refresh for subscriptions.
   o  There is no NOTIFY upon termination of SUBSCRIPTION
   o  The size of each message is smaller since there is no need for the
      various headers that SIP uses for routing etc.  So we need to
      assume smaller message sizes while we will keep the size of the
      presence document the same.

   As notes above the calculations in this document do not assume
   offline means of getting parts of the presence information.
   Therefore, in addition to the above optimizations, the other
   optimizations that were assumed in the document will be assumed here
   also.  These includes partial notifications and the dialog
   optimizations.  The NOTIFY optimization is not relevant here since
   there are no refreshes of subscriptions.

   The following is a calculation for the very large networks peering
   scenario assuming the imaginary TCP only SIP.  It is very interesting
   to note that the dialog optimization does not reduce the number of
   bytes when partial notification optimization is applied (on the
   contrary) due to the RLMI overhead.

           ** Constants
   (C01) Subscription lifetime (hours)...........................8
   (C02) Presence state changes / hour...........................6
   (C03) Subscription refresh interval / hour....................0
   (C04) Total federated presentities per watcher...............10
   (C05) Number of dialogs to maintain per watcher...............1
   (C06) Total number of watchers in domains............20,000,000



Houri, et al.            Expires April 25, 2009                [Page 38]


Internet-Draft          Presence Scaling Analysis           October 2008


   (C07) SUBSCRIBE message size in bytes.......................150
   (C08) 200 OK for SUBSCRIBE message size in bytes..............0
   (C09) NOTIFY message size not including presence doc........150
   (C10) 200 OK for NOTIFY message size in bytes.................0
   (C11) Size of an average presence document..................350
   (C12) Size of an average partial presence document..........200

   ** Initial Messages
   (I01) Initial SUBSCRIBE msgs per watcher......................1
   (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............0
   (I03) Initial NOTIFY msgs per watcher.........................1
   (I04) Initial 200 OK msgs (NOTIFY) per watcher................0
   (I05) Total number & bytes of initial SUBSCRIBE msgs
             Number of msgs for all watchers............20,000,000
             Bytes for all watchers..................3,000,000,000
   (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers.....................0
             Bytes for all watchers..............................0
   (I07) Total number & bytes of initial NOTIFY msgs
             Number of msgs for all watchers............20,000,000
             Bytes for all watchers................136,680,000,000
   (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
             Number of msgs for all watchers.....................0
             Bytes for all watchers..............................0
   (I09) Total number & bytes of initial messages per day
             Number of msgs for all watchers............40,000,000
             Bytes for all watchers................139,680,000,000

   ** Steady State Messages
   (S01) NOTIFY msgs due to state change
             per watched presentity per day.....................46
   (S02) 200 (for NOTIFY due to state change) msgs
             per watched presentity per day......................0
   (S03) Total number and size of msgs due to state change per day
             Number of msgs for all watchers.........9,200,000,000
             Bytes for all watchers..............8,666,400,000,000
   (S04) Number of SUBSCRIBE msgs for refreshes
             per watcher per day.................................0
   (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
             per watcher per day.................................0
   (S06) Number of NOTIFY msgs for refreshes
             per watcher per day.................................0
   (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
             per watcher per day.................................0
   (S08) Total number and size of msgs due to SUBSCRIBE refreshes
             Number of msgs for all watchers per day.............0
             Bytes for all watchers per day......................0
   (S09) Total number & bytes of steady messages per day



Houri, et al.            Expires April 25, 2009                [Page 39]


Internet-Draft          Presence Scaling Analysis           October 2008


             Number of msgs for all watchers.........9,200,000,000
             Bytes for all watchers..............8,666,400,000,000

   ** Termination Messages
   (T01) Terminating SUBSCRIBE msgs per watcher..................1
   (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........0
   (T03) Terminating NOTIFY msgs per watcher.....................0
   (T04) Terminating 200 OK msgs (NOTIFY) per watcher............0
   (T05) Total number & bytes of Terminating SUBSCRIBE msgs
             Number of msgs for all watchers............20,000,000
             Bytes for all watchers..................3,000,000,000
   (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers.....................0
             Bytes for all watchers..............................0
   (T07) Total number & bytes of terminating NOTIFY msgs
             Number of msgs for all watchers.....................0
             Bytes for all watchers..............................0
   (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
             Number of msgs for all watchers.....................0
             Bytes for all watchers..............................0
   (T09) Total number & bytes of terminating messages per day
             Number of msgs for all watchers............20,000,000
             Bytes for all watchers..................3,000,000,000

   ** Bottom Line
   (B01) Total of messages between domains...........9,260,000,000
         Total of bytes between domains (PD=350).8,809,080,000,000
         Total of bytes bet. domains (PD=3000)...9,339,080,000,000
   (B02) Total number of messages / second.................321,528
         Total of bytes per second (PD=350)............305,870,833
         Total of bytes per second (PD=3000)...........324,273,611
   (B03) Total number of by msgs per user/day..................463
         Total number of bytes per user/day (PD=350).......440,454
         Total number of bytes per user/day (PD=3000)......466,954

    Figure 12: Very large networks peering, TCP only SIP+Partial+Dialog
                               optimizations


   ** Constants
   (C01) Subscription lifetime (hours)...........................8
   (C02) Presence state changes / hour...........................6
   (C03) Subscription refresh interval / hour....................0
   (C04) Total federated presentities per watcher...............10
   (C05) Number of dialogs to maintain per watcher..............10
   (C06) Total number of watchers in domains............20,000,000
   (C07) SUBSCRIBE message size in bytes.......................150
   (C08) 200 OK for SUBSCRIBE message size in bytes..............0



Houri, et al.            Expires April 25, 2009                [Page 40]


Internet-Draft          Presence Scaling Analysis           October 2008


   (C09) NOTIFY message size not including presence doc........150
   (C10) 200 OK for NOTIFY message size in bytes.................0
   (C11) Size of an average presence document..................350
   (C12) Size of an average partial presence document..........200

   ** Initial Messages
   (I01) Initial SUBSCRIBE msgs per watcher.....................10
   (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............0
   (I03) Initial NOTIFY msgs per watcher........................10
   (I04) Initial 200 OK msgs (NOTIFY) per watcher................0
   (I05) Total number & bytes of initial SUBSCRIBE msgs
             Number of msgs for all watchers...........200,000,000
             Bytes for all watchers.................30,000,000,000
   (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers.....................0
             Bytes for all watchers..............................0
   (I07) Total number & bytes of initial NOTIFY msgs
             Number of msgs for all watchers...........200,000,000
             Bytes for all watchers................100,000,000,000
   (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
             Number of msgs for all watchers.....................0
             Bytes for all watchers..............................0
   (I09) Total number & bytes of initial messages per day
             Number of msgs for all watchers...........400,000,000
             Bytes for all watchers................130,000,000,000

   ** Steady State Messages
   (S01) NOTIFY msgs due to state change
             per watched presentity per day.....................46
   (S02) 200 (for NOTIFY due to state change) msgs
             per watched presentity per day......................0
   (S03) Total number and size of msgs due to state change per day
             Number of msgs for all watchers.........9,200,000,000
             Bytes for all watchers..............3,220,000,000,000
   (S04) Number of SUBSCRIBE msgs for refreshes
             per watcher per day.................................0
   (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
             per watcher per day.................................0
   (S06) Number of NOTIFY msgs for refreshes
             per watcher per day.................................0
   (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
             per watcher per day.................................0
   (S08) Total number and size of msgs due to SUBSCRIBE refreshes
             Number of msgs for all watchers per day.............0
             Bytes for all watchers per day......................0
   (S09) Total number & bytes of steady messages per day
             Number of msgs for all watchers.........9,200,000,000
             Bytes for all watchers..............3,220,000,000,000



Houri, et al.            Expires April 25, 2009                [Page 41]


Internet-Draft          Presence Scaling Analysis           October 2008


   ** Termination Messages
   (T01) Terminating SUBSCRIBE msgs per watcher.................10
   (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........0
   (T03) Terminating NOTIFY msgs per watcher.....................0
   (T04) Terminating 200 OK msgs (NOTIFY) per watcher............0
   (T05) Total number & bytes of Terminating SUBSCRIBE msgs
             Number of msgs for all watchers...........200,000,000
             Bytes for all watchers.................30,000,000,000
   (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers.....................0
             Bytes for all watchers..............................0
   (T07) Total number & bytes of terminating NOTIFY msgs
             Number of msgs for all watchers.....................0
             Bytes for all watchers..............................0
   (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
             Number of msgs for all watchers.....................0
             Bytes for all watchers..............................0
   (T09) Total number & bytes of terminating messages per day
             Number of msgs for all watchers...........200,000,000
             Bytes for all watchers.................30,000,000,000

   ** Bottom Line
   (B01) Total of messages between domains...........9,800,000,000
         Total of bytes between domains (PD=350).3,380,000,000,000
         Total of bytes bet. domains (PD=3000)...3,910,280,000,000
   (B02) Total number of messages / second.................340,278
         Total of bytes per second (PD=350)............117,361,111
         Total of bytes per second (PD=3000)...........135,763,889
   (B03) Total number of by msgs per user/day..................490
         Total number of bytes per user/day (PD=350).......169,000
         Total number of bytes per user/day (PD=3000)......195,500


       Figure 13: Very large networks peering, TCP only SIP+Partial
                               optimizations


3.  State Management

   In previous sections we have discussed the big amount of messages
   that need to be sent to/from a presence server In this section the
   state that needs to be maintained by a presence server will be
   analyzed and shown to be far from trivial.

   The presence server has two parallel tasks.






Houri, et al.            Expires April 25, 2009                [Page 42]


Internet-Draft          Presence Scaling Analysis           October 2008


   1.  Maintain the state of the presentities to which watchers
       subscribe.
   2.  Maintain the state of the subscriptions of watchers and provide
       timely updates to the watchers.

   For a single subscription from a single watcher on a presentity, the
   presence server has to maintain the following state:

   o  Subscription state including all the parameters that are needed in
      order to maintain the subscription as timers.
   o  Optional filtering information that was requested by the watcher.
      This includes enough information that is needed for doing the
      filtering.  In addition additional information has to be
      maintained if partial notification is being supported for the
      subscription
   o  Optional rate management information as throttling
   o  Watcher information [2], [3] that is the result of the
      subscription in order to enable watched presentities to see who is
      watching them.

   For each presentity that has been subscribed to in the presence
   server, the presence server has to maintain the following state:

   o  A list of the subscriptions for the presentity.  Note that this is
      already taken care of from the size calculation point of view by
      the subscription state above.
   o  Authorization information for the presentity.

   For each presentity for which there was any publication and the
   presentity has a state other then a default value, the presence
   server has to maintain the current value of the presentity.

3.1.  State Size Calculations

   Lets assume the following sizes:

   o  Subscription size - 2K bytes.  This includes watcher information
      that need to be created by the presence server for each
      subscription.  This is for each subscription that is done by each
      watcher to each presentity that the watcher is watching.  So if we
      have 10K watchers we should have 10K of these.
   o  Subscribed to resource - 1K bytes (for privacy information and
      other management info).  This is for each presentity that is being
      watched.  No matter how many watchers are watching it.  The
      subscriptions themselves are already calculated in the previous
      bullet.





Houri, et al.            Expires April 25, 2009                [Page 43]


Internet-Draft          Presence Scaling Analysis           October 2008


   o  Resource with a state - 6K bytes.  This is a moderate assumption
      if we take into account the amount of data that is being put in a
      presence document as multiple devices, calendar and geographical
      information.  This is for each presentity that has state other
      then the default empty state.  It does not matter if it is being
      watched or not.

3.1.1.  Tiny System

   o  10K subscriptions = 19M bytes.
   o  5K subscribed to presentities = 5M bytes.
   o  10K presentities with state = 58M bytes.

   Total is 82M bytes.

3.1.2.  Medium System

   o  100K subscriptions = 195M bytes.
   o  50K subscribed to presentities = 49M bytes.
   o  100K presentities with state = 586M bytes.

   Total is 830M bytes.

3.1.3.  Large System

   o  6M subscriptions = 11,718M bytes.
   o  3M subscribed to presentities = 2,929M bytes.
   o  4M presentities with state = 23437M bytes.

   Total is 38G bytes.

3.1.4.  Very Large System

   o  150M subscriptions = 292,969M bytes.
   o  75M subscribed to presentities = 73,242M bytes.
   o  100M presentities with state = 585,937M bytes.

   Total is 952G bytes which is a very big number for a very dynamic
   storage as needed by the presence server.

   Although the numbers above may seem moderate enough for the sizes
   that the presence server is handling we should consider the
   following:

   o  Dynamic state - Although the state may seem not so big for
      databases even for the very large system, we need to remember that
      this state is a very dynamic state.  Subscriptions come and go all
      the time, the status of presentities is being updated and so



Houri, et al.            Expires April 25, 2009                [Page 44]


Internet-Draft          Presence Scaling Analysis           October 2008


      forth.  This means that the presence server has to manage its
      state in a medium that is very dynamic and for such large sizes
      this task is not trivial.
   o  Interlinked state - The subscriptions and the subscribed to
      presentities are dependent on each other.  There needs to be a
      link from the presentity to the subscriptions and vice versa.  See
      Section 4.5 about the interlinkage that is created due to resource
      lists.
   o  Moderate assumptions - The size assumptions that were made above
      are quite moderate.  As presence is becoming more a core
      middleware functionality that holds a lot of data on the user.  In
      real-life the numbers above may be even higher and the presence
      server can have additional overhead as managing the SIP sessions,
      networking and more.

   Although the calculations above do not show that there is a real
   issue with state management of presence in medium systems or even in
   big systems since it should be possible to divide the state between
   different machines, the state size is still very big.  A bigger issue
   with the state is more when resource lists are involved and create an
   interlinked state between many servers.  In that case the division of
   very big state to multiple servers becomes less trivial...


4.  Processing complexities

   The basic presence paradigm consists from a watcher and a presentity
   to which the watcher watches.  It sounds simple enough but there are
   many additions and extensions that the presence server has to manage
   that make the processing of the presence server very complex.

   In this section we show that in addition to the large amount of
   messages and the big state that the presence server has to handle, it
   has also to handle quite intensive processing for aggregation,
   partial notify and publish, filtering and privacy.  This adds another
   complexity to the presence server in the CPU front in addition to the
   network and memory fronts that were described before.

4.1.  Aggregation

   A presence document may contain multiple resources.  These resources
   can be devices of the presentity, information that is received form
   external providers of presence information for the presentity as
   geographical and calendar information and more.

   The presence server needs to be able to get the updates from all the
   resources and aggregate them correctly into a single presence
   document.  Although this is just "XML processing" task, the amount of



Houri, et al.            Expires April 25, 2009                [Page 45]


Internet-Draft          Presence Scaling Analysis           October 2008


   updates that the presence server may get, the need to keep the
   presence document aligned with its schema and the need to notify the
   users as soon as possible create a significant processing burden on
   the presence server

4.2.  Partial Publish and Notify

   Drafts [12], [13] define a way for the watcher to request getting
   only what was changed in the presence document and for the publisher
   of presence information to publish only what was changed in the
   presence document since the last publish.  Although these
   optimizations help in reducing the amount of the data that is sent
   from/to the presence server, these optimizations create additional
   processing burden on the presence server.

   When a partial publish is arriving to the presence server, the
   presence server has to be able to process the partial publish, change
   only what is indicated in the partial publish while keeping the
   presence document in a well formed shape according to the schema.

   In partial notify the processing is even more complex since each
   watcher needs to get the partial update based on the last update that
   was received by that watcher.  Therefore [12] specifies a versioning
   mechanism that enables the watcher to get the updates based on the
   previous state that it has seen.  This versioning mechanism has to be
   maintained by the presence server for each watcher that is subscribed
   to a presentity and requires partial notify.

4.3.  Filtering

   Filtering as defined in RFCs [7], [8] enables a watcher to request to
   be notified only when the presence document fulfills certain
   conditions.  Although this is a very convenient feature for watchers,
   the burden that is put on the presence server is quite big.  For each
   change in the presence document, the presence server needs to compute
   the filtering expressions which can be very complex, decide whether
   and what to send to the watcher that have requested filtering.

4.4.  Authorization

   Draft [14] defines presence authorization rules that can be used by
   presentities to define who can see what from their presence
   documents.  The processing that the presence server has to do here is
   very similar to filtering.  When there is a change to any presence
   document that has privacy defined for it, the presence server needs
   to create different notification for different watchers according to
   what is defined in the authorization rules.




Houri, et al.            Expires April 25, 2009                [Page 46]


Internet-Draft          Presence Scaling Analysis           October 2008


4.5.  Resource List Service

   RFC [9] defines a way to subscribe on a single URI while that URI is
   actually a list of resources that are being subscribed to by a single
   subscription.  Although this is quite useful mechanism and it
   significantly saves on the number of sessions between the watcher and
   the presence server (as we show in the calculations of messages),
   this feature has the potential to make the scalability issue of
   presence systems harder and more complex.

   The reasons that resource lists may make the scalability problem of
   the presence server even more complex are:

   o  Subscriptions and state - The resource list may contain reference
      to many other presence servers in many other domains.  This
      requires the RLS to create subscriptions to other presence servers
      and buffer the state of all presentities in order to be able to
      provide the full state of the presentities in the list when
      needed.  So in the overall system, the subscriptions that were
      saved between the watcher and the presence server are moved to the
      backend system while state has been duplicated between the various
      presence servers that serve the various presentities and the RLSs.
      This issue could have been mitigated if there was a way for the
      RLS to retrieve the presence information for many watchers while
      adhering to privacy when sending the actual notifications to the
      watchers.
   o  Interlinkage - The resource list subscription will reach one RLS
      that will open it and send it to many presence servers and to
      other RLSs (if there is a subgroup inside the list).  This way a
      complex linkage between the state of many components is created.
      This linkage makes state management and other maintenance of a
      presence systems quite complex.
   o  Big lists are easy - There are two types of groups that may be
      used with this feature, private groups that are defined by/for
      each watcher and public groups that are defined in the system and
      can be used by any watcher.  Although we should expect IT
      administrators to take caution when creating public groups, this
      may be not the case in real life.  The connection between the size
      of the public group and the load on the presence server system may
      not apparent to everyone.  Furthermore many public groups that are
      used in presence systems may have been created for other purposes
      as email systems (where the size of the lists was not so
      important) and are taken as they are to presence systems.  So for
      example we may very easily find that a public group that actually
      covers all the users in the enterprise are used by many users in
      the enterprise thus creating unbearable load on the presence
      server.  Note that this issue is not a protocol or design issue
      but more a usage issue that may have a real impact on the presence



Houri, et al.            Expires April 25, 2009                [Page 47]


Internet-Draft          Presence Scaling Analysis           October 2008


      system.
   o  Stopping notifications - A watcher may accidentally subscribe to a
      very big list and be overwhelmed by the amount of notifies that it
      receives from the presence server.  There is no current way to
      stop this stream of notifies and even canceling the subscription
      may take time until being affective.

   The issues mentioned above are one example of an optimization that
   helps in one part of the system but creates even bigger problems in
   the overall system.  There is a need to think about the problems
   listed above but more then that there is a need to make sure that
   when an optimization is introduced it does not create issues in other
   places.


5.  Current Optimizations

   This section lists and discusses several optimizations that are
   either already part of the SIP protocol or they have been suggested
   in various drafts.  Several other optimizations that have been
   suggested but have not been discussed in any working group yet are
   summarized in [19] and in [21].  Note that trials with batched
   notifies optimization that is describes in [19], showed an
   improvement of 117% in the whole throughput of presence traffic.

   o  Subnot-etags - Draft [17].  This draft suggests ways to suppress
      the sending of unnecessary notifies when for example a
      subscription is refreshed.  This suggestion seems to be an
      efficient optimization since it saves both the number of messages
      sent and on the processing time of the presence server.
   o  Resource List Service - [9] enable creating a single subscription
      session between the watcher and the presence server for
      subscribing on a list of users.  This saves the amount of sessions
      that are created between watchers and presence servers.  On the
      other hand, this mechanism enables creating very large amount of
      subscriptions in the presence server/RLS system thus enabling the
      creation of a very large number of subscriptions between presence
      servers and RLSs with relatively few clients especially if large
      public groups are used.  It seems that in order to really optimize
      in this area, the usage of large public groups should not be
      considered as BCP and there should be a way for an RLS to create a
      single subscription for multiple occurrences of the same resource
      in resource lists.  See consolidates subscriptions below.
   o  Partial notify/publish - Drafts [12], [13] define a way for the
      subscriber to request getting only what was changed in the
      presence document and for the publisher of presence information to
      publish only what was changed in the presence document since the
      last publish.  Although these optimizations help in reducing the



Houri, et al.            Expires April 25, 2009                [Page 48]


Internet-Draft          Presence Scaling Analysis           October 2008


      amount of actual data that is sent from/to the presence server,
      these optimizations create additional processing burden on the
      presence server as was discussed above.
   o  Filtering as defined in RFCs [7], [8] enables a watcher to request
      to be notified only when the presence document fulfills certain
      conditions.  Although this optimization enables saving on the
      amount of messages that are sent from the presence server to the
      watcher, this optimization puts more burden on the processing time
      of the presence server as was discussed above.
   o  Throttling [20] defines a mechanism in which a watcher requires to
      be updated only in certain intervals.  Although this mechanism may
      give some extra load on the processing time of the presence
      server, that load is negligible and the reduction on the amount of
      messages sent from the presence server to the watchers is
      significant.  This optimization is even more important with
      resource lists where there can be many resources in the resource
      lists and if the traffic of updates on resource list is not
      regulated, the watcher may get very large amount of notifications.
   o  Presence specific sigcomp dictionary [15] defines a SIGCOMP [1]
      dictionary for presence.  This optimization will enable to reduce
      the number of bytes that are transferred in presence systems by
      compressing the textual SIP messages and using the specialized
      presence dictionary the compression may be more significant then
      just using SIGCOMP as is.  Note that number of actual messages
      will remain the same and a calculation of the amount of bytes that
      will be saved may be useful here.
   o  Content Indirection [6] enables sending only the URI of the
      presence document to the watcher thus offloading the presence
      server from sending the presence document to the watcher.  This
      optimization may be useful in some cases especially where there is
      a big number of users that get the same presence document.


6.  Summary

   Following is a summary of the various calculations.  This is repeated
   here in order to ease the understanding of the conclusions that are
   listed below.

   The following table summarizes the various constants that are used in
   ALL calculations.










Houri, et al.            Expires April 25, 2009                [Page 49]


Internet-Draft          Presence Scaling Analysis           October 2008


   (C01) Subscription lifetime (hours)...........................8
   (C03) Subscription refresh interval / hour....................1
   (C05) Number of dialogs to maintain per watcher = Number of
           federated presentities when dialog optimization is
           not used and to 1 when dialog optimization is used.
   (C07) SUBSCRIBE message size in bytes.......................450
   (C08) 200 OK for SUBSCRIBE message size in bytes............370
   (C09) NOTIFY message size not including presence doc........500
   (C10) 200 OK for NOTIFY message size in bytes...............370
   (C11) Size of an average presence document..........350 or 3000
           Calculations are done for both sizes
   (C12) Size of an average partial presence document..........200
   (C13) Additional data per document in RLMI..................160
   (C14) Multiparty boundary in RLMI document..................144
   (C15) XML root node in RLMI document........................144

                 Figure 14: Constants in ALL calculations

   The following table summarizes the results of various optimization
   factors for the basic use case.

   C02 Presence state changes / hour.............................3
   C04 Total federated presentities per watcher..................4
   C06 Total # of watchers in the federated domains.........40,000

   No optimizations are applied

   (B01) Total of messages between domains..............12,800,000
         Total of bytes between domains (PD=350).....7,232,000,000
         Total of bytes between domains (PD=3000)...20,376,000,000
   (B02) Total number of messages / second.. ..................444
         Total of bytes per second (PD=350)................251,111
         Total of bytes per second (PD=3000)...............707,500
   (B03) Total number of by msgs per user/day......... ........320
         Total number of bytes per user/day (PD=350).......180,800
         Total number of bytes per user/day (PD=3000)......509,400

   Dialog optimization is applied

   (B01) Total of messages between domains...............8,480,000
         Total of bytes between domains (PD=350).....8,032,080,000
         Total of bytes between domains (PD=3000)...21,176,080,000
   (B02) Total number of messages / second.....................294
         Total of bytes per second (PD=350)................278,892
         Total of bytes per second (PD=3000)...............735,281
   (B03) Total number of by msgs per user/day..................212
         Total number of bytes per user/day (PD=350).......200,802
         Total number of bytes per user/day (PD=3000)......529,042



Houri, et al.            Expires April 25, 2009                [Page 50]


Internet-Draft          Presence Scaling Analysis           October 2008


   Notify optimization is applied

   (B01) Total of messages between domains..............10,240,000
         Total of bytes between domains (PD=350).....5,670,400,000
         Total of bytes between domains (PD=3000)...15,422,400,000
   (B02) Total number of messages / second.....................356
         Total of bytes per second (PD=350)................196,889
         Total of bytes per second (PD=3000)...............535,500
   (B03) Total number of by msgs per user/day..................256
         Total number of bytes per user/day (PD=350).......141,760
         Total number of bytes per user/day (PD=3000)......385,560

   Dialog and notify optimizations are applied

   (B01) Total of messages between domains...............7,840,000
         Total of bytes between domains (PD=350).....6,824,400,000
         Total of bytes between domains (PD=3000)...16,576,400,000
   (B02) Total number of messages / second.....................272
         Total of bytes per second (PD=350)................236,958
         Total of bytes per second (PD=3000)...............575,569
   (B03) Total number of by msgs per user/day..................196
         Total number of bytes per user/day (PD=350).......170,610
         Total number of bytes per user/day (PD=3000)......414,410

                         Figure 15: Basic use case

   The following table summarizes the results of various optimization
   factors for the widely distributed inter domain use case.























Houri, et al.            Expires April 25, 2009                [Page 51]


Internet-Draft          Presence Scaling Analysis           October 2008


   C02 Presence state changes / hour.............................3
   C04 Total federated presentities per watcher.................20
   C06 Total # of watchers in the federated domains.........40,000

   No optimizations are applied

   (B01) Total of messages between domains..............64,000,000
         Total of bytes between domains (PD=350)....36,160,000,000
         Total of bytes between domains (PD=3000)..101,880,000,000
   (B02) Total number of messages / second...................2,222
         Total of bytes per second (PD=350)..............1,255,556
         Total of bytes per second (PD=3000).............3,537,500
   (B03) Total number of by msgs per user/day................1,600
         Total number of bytes per user/day (PD=350).......904,000
         Total number of bytes per user/day (PD=3000).....,547,000

   Dialog and notify optimizations are applied

   (B01) Total of messages between domains..............36,000,000
         Total of bytes between domains (PD=350)....32,755,920,000
         Total of bytes between domains (PD=3000)...81,515,920,000
   (B02) Total number of messages / second...................1,250
         Total of bytes per second (PD=350)..............1,137,358
         Total of bytes per second (PD=3000).............2,830,414
   (B03) Total number of by msgs per user/day..................900
         Total number of bytes per user/day (PD=350).......818,898
         Total number of bytes per user/day (PD=3000)....2,037,898

                Figure 16: Widely distributed inter-domain

   The following table summarizes the results of various optimization
   factors for the intra-domain peering use case.



















Houri, et al.            Expires April 25, 2009                [Page 52]


Internet-Draft          Presence Scaling Analysis           October 2008


   C02 Presence state changes / hour.............................3
   C04 Total federated presentities per watcher.................10
   C06 Total # of watchers in the federated domains........120,000

   No optimizations are applied

   B01 Total of messages between domains................96,000,000
     Total of bytes between domains (PD=350)........54,240,000,000
     Total of bytes between domains (PD=3000)......152,820,000,000
   B02 Total number of messages / second.....................3,333
     Total of bytes per second (PD=350)..................1,883,333
     Total of bytes per second (PD=3000).................5,306,250
   B03 Total number of by msgs per user/day....................800
     Total number of bytes per user/day (PD=350)...........452,000
     Total number of bytes per user/day (PD=3000)........1,273,500

   Dialog and notify optimizations are applied

   (B01) Total of messages between domains..............55,200,000
         Total of bytes between domains (PD=350)....49,646,160,000
         Total of bytes between domains (PD=3000)..122,796,160,000
   (B02) Total number of messages / second...................1,917
         Total of bytes per second (PD=350)..............1,723,825
         Total of bytes per second (PD=3000).............4,263,408
   (B03) Total number of by msgs per user/day..................460
         Total number of bytes per user/day (PD=350).......413,718
         Total number of bytes per user/day (PD=3000)....1,023,218

                      Figure 17: Inter-domain peering

   The following table summarizes the results of various optimization
   factors for the very large scale peering networks use case.

   C02 Presence state changes / hour.............................6
   C04 Total federated presentities per watcher.................10
   C06 Total # of watchers in the federated domains.....20,000,000

   No optimizations are applied

   (B01) Total of messages between domains..........25,600,000,000
         Total of bytes bet. domains (PD=350)...14,896,000,000,000
         Total of bytes bet. domains (PD=3000)..44,046,000,000,000
   (B02) Total number of messages / second.................888,889
         Total of bytes per second (PD=350)............517,222,222
         Total of bytes per second (PD=3000).........1,529,375,000
   (B03) Total number of by msgs per user/day................1,280
         Total number of bytes per user/day (PD=350).......744,800
         Total number of bytes per user/day (PD=3000)....2,202,300



Houri, et al.            Expires April 25, 2009                [Page 53]


Internet-Draft          Presence Scaling Analysis           October 2008


   Dialog and notify optimizations are applied

   (B01) Total of messages between domains..........18,800,000,000
         Total of bytes bet. domains (PD=350)...16,971,960,000,000
         Total of bytes bet. domains (PD=3000)..41,881,960,000,000
   (B02) Total number of messages / second.................652,778
         Total of bytes per second (PD=350)............589,304,167
         Total of bytes per second (PD=3000).........1,454,234,722
   (B03) Total number of by msgs per user/day..................940
         Total number of bytes per user/day (PD=350).......848,598
         Total number of bytes per user/day (PD=3000)....2,094,098

   Partial and notify optimizations are applied

   (B01) Total of messages between domains..........22,400,000,000
         Total of bytes bet. domains (PD=350)...11,564,000,000,000
         Total of bytes bet. domains (PD=3000)..12,094,000,000,000
   (B02) Total number of messages / second.................777,778
         Total of bytes per second (PD=350)............401,527,778
         Total of bytes per second (PD=3000)...........419,930,556
   (B03) Total number of by msgs per user/day................1,120
         Total number of bytes per user/day (PD=350).......578,200
         Total number of bytes per user/day (PD=3000)......604,700

   TCP only SIP+Partial+Dialog optimizations

   (B01) Total of messages between domains...........9,260,000,000
         Total of bytes between domains (PD=350).8,809,080,000,000
         Total of bytes bet. domains (PD=3000)...9,339,080,000,000
   (B02) Total number of messages / second.................321,528
         Total of bytes per second (PD=350)............305,870,833
         Total of bytes per second (PD=3000)...........324,273,611
   (B03) Total number of by msgs per user/day..................463
         Total number of bytes per user/day (PD=350).......440,454
         Total number of bytes per user/day (PD=3000)......466,954

   TCP only SIP+Partial optimizations

   (B01) Total of messages between domains...........9,800,000,000
         Total of bytes between domains (PD=350).3,380,000,000,000
         Total of bytes bet. domains (PD=3000)...3,910,280,000,000
   (B02) Total number of messages / second.................340,278
         Total of bytes per second (PD=350)............117,361,111
         Total of bytes per second (PD=3000)...........135,763,889
   (B03) Total number of by msgs per user/day..................490
         Total number of bytes per user/day (PD=350).......169,000
         Total number of bytes per user/day (PD=3000)......195,500




Houri, et al.            Expires April 25, 2009                [Page 54]


Internet-Draft          Presence Scaling Analysis           October 2008


               Figure 18: Very large scale peering networks


7.  Conclusions

   The following conclusions can be drawn from the above numbers:

   o  Due to the overhead of RLMI, the dialog optimization does not help
      in reducing the number of bytes nor in the number of the messages.
      It seems to be more important from the point of view of the
      convenience of the user since it enables the user to manage his/
      hers watch list on e.g. a web page.
   o  The notify optimization optimizes both the number of messages and
      the number of bytes.
   o  Partial notification saves a lot in the number of bytes especially
      when the presence document is a rich presence document which is
      relatively big.
   o  Comparing to very optimized SIP protocol (imaginary TCP only SIP)
      shows that the number of messages is less by about a half.  The
      number of bytes is also reduced by about a half.
   o  When looking at the numbers from the perspective of the number of
      bytes that a user "consumes" per day the numbers may not look so
      big.  Nevertheless, we should remember that the overall affect on
      the network may be quite big since the network will have to convey
      dozens of Giga bytes per day for the modest use cases that are
      described in this document for presence traffic only.  Recalling
      that presence is only an enabler for other media these numbers are
      not so easy to handle.

   The document analyzes the scalability of presence systems and of the
   SIP based in particular.  It is apparent that the scalability of
   these systems is far from being trivial from several perspectives:
   number of messages, network bandwidth, state management and CPU load.

   As part of the analysis we have analyzed several optimizations and
   showed the effect of these optimizations on the number of messages
   and the number of bytes that are sent between the federating domains.

   We have also computed the number of messages and bytes for a very
   large scale peering network while assuming a protocol that has much
   less overhead then SIP.  Even in that protocol we got relatively high
   numbers.

   It is very possible that the issues that are described in this
   document are inherent to presence systems in general and not specific
   to the SIMPLE protocol.  Organizations need to be prepared to invest
   a lot in network and hardware in order to create real big systems.
   However, it is apparent that not all the possible optimizations were



Houri, et al.            Expires April 25, 2009                [Page 55]


Internet-Draft          Presence Scaling Analysis           October 2008


   done yet and further work is needed in the IETF in order to provide
   better scalability

   Nevertheless, we should remember that SIP was originally designed for
   end to end session creation and number and size of messages are of
   secondary importance for end to end session negotiation.  For large
   scale and especially for very large scale presence the number of
   messages that are needed and the size of each message are of extreme
   importance.  It seems that we need to think about the problem in a
   different way.  We need to think about scalability as part of the
   protocol design.  The IETF tends not to think about actual
   deployments when designing a protocol but in this case it seems that
   if we do not think about scalability with the protocol design it will
   be very hard to scale.

   We should also consider whether using the same protocol between
   clients and servers and between servers is a good choice with this
   problem?  It may be that in interdomain or even between servers in
   the same domain (as between RLSs and presence servers) there is a
   need to have a different protocol that will be very optimized for the
   load and can assume some assumptions about the network (e.g. do not
   use unreliable protocol as UDP but only TCP).

   When servers is connecting to another server using current protocol,
   there will be an extreme number of redundant messages due to the
   overhead of supporting UDP and to the need to send multiple presence
   documents for the same watched user due to privacy issue.  A server
   to server protocol will have to address these issues.  Some initial
   work to address these issues can be found in: [19], [21] and [22]

   Another issue that is more concerning protocol design is whether
   NOTIFY messages should not be considered as media as audio, video and
   even text messaging are considered?  The SUBSCRIBE can be extended to
   do similar three way handshake as INVITE and negotiate where the
   notify messages should go, rate and other parameters.  This way the
   load can be offloaded to a specialized NOTIFY "relays" thus not
   loading the control path of SIP.  One of the possible ideas (Marc
   Willekens) is to use the SIP stack for the client/server NOTIFY but
   make use of a more optimized and controllable protocol for the
   server-to-server interface.  Another possibility is to use the MSRP
   [10], [11]protocol for the notifies.


8.  Security Considerations

   This document discusses scalability issues with the existing SIP/
   SIMPLE presence protocol and model.  Therefore, there are no security
   considerations to be considered for this document.  However, a lot of



Houri, et al.            Expires April 25, 2009                [Page 56]


Internet-Draft          Presence Scaling Analysis           October 2008


   the possible optimizations that should emerge as a result of this
   document will have security implications that will need to be solved.


9.  IANA Considerations

   This document has no actions for IANA.


10.  Changes from Previous Versions

10.1.  Changes in version 05

   o  Fixed mistakes in calculations that were found by Victoria
      Beltran-Martinez, both relate to dialog optimizations.  One
      mistake was not including the multipart boundary of the resource
      list itself in S03 when dialog optimizations were used.  The other
      one was assuming in T07 that only a single presentity is returned
      in termination in T07 calculation.
   o  Fixed nits that were referred to me by Robert Sparks

10.2.  Changes in version 04

   o  Fixed mistake in the formula of I07 and S08 (RLMI was not
      included).  Affect on total number of bytes was very small.
   o  Fixed mistake in the text of the calculation of number of bytes
      for S08 for non dialog optimization.  No actual change in number
      of bytes since the excel file calculations were done correctly.
   o  Removed general references throughout the text to "other
      protocols".  This was done in order to avoid the impression that
      the document tries to compare SIP protocol with any other presence
      base protocol.
   o  Several other editorial and clarification changes

10.3.  Changes in version 03

   o  Added some input from real life deployments and input on a test
      with batched notifies.
   o  Added Calculations of messages and bytes per user.
   o  Calculations are now done both for minimal size of presence
      document and for an average size of rich presence document.
   o  Comparison with other protocol is now done using small, tiny and
      rich presence document sizes.
   o  Removed dialog optimization with partial notification since it is
      not relevant
   o  Fixed a few issues in calculations that were found by Victoria
      Beltran-Martinez.




Houri, et al.            Expires April 25, 2009                [Page 57]


Internet-Draft          Presence Scaling Analysis           October 2008


      *  Added overhead for RLMI for dialog optimizations (list
         subscription).  This calculation fix actually shows that dialog
         optimization is not a real optimization from the point of view
         of bytes and number of messages.
      *  When NOTIFY optimizations are applied no need for final NOTIFY
      *  The usage of RLS between domains was clarified.
   o  Significantly enhanced the conclusions section
   o  Several typo fixes

10.4.  Changes in version 02

   o  Fixed a bug in the calculations.  Thanks to Marc Willekens for
      finding the bug.

10.5.  Changes in version 01

   o  Clarifications and corrections of the computation model and the
      computations.
   o  Added several more computations to show the influence of different
      optimizations.
   o  The requirements were moved to [18]
   o  The new suggestions for optimizations were moved to [19]


11.  Acknowledgments

   We would like to thank Jonathan Rosenberg, Ben Campbell, Robert
   Sparks, Markus Isomaki Piotr Boni, David Viamonte, Aki Niemi and
   Peter-Saint Andre for ideas and input.  Special thanks to Marc
   Willekens and Victoria Beltran-Martinez for finding several issues in
   the calculations.


12.  Informational References

   [1]   Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu,
         Z., and J. Rosenberg, "Signaling Compression (SigComp)",
         RFC 3320, January 2003.

   [2]   Rosenberg, J., "A Watcher Information Event Template-Package
         for the Session Initiation Protocol (SIP)", RFC 3857,
         August 2004.

   [3]   Rosenberg, J., "An Extensible Markup Language (XML) Based
         Format for Watcher Information", RFC 3858, August 2004.

   [4]   Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
         J. Peterson, "Presence Information Data Format (PIDF)",



Houri, et al.            Expires April 25, 2009                [Page 58]


Internet-Draft          Presence Scaling Analysis           October 2008


         RFC 3863, August 2004.

   [5]   Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg,
         "RPID: Rich Presence Extensions to the Presence Information
         Data Format (PIDF)", RFC 4480, July 2006.

   [6]   Burger, E., "A Mechanism for Content Indirection in Session
         Initiation Protocol (SIP) Messages", RFC 4483, May 2006.

   [7]   Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-
         Requena, "Functional Description of Event Notification
         Filtering", RFC 4660, September 2006.

   [8]   Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-
         Requena, "An Extensible Markup Language (XML)-Based Format for
         Event Notification Filtering", RFC 4661, September 2006.

   [9]   Roach, A., Campbell, B., and J. Rosenberg, "A Session
         Initiation Protocol (SIP) Event Notification Extension for
         Resource Lists", RFC 4662, August 2006.

   [10]  Campbell, B., Mahy, R., and C. Jennings, "The Message Session
         Relay Protocol (MSRP)", RFC 4975, September 2007.

   [11]  Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the
         Message Sessions Relay Protocol (MSRP)", RFC 4976,
         September 2007.

   [12]  Lonnfors, M., Costa-Requena, J., Leppanen, E., and H.
         Khartabil, "Session Initiation Protocol (SIP) Extension for
         Partial Notification of Presence Information", RFC 5263,
         September 2008.

   [13]  Niemi, A., Lonnfors, M., and E. Leppanen, "Publication of
         Partial Presence Information", RFC 5264, September 2008.

   [14]  Rosenberg, J., "Presence Authorization Rules", RFC 5025,
         December 2007.

   [15]  Garcia-Martin, M., "The Presence-Specific Static Dictionary for
         Signaling Compression (Sigcomp)", RFC 5112, January 2008.

   [16]  Camarillo, G., "Subscriptions to Request-Contained Resource
         Lists in the Session Initiation  Protocol (SIP)",
         draft-ietf-sipping-uri-list-subscribe-05 (work in progress),
         May 2006.

   [17]  Niemi, A., "An Extension to Session Initiation Protocol (SIP)



Houri, et al.            Expires April 25, 2009                [Page 59]


Internet-Draft          Presence Scaling Analysis           October 2008


         Events for Conditional  Event Notification",
         draft-ietf-sip-subnot-etags-03 (work in progress), July 2008.

   [18]  Houri, A., Parameswar, S., Aoki, E., Singh, V., and H.
         Schulzrinne, "Scaling Requirements for Presence in SIP/SIMPLE",
         draft-ietf-sipping-presence-scaling-requirements-01 (work in
         progress), July 2008.

   [19]  Houri, A., "Scaling Optimizations for Presence in SIP/SIMPLE",
         draft-houri-simple-interdomain-scaling-optimizations-00 (work
         in progress), July 2007.

   [20]  Niemi, A., Kiss, K., and S. Loreto, "Session Initiation
         Protocol (SIP) Event Notification Extension for  Notification
         Throttling", draft-niemi-sipping-event-throttle-07 (work in
         progress), October 2008.

   [21]  Rosenberg, J., Donovan, S., and K. McMurry, "Optimizing
         Federated Presence with View Sharing",
         draft-ietf-simple-view-sharing-01 (work in progress),
         July 2008.

   [22]  Rosenberg, J., Houri, A., and C. Smyth, "Models for Intra-
         Domain Presence and Instant Messaging (IM) Federation",
         draft-ietf-simple-intradomain-federation-01 (work in progress),
         July 2008.


Authors' Addresses

   Avshalom Houri
   IBM
   Science Park
   Rehovot,
   Israel

   Email: avshalom@il.ibm.com


   Edwin Aoki
   AOL  LLC
   401 Ellis St.
   Mountain View, CA  94043
   USA

   Email: aoki@aol.net





Houri, et al.            Expires April 25, 2009                [Page 60]


Internet-Draft          Presence Scaling Analysis           October 2008


   Sriram Parameswar
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052
   USA

   Email: Sriram.Parameswar@microsoft.com


   Tim Rang
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052
   USA

   Email: timrang@microsoft.com


   Vishal Singh
   Columbia University
   Department of Computer Science
   450 Computer  Science Building
   New York, NY  10027
   US

   Email: vs2140@cs.columbia.edu
   URI:   http://www.cs.columbia.edu/~vs2140


   Henning Schulzrinne
   Columbia University
   Department of Computer Science
   450 Computer  Science Building
   New York, NY  10027
   US

   Phone: +1 212 939  7004
   Email: hgs+ecrit@cs.columbia.edu
   URI:   http://www.cs.columbia.edu/~hgs












Houri, et al.            Expires April 25, 2009                [Page 61]


Internet-Draft          Presence Scaling Analysis           October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Houri, et al.            Expires April 25, 2009                [Page 62]