SIMPLE WG                                                       A. Houri
Internet-Draft                                                       IBM
Intended status: Informational                                   E. Aoki
Expires: January 9, 2010                                        AOL  LLC
                                                           S. Parameswar
                                                                 T. Rang
                                                   Microsoft Corporation
                                                                V. Singh
                                                          H. Schulzrinne
                                                             Columbia U.
                                                            July 8, 2009


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

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 January 9, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights



Houri, et al.            Expires January 9, 2010                [Page 1]


Internet-Draft          Presence Scaling Analysis              July 2009


   and restrictions with respect to this document.

Abstract

   The document analyzes the traffic that is generated by presence
   subscriptions between domains and shows that the amount of traffic
   can be extremely large.  The document also analyzes the effects of a
   large presence system on the memory footprint and the CPU load.
   Approved and in-work optimizations to the Session Initiation Protocol
   are analyzed 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.  Message Load Optimizations Considered  . . . . . . . . . .  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 . . . . . . . . . . . . . . . . . 11
       2.3.5.  Bottom Line  . . . . . . . . . . . . . . . . . . . . . 12
       2.3.6.  Rush Hour Calculations . . . . . . . . . . . . . . . . 12
     2.4.  No optimizations used  . . . . . . . . . . . . . . . . . . 13
     2.5.  Dialog optimization used . . . . . . . . . . . . . . . . . 15
     2.6.  NOTIFY optimization used . . . . . . . . . . . . . . . . . 17
     2.7.  Dialog and NOTIFY optimizations used . . . . . . . . . . . 19
     2.8.  Presence Federation Scenarios  . . . . . . . . . . . . . . 21
       2.8.1.  Widely distributed inter-domain presence . . . . . . . 21
       2.8.2.  Associated inter-domain presence . . . . . . . . . . . 26
       2.8.3.  Large network peering  . . . . . . . . . . . . . . . . 26
       2.8.4.  Intra-domain peering . . . . . . . . . . . . . . . . . 31
     2.9.  Partial Notifications Optimization . . . . . . . . . . . . 35
     2.10. Extremely Optimized SIP  . . . . . . . . . . . . . . . . . 37
   3.  State Management . . . . . . . . . . . . . . . . . . . . . . . 42
     3.1.  State Size Calculations  . . . . . . . . . . . . . . . . . 43
       3.1.1.  Tiny System  . . . . . . . . . . . . . . . . . . . . . 43
       3.1.2.  Medium System  . . . . . . . . . . . . . . . . . . . . 43
       3.1.3.  Large System . . . . . . . . . . . . . . . . . . . . . 44
       3.1.4.  Larger System  . . . . . . . . . . . . . . . . . . . . 44
   4.  Processing complexities  . . . . . . . . . . . . . . . . . . . 45
     4.1.  Aggregation  . . . . . . . . . . . . . . . . . . . . . . . 45
     4.2.  Partial Publish and Notify . . . . . . . . . . . . . . . . 45
     4.3.  Filtering  . . . . . . . . . . . . . . . . . . . . . . . . 46



Houri, et al.            Expires January 9, 2010                [Page 2]


Internet-Draft          Presence Scaling Analysis              July 2009


     4.4.  Authorization  . . . . . . . . . . . . . . . . . . . . . . 46
     4.5.  Resource List Service  . . . . . . . . . . . . . . . . . . 46
   5.  Current Optimizations  . . . . . . . . . . . . . . . . . . . . 47
   6.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
   7.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 54
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 55
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 56
   10. Changes from Previous Versions . . . . . . . . . . . . . . . . 56
     10.1. Changes in version 07  . . . . . . . . . . . . . . . . . . 56
     10.2. Changes in version 06  . . . . . . . . . . . . . . . . . . 56
     10.3. Changes in version 05  . . . . . . . . . . . . . . . . . . 56
     10.4. Changes in version 04  . . . . . . . . . . . . . . . . . . 56
     10.5. Changes in version 03  . . . . . . . . . . . . . . . . . . 57
     10.6. Changes in version 02  . . . . . . . . . . . . . . . . . . 57
     10.7. Changes in version 01  . . . . . . . . . . . . . . . . . . 57
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 57
   12. Informational References . . . . . . . . . . . . . . . . . . . 58
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59

































Houri, et al.            Expires January 9, 2010                [Page 3]


Internet-Draft          Presence Scaling Analysis              July 2009


1.  Introduction

   The document analyzes the traffic that is generated by Session
   Initiation Protocol (SIP) for presence (as defined by the SIMPLE
   working group) due to presence subscriptions between domains.  It
   shows that the number of messages and the amount of data generated
   can be extremely large.  This document also analyzes the effects of a
   large presence system on the memory footprint and the CPU load.
   Approved and in-work optimizations to SIP are analyzed with the
   possible impact on the load.  Another document provides requirements
   for optimizations [1] while other documents contain suggestions for
   new optimizations: [2] and [3]

   This document is intended to drive work on possible solutions that
   will make the deployment of a SIP-based presence server a less
   challenging task.  Deployment of highly scalable presence systems is
   challenging by its nature, and protocol developers design their own
   techniques for optimizing their protocols.  Comparing protocols is
   beyond the scope of this document.

   The document discusses the following areas, showing the complexity
   and load that the presence server handles in order to provide its
   service:

   o  Message load - By computing the number of messages that are
      required for connecting presence systems, the document shows that
      the number of messages and the required bandwidth are large, and
      that it is quite obvious that optimizations are needed.
   o  State management - Due to the nature of the service that the
      presence server provides, the presence server has to manage a
      relatively large and complex state, and some computations are
      provided in the document.
   o  Processing complexities - The presence server maintains many small
      objects and performs frequent operations on these objects.  We
      show that these operations and the optimizations that are intended
      to reduce the amount of data sent between watchers and presence
      servers are not so simple and may create a heavy processing load
      on the presence server.
   o  Groups - Resource List Servers [4] optimize the number of sessions
      that are created between the watchers and the presence server.
      However, this optimization may create an exponential size of
      subscriptions due to the minimal effort of subscribing to large
      groups.

   The terms presence domain or presence system appear in this document
   frequently.  These terms refer to SIP-based presence servers that
   provide presence subscription and notification services to their
   users.  A presence system can be deployed in a small enterprise or in



Houri, et al.            Expires January 9, 2010                [Page 4]


Internet-Draft          Presence Scaling Analysis              July 2009


   a 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 large number
   of messages and wide bandwidth are needed in order to establish
   federation between presence systems of large communities.  Further
   thinking is needed in order to make large deployment of presence
   systems less resource demanding.

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

2.1.  Message Load Optimizations Considered

   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 such
      as the resource list RFC [4] or to the URI list subscriptions RFC
      [5].  These documents define ways to reduce the number of dialogs
      that are required between the subscriber and the presence system.

         Note that the terms dialog optimization or RLS usage as used in
         this document refer to the usage of a URI that represents a
         list of URI lists between domains and not within the same
         domain.  An example is a user Alice in domain example.org who
         subscribes to the URI external-reps-list at example.com or uses
         a URI list to subscribe to her watch list in example.com.  Note
         also that, when calculating the traffic due to the RLS within a
         domain, the traffic between the RLS and the presence agents
         should also be considered.  However, since we are mostly
         concerned with inter- domain traffic, we are not taking into
         account the traffic between the RLS and the presence agents.
   o
      Notification optimizations - Here we refer to the optimizations
      covered in the subnot-etags draft [6], which describes the
      suppression of unnecessary NOTIFYs when subscriptions are
      refreshed.  There are other drafts that reduce the size of
      messages by using partial notifications or filtering.  This
      document shows that partial optimizations can reduce the bandwidth
      but do not reduce the number of messages.




Houri, et al.            Expires January 9, 2010                [Page 5]


Internet-Draft          Presence Scaling Analysis              July 2009


   One optimation that was not considered is the reception of presence
   information outside of SIP.  An example of this is the ability to
   download persistent presence information directly from a web site.
   The calculations assume that all presence data is carried within SIP
   and not by other means.  These out-of-band optimizations may improve
   the number of messages and number of bytes significantly, but they
   are out of scope for this document.

2.2.  Assumptions

   In this document, several assumptions are used regarding size of
   messages, rate of presence change and more.  It should be noted that
   these assumptions are not directly based on rigorous statistics from
   actual SIP-based deployments of presence systems but more 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  There are approximately 110 users on a watch list on average.
   o  There are approximately 12 billion status changes a day (139k/
      second) across the network.  When a proprietary binary protocol
      conveys the status changes, the average message size is about 188
      bytes.  When a SIP NOTIFY is used, the average is about 1228
      bytes.
   o  The average number of logins/logouts in the system is about 2000
      logins per second and about 4000 logouts per second.  When a
      promotion, contest, or a network hiccup 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 an enterprise deployment, we have seen the following patterns:

   o  Average 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 a
   specific system but to show that even with VERY moderate assumptions
   (which are even less than the observations mentioned above), the



Houri, et al.            Expires January 9, 2010                [Page 6]


Internet-Draft          Presence Scaling Analysis              July 2009


   number of messages, the network bandwidth, the required state
   management, and the CPU load are high.  Real-life systems could have
   much larger scalability challenges.  For example, the presence state
   change that we assumed (one presence state change per hour) is maybe
   one of the most moderate assumptions that we have taken.  Experience
   from consumer networks shows that the frequency can be much higher,
   especially with the younger generation using more presence attributes
   like mood, etc.  In an environment where a user may have several
   devices and other resources for presence information such as
   geographical location and calendar, the frequency of presence state
   changes will be much higher.

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

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

   The same is correct for the number of watched presentities per
   watcher.  If only some percentage of the domain users are online at a
   given time, then this number should match that percentage.  However,
   adding this assumption to the calculations will make the calculations
   more complex since the effect of the watched offline presentities
   would need to be considered.  This means that empty NOTIFYs would be
   sent for offline presentities when the subscription is created and
   there are no updates on them.  In order to make the computations less
   complex (they are complex enough as they are), the number of the
   watched presentities used in the calculations is the number of the
   federated presentities from the watcher list that are online.







Houri, et al.            Expires January 9, 2010                [Page 7]


Internet-Draft          Presence Scaling Analysis              July 2009


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 the "constants" that we use in the calculations.
   Some of the constants are used throughout the calculations 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.
      Note that the term "day" that is used in the document and C01 are
      synonymous.
   o  (C02) Presence state changes / hour - The average time that a
      presentity changes his/her status in one hour.  We assumed 3 times
      per hour for most calculations.  Note that for some users in
      consumer messaging systems, the actual number of changes is likely
      to be much higher.
   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



Houri, et al.            Expires January 9, 2010                [Page 8]


Internet-Draft          Presence Scaling Analysis              July 2009


      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 C04,
      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 SUBSCRIBE 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.  Two sizes of average
      presence doucment are used.  One is the minimal size of the PIDF
      [7] document, assumed to be 350 bytes based on examples from RFCs,
      and the other is 3000 bytes for a rich presence document [8].  It
      should be noted that 3000 bytes for a presence document is
      relatively modest if we take into account multiple devices and
      location information.
   o  (C12) The size of a NOTIFY when partial notification [9] is used.
      We have taken this size to be 200 bytes, much smaller than the
      example given in [9], which assumes multiple changes in the
      presence document.  Here we assume a single change.

         When dialog optimization [4] is used, an RLMI document, which
         contains the presence documents for the users on the watch
         list, is sent.  In a previous version of this document, we had
         omitted the overhead of the RLMI document.  This "bug" was
         found by Victoria Beltran-Martinez and is fixed in this version
         by adding the following constants C13, C14 and C15 to the
         calculations:
   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.





Houri, et al.            Expires January 9, 2010                [Page 9]


Internet-Draft          Presence Scaling Analysis              July 2009


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 the 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 depending on the use of dialog optimization.
      When dialog optimization is not applied, the number of bytes is
      calculated by (I01*C06*C09)+(I01*C06*C11).  When dialog
      optimization is applied, the number of bytes is 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 steady state messages.  Steady
   state is the time between the initial subscription and the teardown
   of the subscription.  It contains the NOTIFYs due to state change and
   the subscription refreshes.

   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 messages (for NOTIFYs 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  (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 depends on the use of dialog optimization.  When dialog
      optimization is not applied, the number of bytes is calculated by
      (C06*C04)*((S01*(C09+C11))+(S02*C10)) and when dialog optimization



Houri, et al.            Expires January 9, 2010               [Page 10]


Internet-Draft          Presence Scaling Analysis              July 2009


      is applied, the number of bytes is calculated by
      (C06*C04)*((S01*(C09+C11+C13+C14+C15+C14))+(S02*C10)).  This
      includes the multipart boundary of the resource list.  Note that,
      for dialog optimization, it is assumed that only a single
      presentity is changed and partial state notification is used.
   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.  If NOTIFY optimization is used [6], there is
      no need to send NOTIFYs for refreshes, and S06 will be zero.
   o  (S07) Number of 200 OK messages for NOTIFY messages for refreshes
      per watcher per day = ((C01/C03)-1)*C05.  If NOTIFY optimization
      is used [6], there is no need to send NOTIFYs for refreshes, and
      S07 will be zero.
   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 SUBSCRIBE bytes (S04*C06*C07), the OK
      bytes for the SUBSCRIBE (S05*C06*C08), the NOTIFY bytes
      C06*(S06*(C09+C11)) and the OK bytes for the NOTIFY (S07*C06*C10).
      Note that the formula for the NOTIFY bytes assumes that dialog
      optimization is not used.  When dialog optimization is used, the
      formula is: C06*(S06*((C09+C14+C15)+(C04*(C11+C13+C14)))).  Note
      that a full state should be given in SUBSCRIBE refreshes in
      resource lists.  See section 5.2 in [4].  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.
   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 subscriptions.  The calculations contain
   both the 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.  If
      NOTIFY optimization is used [6], there is no need to send a NOTIFY
      for terminations, and T03 will be zero.




Houri, et al.            Expires January 9, 2010               [Page 11]


Internet-Draft          Presence Scaling Analysis              July 2009


   o  (T04) Number of terminating 200 OK messages for NOTIFY messages
      per watcher = C05.  If NOTIFY optimization is used [6], there is
      no need to send a NOTIFY for terminations, and T04 will be zero.
   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 [4].
   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).
   o  (B03) Total number of message and bytes per user per day =
      Messages: number of messages in B01/C06, Bytes: number of bytes in
      B01/C06.

2.3.6.  Rush Hour Calculations

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






Houri, et al.            Expires January 9, 2010               [Page 12]


Internet-Draft          Presence Scaling Analysis              July 2009


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 without any proposed
   optimizations.  In this example, there are two presence domains with
   a total of 40,000 federating users with an average of 4 contacts in
   the peer domain.  Note that the main calculation is done for a
   presence document size of 350 bytes, which is the base PIDF [7]
   document size, but the bottom line calculation is also given for a
   presence document size for rich presence [8], which is assumed to be
   3000 bytes based on the examples given in the RFCs.  This two-fold
   calculation is done for every use case in this document.

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

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




Houri, et al.            Expires January 9, 2010               [Page 13]


Internet-Draft          Presence Scaling Analysis              July 2009


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

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

   ** Bottom Line
   (B01) Total of messages between domains..............12,800,000
         Total of bytes between domains (PD=350).....7,232,000,000
         Total of bytes between domains (PD=3000)...20,376,000,000



Houri, et al.            Expires January 9, 2010               [Page 14]


Internet-Draft          Presence Scaling Analysis              July 2009


   (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


   ** 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



Houri, et al.            Expires January 9, 2010               [Page 15]


Internet-Draft          Presence Scaling Analysis              July 2009


             Number of msgs for all watchers................40,000
             Bytes for all watchers.....................14,800,000
   (I09) Total number & bytes of initial messages per day
             Number of msgs for all watchers...............160,000
             Bytes for all watchers....................183,760,000

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

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



Houri, et al.            Expires January 9, 2010               [Page 16]


Internet-Draft          Presence Scaling Analysis              July 2009


             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 analysis provided in Figure 1 is repeated here with the
   assumption that the notification optimization is applied.  The
   optimization saves the need for NOTIFY upon refreshing a SUBSCRIBE if
   there was no change since the last NOTIFY.  It is assumed here that
   there are no NOTIFY messages for SUBSCRIBE refreshes and
   terminations.  As expected, this optimization affects the steady and
   termination 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
   (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



Houri, et al.            Expires January 9, 2010               [Page 17]


Internet-Draft          Presence Scaling Analysis              July 2009


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

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

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



Houri, et al.            Expires January 9, 2010               [Page 18]


Internet-Draft          Presence Scaling Analysis              July 2009


   (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 and 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
   (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



Houri, et al.            Expires January 9, 2010               [Page 19]


Internet-Draft          Presence Scaling Analysis              July 2009


             Number of msgs for all watchers................40,000
             Bytes for all watchers.....................18,000,000
   (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers................40,000
             Bytes for all watchers.....................14,800,000
   (I07) Total number & bytes of initial NOTIFY msgs
             Number of msgs for all watchers................40,000
             Bytes for all watchers....................136,160,000
   (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
             Number of msgs for all watchers................40,000
             Bytes for all watchers.....................14,800,000
   (I09) Total number & bytes of initial messages per day
             Number of msgs for all watchers...............160,000
             Bytes for all watchers....................183,760,000

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

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



Houri, et al.            Expires January 9, 2010               [Page 20]


Internet-Draft          Presence Scaling Analysis              July 2009


             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 and 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
   characteristics can alter the overall effectiveness of existing
   optimizations.

   Note that the number of users considered is not the total number of
   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 numbers used for watchers and watched
   presentities are for online users.

2.8.1.  Widely distributed inter-domain presence

   In some environments, presence federation may be common, perhaps even
   more common than intra-domain presence.  An example of this type of
   environment is a small ISV or public server.  Users in that small ISV
   are not likely to subscribe to the presence of other users in the
   their server since they do not necessarily have any relationship with



Houri, et al.            Expires January 9, 2010               [Page 21]


Internet-Draft          Presence Scaling Analysis              July 2009


   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 (that is, the probability that
      multiple watchers in the domain are subscribed 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.
   Although the number of watchers in the domain could also be adjusted
   to allow for an expected larger community of users being peered with,
   it is omitted here for simplification.

   The first table below provides the calculations without
   optimizations.  The second table provides the calculations with
   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..............20
   (C06) Total number of watchers in domains................40,000
   (C07) SUBSCRIBE message size in bytes.......................450
   (C08) 200 OK for SUBSCRIBE message size in bytes............370
   (C09) NOTIFY message size not including presence doc........500
   (C10) 200 OK for NOTIFY message size in bytes...............370
   (C11) Size of an average presence document..................350

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



Houri, et al.            Expires January 9, 2010               [Page 22]


Internet-Draft          Presence Scaling Analysis              July 2009


             Number of msgs for all watchers...............800,000
             Bytes for all watchers....................680,000,000
   (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
             Number of msgs for all watchers...............800,000
             Bytes for all watchers....................296,000,000
   (I09) Total number & bytes of initial messages per day
             Number of msgs for all watchers.............3,200,000
             Bytes for all watchers..................1,632,000,000

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

   ** Termination Messages
   (T01) Terminating SUBSCRIBE msgs per watcher.................20
   (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........20
   (T03) Terminating NOTIFY msgs per watcher....................20
   (T04) Terminating 200 OK msgs (NOTIFY) per watcher...........20
   (T05) Total number & bytes of Terminating SUBSCRIBE msgs
             Number of msgs for all watchers...............800,000
             Bytes for all watchers....................360,000,000
   (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers...............800,000
             Bytes for all watchers....................296,000,000
   (T07) Total number & bytes of terminating NOTIFY msgs
             Number of msgs for all watchers...............800,000
             Bytes for all watchers....................680,000,000
   (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
             Number of msgs for all watchers...............800,000



Houri, et al.            Expires January 9, 2010               [Page 23]


Internet-Draft          Presence Scaling Analysis              July 2009


             Bytes for all watchers....................296,000,000
   (T09) Total number & bytes of terminating messages per day
             Number of msgs for all watchers.............3,200,000
             Bytes for all watchers..................1,632,000,000

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

      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

   ** 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



Houri, et al.            Expires January 9, 2010               [Page 24]


Internet-Draft          Presence Scaling Analysis              July 2009


             Bytes for all watchers....................554,720,000
   (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
             Number of msgs for all watchers................40,000
             Bytes for all watchers.....................14,800,000
   (I09) Total number & bytes of initial messages per day
             Number of msgs for all watchers...............160,000
             Bytes for all watchers....................602,320,000

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

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



Houri, et al.            Expires January 9, 2010               [Page 25]


Internet-Draft          Presence Scaling Analysis              July 2009


   (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 common.
   However, there is also a strong association between some users in the
   deployment.  These associations make it somewhat more likely that
   users in that domain are watchers of the same presentity.  This can
   occur because of business relationships (for example, two co-workers
   on a project federating with a partner company).

   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.
   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.  Large network peering

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



Houri, et al.            Expires January 9, 2010               [Page 26]


Internet-Draft          Presence Scaling Analysis              July 2009


   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 high (that is, 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 high.  Note
   also that the bandwidth required is 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
   (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



Houri, et al.            Expires January 9, 2010               [Page 27]


Internet-Draft          Presence Scaling Analysis              July 2009


             Bytes for all watchers.................74,000,000,000
   (I09) Total number & bytes of initial messages per day
             Number of msgs for all watchers...........800,000,000
             Bytes for all watchers................408,000,000,000

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

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



Houri, et al.            Expires January 9, 2010               [Page 28]


Internet-Draft          Presence Scaling Analysis              July 2009


   ** 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: 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
   (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



Houri, et al.            Expires January 9, 2010               [Page 29]


Internet-Draft          Presence Scaling Analysis              July 2009


             Number of msgs for all watchers............80,000,000
             Bytes for all watchers................170,360,000,000

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

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

   ** Bottom Line



Houri, et al.            Expires January 9, 2010               [Page 30]


Internet-Draft          Presence Scaling Analysis              July 2009


   (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: Large network peering with optimizations

2.8.4.  Intra-domain peering

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

   Common characteristics of this deployment are:

   o  The difference between subscriptions to presentities in one system
      versus the other are completely arbitrary.  Any one presentity is
      as likely to be homed on one infrastructure as the other.
   o  Active users are almost guaranteed to subscribe to many users in
      the peer infrastructure.
   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.  Although relatively conservative numbers are used, the
   number of messages is still high even though optimization may cut the
   traffic by more than 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



Houri, et al.            Expires January 9, 2010               [Page 31]


Internet-Draft          Presence Scaling Analysis              July 2009


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

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

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




Houri, et al.            Expires January 9, 2010               [Page 32]


Internet-Draft          Presence Scaling Analysis              July 2009


   ** 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

           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



Houri, et al.            Expires January 9, 2010               [Page 33]


Internet-Draft          Presence Scaling Analysis              July 2009


   (C14) Multiparty boundary in RLMI document..................144
   (C15) XML root node in RLMI document........................144

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

   ** Steady State Messages
   (S01) NOTIFY msgs due to state change
             per watched presentity per day.....................22
   (S02) 200 (for NOTIFY due to state change) msgs
             per watched presentity per day.....................22
   (S03) Total number and size of msgs due to state change per day
             Number of msgs for all watchers............52,800,000
             Bytes for all watchers.................47,836,800,000
   (S04) Number of SUBSCRIBE msgs for refreshes
             per watcher per day.................................7
   (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
             per watcher per day.................................7
   (S06) Number of NOTIFY msgs for refreshes
             per watcher per day.................................0
   (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
             per watcher per day.................................0
   (S08) Total number and size of msgs due to SUBSCRIBE refreshes
             Number of msgs for all watchers per day.....1,680,000
             Bytes for all watchers per day............688,800,000
   (S09) Total number & bytes of steady messages per day
             Number of msgs for all watchers............54,480,000
             Bytes for all watchers.................48,525,600,000

   ** Termination Messages



Houri, et al.            Expires January 9, 2010               [Page 34]


Internet-Draft          Presence Scaling Analysis              July 2009


   (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

2.9.  Partial Notifications Optimization

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

   ** Constants
   (C01) Subscription lifetime (hours)...........................8
   (C02) Presence state changes / hour...........................6
   (C03) Subscription refresh interval / hour....................1



Houri, et al.            Expires January 9, 2010               [Page 35]


Internet-Draft          Presence Scaling Analysis              July 2009


   (C04) Total federated presentities per watcher...............10
   (C05) Number of dialogs to maintain per watcher..............10
   (C06) Total number of watchers in domains............20,000,000
   (C07) SUBSCRIBE message size in bytes.......................450
   (C08) 200 OK for SUBSCRIBE message size in bytes............370
   (C09) NOTIFY message size not including presence doc........500
   (C10) 200 OK for NOTIFY message size in bytes...............370
   (C11) Size of an average presence document..................350
   (C12) Size of an average partial presence document..........200

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

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



Houri, et al.            Expires January 9, 2010               [Page 36]


Internet-Draft          Presence Scaling Analysis              July 2009


             Number of msgs for all watchers per day.2,800,000,000
             Bytes for all watchers per day......1,148,000,000,000
   (S09) Total number & bytes of steady messages per day
             Number of msgs for all watchers........21,200,000,000
             Bytes for all watchers.............10,992,000,000,000

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

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

         Figure 11: Large networks peering with NOTIFY and partial
                               optimizations

2.10.  Extremely Optimized SIP

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

   The following calculation assumes an imaginary TCP-only version of



Houri, et al.            Expires January 9, 2010               [Page 37]


Internet-Draft          Presence Scaling Analysis              July 2009


   SIP that optimizes the following:

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

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

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

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

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



Houri, et al.            Expires January 9, 2010               [Page 38]


Internet-Draft          Presence Scaling Analysis              July 2009


             Number of msgs for all watchers.....................0
             Bytes for all watchers..............................0
   (I07) Total number & bytes of initial NOTIFY msgs
             Number of msgs for all watchers............20,000,000
             Bytes for all watchers................136,680,000,000
   (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
             Number of msgs for all watchers.....................0
             Bytes for all watchers..............................0
   (I09) Total number & bytes of initial messages per day
             Number of msgs for all watchers............40,000,000
             Bytes for all watchers................139,680,000,000

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

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



Houri, et al.            Expires January 9, 2010               [Page 39]


Internet-Draft          Presence Scaling Analysis              July 2009


             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: 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
   (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



Houri, et al.            Expires January 9, 2010               [Page 40]


Internet-Draft          Presence Scaling Analysis              July 2009


   (I07) Total number & bytes of initial NOTIFY msgs
             Number of msgs for all watchers...........200,000,000
             Bytes for all watchers................100,000,000,000
   (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
             Number of msgs for all watchers.....................0
             Bytes for all watchers..............................0
   (I09) Total number & bytes of initial messages per day
             Number of msgs for all watchers...........400,000,000
             Bytes for all watchers................130,000,000,000

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

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



Houri, et al.            Expires January 9, 2010               [Page 41]


Internet-Draft          Presence Scaling Analysis              July 2009


             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: Large networks peering, TCP only SIP+Partial optimizations


3.  State Management

   In previous sections, we discussed the large number of messages that
   need to be sent to/from a presence server.  In this section, we will
   analyze the state that needs to be maintained by a presence server
   and will show it to be far from trivial.

   The presence server has two parallel tasks:

   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 to
      maintain the subscription as timers.
   o  Optional filtering information that was requested by the watcher,
      which includes information needed for filtering.  If partial
      notification is supported for the subscription, additional
      information has to be maintained.
   o  Optional rate management information as throttling.
   o  Watcher information [10], [11] that is the result of the
      subscription in order to enable watched presentities to know who
      is watching them.



Houri, et al.            Expires January 9, 2010               [Page 42]


Internet-Draft          Presence Scaling Analysis              July 2009


   For each presentity with subscriptions in the presence server, the
   presence server has to maintain the following state:

   o  A list of the subscriptions for the presentity.  Note that the
      size calculation is already handled by the subscription state
      above.
   o  Authorization information for the presentity.

   For each presentity that has published a state other than a default
   value, the presence server has to maintain the current value of the
   presentity's state.

3.1.  State Size Calculations

   Lets assume the following sizes:

   o  Subscription size - 2K bytes.  This includes watcher information
      that the presence server creates for each subscription.  This is
      for every subscription created by a watcher to each presentity
      that the watcher is watching.  So, if we have 10K watchers, we
      should have 10K of these.
   o  Subscribed to resource - 1K bytes for privacy information and
      other management information.  This is for each watched presentity
      regardless of the number of its watchers.  The subscriptions
      themselves are already calculated in the previous bullet.
   o  Resource with a state - 6K bytes.  This is a moderate assumption
      if we consider the amount of data, including calendar and
      geographical information, placed in a presence document by
      multiple devices.  This is for each presentity, watched or not,
      that has state other than the default empty state.

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.





Houri, et al.            Expires January 9, 2010               [Page 43]


Internet-Draft          Presence Scaling Analysis              July 2009


3.1.3.  Large System

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

   Total is 38G bytes.

3.1.4.  Larger 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 large number for 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 not seem so large for
      databases even for the larger system, we need to remember that
      this state is dynamic.  Subscriptions come and go all the time,
      the statuses of presentities are being updated, and so forth.
      This means that the presence server has to manage its state in a
      dynamic medium, and for such large sizes, this task is not
      trivial.
   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.  Presence is becoming more a core middleware
      functionality that holds much of the user's data.  In real life,
      the numbers above may be even higher, and the presence server can
      have additional overhead such as managing the SIP sessions,
      networking, and more.

   Although the above calculations do not show that there is a real
   issue with state management of presence in medium systems or even in
   large systems since state could be divided among different machines,
   the state size is still large.  A bigger issue with the state
   involves resource lists, which create an interlinked state between
   many servers.  In that case, the division of large state to multiple
   servers becomes less trivial.




Houri, et al.            Expires January 9, 2010               [Page 44]


Internet-Draft          Presence Scaling Analysis              July 2009


4.  Processing complexities

   The basic presence paradigm comprises a watcher and a presentity to
   which the watcher watches.  It sounds simple enough, but the presence
   server has to manage many additions and extensions, which makes
   processing complex.

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

4.1.  Aggregation

   A presence document may contain multiple resources.  These resources
   can be devices of the presentity, information from external providers
   of presence information such as geographical location, calendars, and
   more.

   The presence server needs to receive the updates from all the
   resources and to aggregate them correctly into a single presence
   document.  Although this is just a "XML processing" task, the number
   of updates that the presence server may receive, the need to keep the
   presence document aligned with its schema, and the need to notify the
   users as soon as possible create a significant processing burden on
   the presence server.

4.2.  Partial Publish and Notify

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

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

   In partial notification, 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, [9] specifies a
   versioning mechanism that enables the watcher to get the updates



Houri, et al.            Expires January 9, 2010               [Page 45]


Internet-Draft          Presence Scaling Analysis              July 2009


   based on the previous state that it has seen.  This versioning
   mechanism has to be maintained by the presence server for each
   watcher that is subscribed to a presentity and requires partial
   notification.

4.3.  Filtering

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

4.4.  Authorization

   RFC [15] defines presence authorization rules that allow presentities
   to specify what each watcher can see in their presence documents.
   The processing that the presence server performs here is similar to
   filtering.  When a presence document with defined authorization rules
   changes, the presence server creates different notifications for
   different watchers according to those rules.

4.5.  Resource List Service

   RFC [4] defines a way to subscribe to a single URI that represents a
   list of resources that are subscribed to by a single subscription.
   Although this quite useful mechanism significantly reduces the number
   of sessions between the watcher and the presence server (as we show
   in the calculations of messages), this feature has the potential to
   complicate the scaling of presence systems.

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

   o  Subscriptions and state - The resource list may contain references
      to many other presence servers in many other domains.  This
      requires the RLS to create subscriptions to other presence servers
      and buffer the state of all presentities so that it can provide
      the full state of the presentities in the list when needed.  So in
      the overall system, the number of subscriptions reduced between
      the watcher and the presence server is moved to the backend system
      while state is duplicated 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.



Houri, et al.            Expires January 9, 2010               [Page 46]


Internet-Draft          Presence Scaling Analysis              July 2009


   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 creates
      a complex linkage between the state of many components.  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 be cautious 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 system may not be
      apparent to everyone.  Furthermore, many public groups may have
      been created for other purposes, such as email systems (where the
      size of the lists is not as important), and are now used in the
      presence systems.  For example, a public group including all the
      users in the enterprise is used by many users in the enterprise,
      thus overwhelming the presence server.  Note that this is not a
      protocol or design issue, but more a usage issue that may have a
      real impact on the presence system.
   o  Stopping notifications - A watcher may accidentally subscribe to
      an extensive list and be overwhelmed by the number of NOTIFYs that
      it receives from the presence server.  There is no current way to
      stop this stream of NOTIFYs, and even canceling the subscription
      may take time before being effective.

   These issues show how an optimization can help in one part of the
   system but create even bigger problems in the overall system.  There
   is a need to think about the problems listed above, but, more than
   that, there is a need to make sure that introducing an optimization
   does not create issues in other places.


5.  Current Optimizations

   This section highlights several optimizations that are either already
   part of SIP 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 [2] and in [3].
   Note that trials with batched NOTIFYs optimization, described in [2],
   showed an improvement of 117% in the whole throughput of presence
   traffic.

   o  Subnot-etags - Draft [6].  This draft suggests ways to suppress
      the sending of unnecessary NOTIFYs when, for example, a
      subscription is refreshed.  This suggestion seems to be an
      efficient optimization since it both reduces the number of



Houri, et al.            Expires January 9, 2010               [Page 47]


Internet-Draft          Presence Scaling Analysis              July 2009


      messages sent and the processing time of the presence server.
   o  Resource List Service - [4] enables creating a single subscription
      session between the watcher and the presence server for
      subscribing to a list of users.  This reduces the number of
      sessions that are created between watchers and presence servers.
      However, this mechanism enables creating large numbers of
      subscriptions in the presence server/RLS system, thus enabling the
      creation of a large number of subscriptions between presence
      servers and RLSs with relatively few clients especially if large
      public groups are used.  It seems that, in order to really
      optimize in this area, the usage of large public groups should not
      be considered as BCP, and there should be a way for an RLS to
      create a single subscription for multiple occurrences of the same
      resource in resource lists.  See consolidated subscriptions below.
   o  Partial notify/publish - RFCs [9] and [12] define a way for the
      subscriber to request getting only what was changed in the
      presence document and for the publisher of presence information to
      publish only what was changed in the presence document since the
      last publish.  Although these optimizations reduce the amount of
      actual data sent from/to the presence server, these optimizations
      create additional processing burden on the presence server as was
      discussed above.
   o  Filtering as defined in RFCs [13], [14] enables a watcher to
      request to be notified only when the presence document fulfills
      certain conditions.  Although this optimization reduces the number
      of messages that are sent from the presence server to the watcher,
      this optimization burdens the processing time of the presence
      server as was discussed above.
   o  Throttling [16] defines a mechanism by which a watcher requests
      updates only at certain intervals.  Although this mechanism may
      add some extra load on the presence server, that load is
      negligible and the reduction of the number of messages sent from
      the presence server to the watchers is significant.  This
      optimization is even more important with resource lists, which can
      contain many resources, since the watcher may receive a large
      number of notifications if the traffic caused by updates on
      resource list is not regulated.
   o  Presence specific SigComp dictionary [17] defines a SigComp [18]
      dictionary for presence.  This optimization reduces the number of
      bytes that are transferred in presence systems by compressing the
      textual SIP messages.  By using the specialized presence
      dictionary, the compression may be more significant than just
      using SigComp as-is.  Note that number of actual messages will
      remain the same, and a calculation of the number of bytes that
      will be saved may be useful here.
   o  Content Indirection [19] enables the sending of only the URI of
      the presence document to the watcher, thus relieving the presence
      server from sending the presence document to the watcher.  This



Houri, et al.            Expires January 9, 2010               [Page 48]


Internet-Draft          Presence Scaling Analysis              July 2009


      optimization may be useful in some cases, especially when a large
      number of users receive the same presence document.


6.  Summary

   The following summary of the various calculations is provided here to
   help support the conclusions listed below.

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

   (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



Houri, et al.            Expires January 9, 2010               [Page 49]


Internet-Draft          Presence Scaling Analysis              July 2009


   Dialog optimization is applied

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

   Notify optimization is applied

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

   Dialog and notify optimizations are applied

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

                         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 January 9, 2010               [Page 50]


Internet-Draft          Presence Scaling Analysis              July 2009


   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 January 9, 2010               [Page 51]


Internet-Draft          Presence Scaling Analysis              July 2009


   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 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 January 9, 2010               [Page 52]


Internet-Draft          Presence Scaling Analysis              July 2009


   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 January 9, 2010               [Page 53]


Internet-Draft          Presence Scaling Analysis              July 2009


                  Figure 18: 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
      reduce the number of bytes nor the number of the messages.  It
      seems to be more important from the point of view of the user
      since it enables convenient management of his/her watch list on,
      for example, a web page.
   o  The notify optimization optimizes both the number of messages and
      the number of bytes.
   o  Partial notification saves a large number of bytes especially when
      the presence document is a rich presence document, which is
      relatively large.
   o  Extremely optimized SIP (imaginary TCP-only SIP) cuts the number
      of messages by about a half.  The number of bytes is also reduced
      by about a half.
   o  From the perspective of the number of bytes that a user "consumes"
      per day, the numbers may not look so large.  Nevertheless, we
      should remember that the overall effect on the network may be
      quite large since the network will have to convey dozens of
      gigabytes of presence traffic per day for the modest use cases
      that are described in this document.  Recalling that presence is
      only an enabler for other media, these numbers are not so easy to
      handle.

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

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

   We have also computed the number of messages and bytes for a large-
   scale peering network while assuming a protocol that has much less
   overhead than SIP.  Even with that protocol, we calculated relatively
   high numbers.

   It is possible that the issues described in this document are
   inherent to presence systems in general and not specific to the
   SIMPLE protocol.  Organizations need to be prepared to invest a lot
   in network and hardware in order to create real large systems.



Houri, et al.            Expires January 9, 2010               [Page 54]


Internet-Draft          Presence Scaling Analysis              July 2009


   However, it is apparent that not all the possible optimizations were
   done yet and further work is needed in the IETF in order to provide
   better scalability.

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

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

   When a server connects to another server using the current protocol,
   there will be an extreme number of redundant messages due to the
   overhead of supporting UDP and the need to send multiple presence
   documents for the same watched user due to privacy issues.  A server-
   to-server protocol will have to address these issues.  Some initial
   work to address these issues can be found in [2], [3] and [20]

   Another issue that concerns protocol design is whether NOTIFY
   messages should not be considered as media like audio, video and even
   text messaging are considered.  The SUBSCRIBE method can be extended
   to create a three-way handshake similar to INVITE and negotiate where
   the NOTIFY messages should go, rate, and other parameters.  This way,
   the load can be shifted to specialized NOTIFY "relays", and taken off
   the control path of SIP.  One of the possible ideas (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 [21], [22]protocol
   for the NOTIFYs.


8.  Security Considerations

   This document discusses scalability issues with the existing SIP/



Houri, et al.            Expires January 9, 2010               [Page 55]


Internet-Draft          Presence Scaling Analysis              July 2009


   SIMPLE presence protocol and model.  Therefore, there are no security
   considerations to be considered for this document.  However, many of
   the possible optimizations that should emerge as a result of this
   document will have security implications that will need to be solved.


9.  IANA Considerations

   This document has no actions for IANA.


10.  Changes from Previous Versions

10.1.  Changes in version 07

   Added clarifications, fixed typos and language usage issues raised
   during the IETF last call.

10.2.  Changes in version 06

   Updated to conform with new IETF IPR boilerplate and updated
   references.

10.3.  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.4.  Changes in version 04

   o  Fixed mistake in the formula of I07 and S08 (RLMI was not
      included).  Effect on total number of bytes was infitesimile.
   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






Houri, et al.            Expires January 9, 2010               [Page 56]


Internet-Draft          Presence Scaling Analysis              July 2009


10.5.  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.
      *  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.6.  Changes in version 02

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

10.7.  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 [1]
   o  The new suggestions for optimizations were moved to [2]


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.  Additional special thanks to A. Jean Mahoney
   and Joel M. Helpern for their dedicated review as part of the IETF
   last call.





Houri, et al.            Expires January 9, 2010               [Page 57]


Internet-Draft          Presence Scaling Analysis              July 2009


12.  Informational References

   [1]   Houri, A., Parameswar, S., Aoki, E., Singh, V., and H.
         Schulzrinne, "Scaling Requirements for Presence in SIP/SIMPLE",
         draft-ietf-sipcore-presence-scaling-requirements-00 (work in
         progress), April 2009.

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

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

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

   [5]   Camarillo, G., Roach, A., and O. Levin, "Subscriptions to
         Request-Contained Resource Lists in the Session Initiation
         Protocol (SIP)", RFC 5367, October 2008.

   [6]   Niemi, A., "An Extension to Session Initiation Protocol (SIP)
         Events for Conditional  Event Notification",
         draft-ietf-sipcore-subnot-etags-02 (work in progress),
         April 2009.

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

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

   [9]   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.

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

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



Houri, et al.            Expires January 9, 2010               [Page 58]


Internet-Draft          Presence Scaling Analysis              July 2009


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

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

   [14]  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.

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

   [16]  Niemi, A., Kiss, K., and S. Loreto, "Session Initiation
         Protocol (SIP) Event Notification Extension for  Notification
         Rate Control", draft-ietf-sipcore-event-rate-control-00 (work
         in progress), May 2009.

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

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

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

   [20]  Rosenberg, J., Houri, A., Smyth, C., and F. Audet, "Models for
         Intra-Domain Presence and Instant Messaging (IM) Bridging",
         draft-ietf-simple-intradomain-federation-03 (work in progress),
         March 2009.

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

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











Houri, et al.            Expires January 9, 2010               [Page 59]


Internet-Draft          Presence Scaling Analysis              July 2009


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


   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




Houri, et al.            Expires January 9, 2010               [Page 60]


Internet-Draft          Presence Scaling Analysis              July 2009


   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 January 9, 2010               [Page 61]