SIMPLE WG                                                       A. Houri
Internet-Draft                                                       IBM
Intended status: Informational                                   E. Aoki
Expires: May 21, 2008                                            AOL LLC
                                                           S. Parameswar
                                                                 T. Rang
                                                   Microsoft Corporation
                                                                V. Singh
                                                          H. Schulzrinne
                                                             Columbia U.
                                                       November 18, 2007


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

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on May 21, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   The document analyzes the traffic that is generated due to presence



Houri, et al.             Expires May 21, 2008                  [Page 1]


Internet-Draft          Presence Scaling Analysis          November 2007


   subscriptions between domains.  It is shown that the amount of
   traffic can be extremely big.  In addition to the very large traffic
   the document also analyzes the affects of a large presence system on
   the memory footprint and the CPU load.  Current approved and in work
   optimizations to the SIMPLE protocol are analyzed with the possible
   impact on the load.  Separate documents contain the requirements for
   optimizations and suggestions for new optimizations.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Message Load . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Known Optimizations  . . . . . . . . . . . . . . . . . . .  5
     2.2.  Assumptions  . . . . . . . . . . . . . . . . . . . . . . .  6
     2.3.  Analysis . . . . . . . . . . . . . . . . . . . . . . . . .  7
       2.3.1.  Constants  . . . . . . . . . . . . . . . . . . . . . .  7
       2.3.2.  Initial Messages . . . . . . . . . . . . . . . . . . .  9
       2.3.3.  Steady State Messages  . . . . . . . . . . . . . . . . 10
       2.3.4.  Termination Messages . . . . . . . . . . . . . . . . . 11
       2.3.5.  Bottom Line  . . . . . . . . . . . . . . . . . . . . . 11
       2.3.6.  Rush Hour Calculations . . . . . . . . . . . . . . . . 12
     2.4.  SIMPLE with no optimizations . . . . . . . . . . . . . . . 12
     2.5.  SIMPLE with dialog optimization  . . . . . . . . . . . . . 14
     2.6.  SIMPLE with NOTIFY optimization  . . . . . . . . . . . . . 16
     2.7.  SIMPLE with Dialog & NOTIFY optimizations  . . . . . . . . 18
     2.8.  Presence Federations . . . . . . . . . . . . . . . . . . . 20
       2.8.1.  Widely distributed inter-domain presence . . . . . . . 21
       2.8.2.  Associated inter-domain presence . . . . . . . . . . . 25
       2.8.3.  Very large network peering . . . . . . . . . . . . . . 26
       2.8.4.  Intra-domain peering . . . . . . . . . . . . . . . . . 30
     2.9.  Partial Notifications Optimization . . . . . . . . . . . . 35
     2.10. Other Protocols  . . . . . . . . . . . . . . . . . . . . . 37
   3.  State Management . . . . . . . . . . . . . . . . . . . . . . . 39
     3.1.  State Size Calculations  . . . . . . . . . . . . . . . . . 40
       3.1.1.  Tiny System  . . . . . . . . . . . . . . . . . . . . . 40
       3.1.2.  Medium System  . . . . . . . . . . . . . . . . . . . . 41
       3.1.3.  Large System . . . . . . . . . . . . . . . . . . . . . 41
       3.1.4.  Very Large System  . . . . . . . . . . . . . . . . . . 41
   4.  Processing complexities  . . . . . . . . . . . . . . . . . . . 42
     4.1.  Aggregation  . . . . . . . . . . . . . . . . . . . . . . . 42
     4.2.  Partial Publish and Notify . . . . . . . . . . . . . . . . 42
     4.3.  Filtering  . . . . . . . . . . . . . . . . . . . . . . . . 43
     4.4.  Authorization  . . . . . . . . . . . . . . . . . . . . . . 43
     4.5.  Resource List Service  . . . . . . . . . . . . . . . . . . 43
   5.  Current Optimizations  . . . . . . . . . . . . . . . . . . . . 45
   6.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
   7.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 51



Houri, et al.             Expires May 21, 2008                  [Page 2]


Internet-Draft          Presence Scaling Analysis          November 2007


   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 53
   9.  Changes from Previous Versions . . . . . . . . . . . . . . . . 54
     9.1.  Changes in version 03  . . . . . . . . . . . . . . . . . . 54
     9.2.  Changes in version 02  . . . . . . . . . . . . . . . . . . 54
     9.3.  Changes in version 01  . . . . . . . . . . . . . . . . . . 54
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 54
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 55
     11.2. Informational References . . . . . . . . . . . . . . . . . 55
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57
   Intellectual Property and Copyright Statements . . . . . . . . . . 59








































Houri, et al.             Expires May 21, 2008                  [Page 3]


Internet-Draft          Presence Scaling Analysis          November 2007


1.  Introduction

   The document analyzes the traffic that is generated due to presence
   subscriptions between domains.  It is shown that the number of
   messages and the amount of data sent can be extremely big.  In
   addition to the very large traffic the document also analysis the
   affects of a large presence system on the memory footprint and the
   CPU load.  Current approved and in work optimizations to the SIMPLE
   protocol are analyzed with the possible impact on the load.  Other
   documents contain the requirements for optimizations [21] and
   suggestions for new optimizations are included in the following
   documents: [22].  [24]

   This document is intended to be drive work on possible solutions that
   will make the deployment of a presence server more reasonable task.
   Although a comparison to another protocol is given in the document,
   the intention of the document is not try to compare the SIP based
   presence protocol to other types of presence protocols but only to
   analyze the SIP based presence protocol.  It is very likely that that
   the scalability issues are inherent to the deployment of presence
   systems and not to a certain protocol.

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

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

   The term presence domain or presence system appears in the document



Houri, et al.             Expires May 21, 2008                  [Page 4]


Internet-Draft          Presence Scaling Analysis          November 2007


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


2.  Message Load

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

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

2.1.  Known Optimizations

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

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

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



Houri, et al.             Expires May 21, 2008                  [Page 5]


Internet-Draft          Presence Scaling Analysis          November 2007


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

2.2.  Assumptions

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

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

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

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

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

   Even though the assumptions in this document are not based on
   rigorous statistical data the target here is not to analyze specific
   system but show that even with VERY moderate assumptions (which are
   even less then the observations mentioned above), the number of
   messages, the network bandwidth, the required state management and
   the load on the CPU is very high.  Real life systems should have a
   much bigger scalability requirements. for example the presence state
   change that we assumed (one presence state change per hour) is maybe
   one of the most moderate assumptions that we have taken.  Experience
   from consumer networks show that the frequency here is much bigger



Houri, et al.             Expires May 21, 2008                  [Page 6]


Internet-Draft          Presence Scaling Analysis          November 2007


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

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

2.3.  Analysis

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

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

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

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

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

2.3.1.  Constants

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



Houri, et al.             Expires May 21, 2008                  [Page 7]


Internet-Draft          Presence Scaling Analysis          November 2007


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



Houri, et al.             Expires May 21, 2008                  [Page 8]


Internet-Draft          Presence Scaling Analysis          November 2007


   o  (C12) The size of NOTIFY when partial [15] notification is being
      done.  We have taken this size to be 200 bytes.  The size is much
      smaller then the example that is given in [15] but the example
      given there assumes multiple changes in the presence document and
      here we assume a single change.

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

2.3.2.  Initial Messages

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

   o  (I01) Number of initial SUBSCRIBE messages per watcher = C05.
   o  (I02) Number of initial 200 OK messages for SUBSCRIBE messages per
      watcher = C05.
   o  (I03) Number of initial NOTIFY messages per watcher = C05.
   o  (I04) Number of initial 200 OK messages for NOTIFY messages per
      watcher = C05.
   o  (I05) Total number and bytes of initial SUBSCRIBE messages for all
      watchers = Number - I01*C06, Bytes - I01*C06*C07.
   o  (I06) Total number and bytes of initial 200 OK for SUBSCRIBE
      messages for all watchers = Number - I01*C06, Bytes - I01*C06*C08.
   o  (I07) Total number and bytes of initial NOTIFY messages for all
      watchers = Number - I01*C06, The calculation for the number of
      bytes is different when dialog optimization is used or not.  When
      dialog optimization is not applied the number of bytes will be
      calculated by: (I01*C06*C09)+(I01*C06*C11) and when dialog
      optimization is applied the number of bytes will be calculated by
      (I01*C06*(C09+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.




Houri, et al.             Expires May 21, 2008                  [Page 9]


Internet-Draft          Presence Scaling Analysis          November 2007


2.3.3.  Steady State Messages

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

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



Houri, et al.             Expires May 21, 2008                 [Page 10]


Internet-Draft          Presence Scaling Analysis          November 2007


      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 of the subscriptions.  The calculations
   contain both number of messages and the number of bytes.

   o  (T01) Number of terminating SUBSCRIBE messages per watcher = C05.
   o  (T02) Number of terminating 200 OK messages for SUBSCRIBE messages
      per watcher = C05.
   o  (T03) Number of terminating NOTIFY messages per watcher = C05.
      Since when NOTIFY optimization is used [20] there is no need to
      send NOTIFY for terminations, T03 will be zero when NOTIFY
      optimization is used.
   o  (T04) Number of terminating 200 OK messages for NOTIFY messages
      per watcher = C05.  Since when NOTIFY optimization is used [20]
      there is no need to send NOTIFY for terminations, T04 will be zero
      when NOTIFY optimization is used.
   o  (T05) Total number and bytes of terminating SUBSCRIBE messages for
      all watchers = Number - T01*C06, Bytes - T01*C06*C07.
   o  (T06) Total number and bytes of terminating 200 OK for SUBSCRIBE
      messages for all watchers = Number - T01*C06, Bytes - T01*C06*C08.
   o  (T07) Total number and bytes of terminating NOTIFY messages for
      all watchers = Number - T01*C06, The number of bytes is calculated
      to be: (T03*C06*(C09+C11) when dialog optimization is not used
      and: (T03*C06*(C09+C11+C13+C14+C15) when dialog optimization is
      used.  Note that for dialog optimization it is assumed that only a
      single presentity is changed and partial state notification is
      used.
   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.



Houri, et al.             Expires May 21, 2008                 [Page 11]


Internet-Draft          Presence Scaling Analysis          November 2007


   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  (B02) Total number of message and bytes per user per day =
      Messages - number of messages in B01/C06 Bytes - Number of bytes
      in B01/C06.

2.3.6.  Rush Hour Calculations

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

2.4.  SIMPLE with no optimizations

   The following table uses some common presence characteristics to
   demonstrate the effect these factors have on state and message rate
   within a presence domain using base SIMPLE protocols without any
   proposed optimizations.  In this example, there are two presence
   domains with total of 40,000 federating users with an average of 4
   contacts in the peer domain.  Note that the main calculation is done
   for a presence document size of 350 bytes which is the base PIDF [6]
   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 folded
   calculation is done for every use case in this document.

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

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



Houri, et al.             Expires May 21, 2008                 [Page 12]


Internet-Draft          Presence Scaling Analysis          November 2007


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

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

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



Houri, et al.             Expires May 21, 2008                 [Page 13]


Internet-Draft          Presence Scaling Analysis          November 2007


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

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

                  Figure 1: SIMPLE with no optimizations

2.5.  SIMPLE with dialog optimization

   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



Houri, et al.             Expires May 21, 2008                 [Page 14]


Internet-Draft          Presence Scaling Analysis          November 2007


   (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....................130,400,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....................178,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.............7,040,000
             Bytes for all watchers..................5,871,360,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,246,000,000
   (S09) Total number & bytes of steady messages per day
             Number of msgs for all watchers.............8,160,000
             Bytes for all watchers..................7,117,360,000

   ** Termination Messages



Houri, et al.             Expires May 21, 2008                 [Page 15]


Internet-Draft          Presence Scaling Analysis          November 2007


   (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.....................51,920,000
   (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
             Number of msgs for all watchers................40,000
             Bytes for all watchers.....................14,800,000
   (T09) Total number & bytes of terminating messages per day
             Number of msgs for all watchers...............160,000
             Bytes for all watchers.....................99,520,000

   ** Bottom Line
   (B01) Total of messages between domains...............8,480,000
         Total of bytes between domains (PD=350).....7,394,880,000
         Total of bytes between domains (PD=3000)...20,220,880,000
   (B02) Total number of messages / second.....................294
         Total of bytes per second (PD=350)................256,767
         Total of bytes per second (PD=3000)...............702,114
   (B03) Total number of by msgs per user/day..................212
         Total number of bytes per user/day (PD=350).......184,872
         Total number of bytes per user/day (PD=3000)......505,522

                Figure 2: SIMPLE with Dialog optimizations

2.6.  SIMPLE with NOTIFY optimization

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

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



Houri, et al.             Expires May 21, 2008                 [Page 16]


Internet-Draft          Presence Scaling Analysis          November 2007


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

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

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



Houri, et al.             Expires May 21, 2008                 [Page 17]


Internet-Draft          Presence Scaling Analysis          November 2007


             Bytes for all watchers per day............918,400,000
   (S09) Total number & bytes of steady messages per day
             Number of msgs for all watchers.............9,280,000
             Bytes for all watchers..................5,212,800,000

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

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

                Figure 3: SIMPLE with NOTIFY optimizations

2.7.  SIMPLE with Dialog & NOTIFY optimizations

   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



Houri, et al.             Expires May 21, 2008                 [Page 18]


Internet-Draft          Presence Scaling Analysis          November 2007


   (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....................130,400,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....................178,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.............7,040,000
             Bytes for all watchers..................5,871,360,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



Houri, et al.             Expires May 21, 2008                 [Page 19]


Internet-Draft          Presence Scaling Analysis          November 2007


   (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,100,960,000

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

   ** Bottom Line
   (B01) Total of messages between domains...............7,840,000
         Total of bytes between domains (PD=350).....6,311,760,000
         Total of bytes between domains (PD=3000)...16,063,760,000
   (B02) Total number of messages / second.....................272
         Total of bytes per second (PD=350)................219,158
         Total of bytes per second (PD=3000)...............557,769
   (B03) Total number of by msgs per user/day..................196
         Total number of bytes per user/day (PD=350).......157,794
         Total number of bytes per user/day (PD=3000)......401,594

            Figure 4: SIMPLE with Dialog & NOTIFY optimizations

2.8.  Presence Federations

   While scalability issues exist in any large deployment, certain
   characteristics make the deployment conducive to the existing
   resource- list optimizations, and others have characteristics that



Houri, et al.             Expires May 21, 2008                 [Page 20]


Internet-Draft          Presence Scaling Analysis          November 2007


   cannot be exploited with the existing SIMPLE model.  Following is a
   list of federation relationships that have varying usage
   characteristics.  For each, a message rate and bandwidth table is
   provided reflecting typical changes message rates.  Those
   characteristics can alter the overall effectiveness of existing
   optimizations.

2.8.1.  Widely distributed inter-domain presence

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

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

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

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

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




Houri, et al.             Expires May 21, 2008                 [Page 21]


Internet-Draft          Presence Scaling Analysis          November 2007


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

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

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



Houri, et al.             Expires May 21, 2008                 [Page 22]


Internet-Draft          Presence Scaling Analysis          November 2007


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

   ** Bottom Line

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


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

      Figure 5: Widely distributed inter-domain with no optimizations


   ** Constants
   (C01) Subscription lifetime (hours)...........................8
   (C02) Presence state changes / hour...........................3
   (C03) Subscription refresh interval / hour....................1
   (C04) Total federated presentities per watcher...............20



Houri, et al.             Expires May 21, 2008                 [Page 23]


Internet-Draft          Presence Scaling Analysis          November 2007


   (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....................548,960,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....................596,560,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.................29,356,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



Houri, et al.             Expires May 21, 2008                 [Page 24]


Internet-Draft          Presence Scaling Analysis          November 2007


   (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.................29,586,400,000

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

   ** Bottom Line
   (B01) Total of messages between domains..............36,000,000
         Total of bytes between domains (PD=350)....30,215,760,000
         Total of bytes between domains (PD=3000)...78,975,760,000
   (B02) Total number of messages / second...................1,250
         Total of bytes per second (PD=350)..............1,049,158
         Total of bytes per second (PD=3000).............2,742,214
   B(03 )Total number of by msgs per user/day..................900
         Total number of bytes per user/day (PD=350).......755,394
         Total number of bytes per user/day (PD=3000)....1,974,394

       Figure 6: Widely distributed inter-domain with optimizations

2.8.2.  Associated inter-domain presence

   In this type of environment, the domain is a collection of associated
   users such as an enterprise.  Here, federation is once again very
   common.  However, there is also a strong association between some
   users in the deployment.  These associations make it somewhat more
   likely that users in that domain will be watchers of the same



Houri, et al.             Expires May 21, 2008                 [Page 25]


Internet-Draft          Presence Scaling Analysis          November 2007


   presentity.  This can occur because of business relationships (e.g.
   two co-workers on a project federating with a partner company).

   Common characteristics of this deployment are:

   o  Federated subscriptions are large minority or small majority of
      subscription traffic
   o  Individual users are likely to subscribe to multiple users in any
      one domain, especially their own
   o  The intersection of users in the deployment watching the same
      presentities increases

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

2.8.3.  Very large network peering

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

   Common characteristics of this deployment are:

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

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

   ** Constants
   (C01) Subscription lifetime (hours)...........................8
   (C02) Presence state changes / hour...........................6
   (C03) Subscription refresh interval / hour....................1
   (C04) Total federated presentities per watcher...............10



Houri, et al.             Expires May 21, 2008                 [Page 26]


Internet-Draft          Presence Scaling Analysis          November 2007


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

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

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



Houri, et al.             Expires May 21, 2008                 [Page 27]


Internet-Draft          Presence Scaling Analysis          November 2007


   (S09) Total number & bytes of steady messages per day
             Number of msgs for all watchers........24,000,000,000
             Bytes for all watchers.............14,080,000,000,000

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

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

        Figure 7: Very large network peering with no optimizations


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



Houri, et al.             Expires May 21, 2008                 [Page 28]


Internet-Draft          Presence Scaling Analysis          November 2007


   (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................143,680,000,000
   (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
             Number of msgs for all watchers............20,000,000
             Bytes for all watchers..................7,400,000,000
   (I09) Total number & bytes of initial messages per day
             Number of msgs for all watchers............80,000,000
             Bytes for all watchers................167,480,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.............15,345,600,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



Houri, et al.             Expires May 21, 2008                 [Page 29]


Internet-Draft          Presence Scaling Analysis          November 2007


             Number of msgs for all watchers........18,680,000,000
             Bytes for all watchers.............15,460,400,000,000

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

   ** Bottom Line
   (B01) Total of messages between domains..........18,800,000,000
         Total of bytes bet. domains (PD=350)...15,644,400,000,000
         Total of bytes bet. domains (PD=3000)..40,554,280,000,000
   (B02) Total number of messages / second.................652,778
         Total of bytes per second (PD=350)............543,208,333
         Total of bytes per second (PD=3000).........1,408,134,722
   (B03) Total number of by msgs per user/day..................940
         Total number of bytes per user/day (PD=350).......782,220
         Total number of bytes per user/day (PD=3000)....2,027,714


          Figure 8: Very large network peering with optimizations

2.8.4.  Intra-domain peering

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



Houri, et al.             Expires May 21, 2008                 [Page 30]


Internet-Draft          Presence Scaling Analysis          November 2007


   Common characteristics of this deployment are

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

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

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

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



Houri, et al.             Expires May 21, 2008                 [Page 31]


Internet-Draft          Presence Scaling Analysis          November 2007


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

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

   ** Bottom Line
   (B01) Total of messages between domains..............96,000,000
         Total of bytes between domains (PD=350)....54,240,000,000
         Total of bytes between domains (PD=3000)..152,820,000,000



Houri, et al.             Expires May 21, 2008                 [Page 32]


Internet-Draft          Presence Scaling Analysis          November 2007


   (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
   (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....................862,080,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,004,880,000

   ** Steady State Messages



Houri, et al.             Expires May 21, 2008                 [Page 33]


Internet-Draft          Presence Scaling Analysis          November 2007


   (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.................44,035,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.....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.................44,724,000,000

   ** Termination Messages
   (T01) Terminating SUBSCRIBE msgs per watcher..................1
   (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1
   (T03) Terminating NOTIFY msgs per watcher.....................1
   (T04) Terminating 200 OK msgs (NOTIFY) per watcher............1
   (T05) Total number & bytes of Terminating SUBSCRIBE msgs
             Number of msgs for all watchers...............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)....45,827,280,000
         Total of bytes between domains (PD=3000)..118,967,280,000
   (B02) Total number of messages / second...................1,917



Houri, et al.             Expires May 21, 2008                 [Page 34]


Internet-Draft          Presence Scaling Analysis          November 2007


         Total of bytes per second (PD=350)..............1,591,225
         Total of bytes per second (PD=3000).............4,130,808
   (B03) Total number of by msgs per user/day..................460
         Total number of bytes per user/day (PD=350).......381,894
         Total number of bytes per user/day (PD=3000)......991,394

            Figure 10: Intra-domain peering with optimizations

2.9.  Partial Notifications Optimization

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

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

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



Houri, et al.             Expires May 21, 2008                 [Page 35]


Internet-Draft          Presence Scaling Analysis          November 2007


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

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

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



Houri, et al.             Expires May 21, 2008                 [Page 36]


Internet-Draft          Presence Scaling Analysis          November 2007


             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: Very large networks peering with NOTIFY and partial
                               optimizations

2.10.  Other Protocols

   In SIP there are several differences from other protocols of presence
   as XMPP [7] and the proprietary protocols of the consumer domains.
   The differences are:

   o  There is no 200 OK for each message.  These protocols support only
      TCP and they do not compensate for network issues.
   o  There is no refresh for subscription.
   o  There is no NOTIFY upon termination of SUBSCRIPTION
   o  The size of each message of these protocol is smaller since they
      are either binary and/or there is no need for the various headers
      that SIP uses for routing etc.  So we need to assume smaller
      message sizes while we will keep the size of the presence document
      the same.

   The following is an analysis of the very large networks peering
   assuming all the changes in other protocols with respect to SIP.

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



Houri, et al.             Expires May 21, 2008                 [Page 37]


Internet-Draft          Presence Scaling Analysis          November 2007


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

   ** Steady State Messages
   (S01) NOTIFY msgs due to state change
             per watched presentity per day.....................46
   (S02) 200 (for NOTIFY due to state change) msgs
             per watched presentity per day......................0
   (S03) Total number and size of msgs due to state change per day
             Number of msgs for all watchers.........9,200,000,000
             Bytes for all watchers..............4,600,000,000,000
   (S04) Number of SUBSCRIBE msgs for refreshes
             per watcher per day.................................0
   (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
             per watcher per day.................................0
   (S06) Number of NOTIFY msgs for refreshes
             per watcher per day.................................0
   (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
             per watcher per day.................................0
   (S08) Total number and size of msgs due to SUBSCRIBE refreshes
             Number of msgs for all watchers per day.............0
             Bytes for all watchers per day......................0
   (S09) Total number & bytes of steady messages per day
             Number of msgs for all watchers.........9,200,480,000
             Bytes for all watchers..............4,600,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



Houri, et al.             Expires May 21, 2008                 [Page 38]


Internet-Draft          Presence Scaling Analysis          November 2007


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

   ** Bottom Line
   (B01) Total of messages between domains...........9,800,000,000
         Total of bytes between domains (PD=50)..1,940,000,000,000
         Total of bytes between domains (PD=350).4,760,000,000,000
         Total of bytes bet. domains (PD=3000)..29,670,000,000,000
   (B02) Total number of messages / second.................340,278
         Total of bytes per second (PD=50)..............67,361,111
         Total of bytes per second (PD=350)............165,277,778
         Total of bytes per second (PD=3000).........1,030,208,333
   (B03) Total number of by msgs per user/day..................490
         Total number of bytes per user/day (PD=50).........97,000
         Total number of bytes per user/day (PD=350).......238,000
         Total number of bytes per user/day (PD=3000)....1,483,500

         Figure 12: Very large networks peering in other protocols


3.  State Management

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

   The presence server has two parallel tasks.

   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.




Houri, et al.             Expires May 21, 2008                 [Page 39]


Internet-Draft          Presence Scaling Analysis          November 2007


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

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

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

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

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

3.1.  State Size Calculations

   Lets assume the following sizes:

   o  Subscription size - 2K bytes.  This includes watcher information
      that need to be created by the presence server for each
      subscription.
   o  Subscribed to resource - 1K bytes (for privacy information and
      other management info).  The subscriptions themselves are already
      calculated in the previous bullet.
   o  Resource with a state - 6K bytes.  This is a moderate assumption
      if we take into account the amount of data that is being put in a
      presence document as multiple devices, calendar and geographical
      information.

3.1.1.  Tiny System

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





Houri, et al.             Expires May 21, 2008                 [Page 40]


Internet-Draft          Presence Scaling Analysis          November 2007


   o  10K presentities with state = 58M bytes.

   Total is 82M bytes.

3.1.2.  Medium System

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

   Total is 830M bytes.

3.1.3.  Large System

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

   Total is 38G bytes.

3.1.4.  Very Large System

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

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

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

   o  Dynamic state - Although the state may seem not so big for
      databases even for the very large system, we need to remember that
      this state is a very dynamic state.  Subscriptions come and go all
      the time, the status of presentities is being updated and so
      forth.  This means that the presence server has to manage its
      state in a medium that is very dynamic and for such large sizes
      this task is not trivial.
   o  Interlinked state - The subscriptions and the subscribed to
      presentities are dependent on each other.  There needs to be a
      link from the presentity to the subscriptions and vice versa.  See
      Section 4.5 about the interlinkage that is created due to resource
      lists.
   o  Moderate assumptions - The size assumptions that were made above
      are quite moderate.  As presence is becoming more a core
      middleware functionality that holds a lot of data on the user.  In



Houri, et al.             Expires May 21, 2008                 [Page 41]


Internet-Draft          Presence Scaling Analysis          November 2007


      real-life the numbers above may be even higher and the presence
      server can have additional overhead as managing the SIP sessions,
      networking and more.

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


4.  Processing complexities

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

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

4.1.  Aggregation

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

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

4.2.  Partial Publish and Notify

   Drafts [15], [16] define a way for the watcher to request getting
   only what was changed in the presence document and for the publisher
   of presence information to publish only what was changed in the
   presence document since the last publish.  Although these



Houri, et al.             Expires May 21, 2008                 [Page 42]


Internet-Draft          Presence Scaling Analysis          November 2007


   optimizations help in reducing the amount of the data that is sent
   from/to the presence server, these optimizations create additional
   processing burden on the presence server.

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

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

4.3.  Filtering

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

4.4.  Authorization

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

4.5.  Resource List Service

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

   The reasons that resource lists may make the scalability problem of



Houri, et al.             Expires May 21, 2008                 [Page 43]


Internet-Draft          Presence Scaling Analysis          November 2007


   the presence server even more complex are:

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

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



Houri, et al.             Expires May 21, 2008                 [Page 44]


Internet-Draft          Presence Scaling Analysis          November 2007


   when an optimization is introduced it does not create issues in other
   places.


5.  Current Optimizations

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

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





Houri, et al.             Expires May 21, 2008                 [Page 45]


Internet-Draft          Presence Scaling Analysis          November 2007


   o  Throttling [23] defines a mechanism in which a watcher requires to
      be updated only in certain intervals.  Although this mechanism may
      give some extra load on the processing time of the presence
      server, that load is negligible and the reduction on the amount of
      messages sent from the presence server to the watchers is
      significant.  This optimization is even more important with
      resource lists where there can be many resources in the resource
      lists and if the traffic of updates on resource list is not
      regulated, the watcher may get very large amount of notifications.
   o  Presence specific sigcomp dictionary [18] defines a SIGCOMP [3]
      dictionary for presence.  This optimization will enable to reduce
      the number of bytes that are transferred in presence systems by
      compressing the textual SIP messages and using the specialized
      presence dictionary the compression may be more significant then
      just using SIGCOMP as is.  Note that number of actual messages
      will remain the same and a calculation of the amount of bytes that
      will be saved may be useful here.
   o  Content Indirection [9] enables sending only the URI of the
      presence document to the watcher thus offloading the presence
      server from sending the presence document to the watcher.  This
      optimization may be useful in some cases especially where there is
      a big number of users that get the same presence document.


6.  Summary

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

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



















Houri, et al.             Expires May 21, 2008                 [Page 46]


Internet-Draft          Presence Scaling Analysis          November 2007


   (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 13: Constants in ALL calculations

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

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

   No optimizations are applied

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

   Dialog optimization is applied

   B01 Total of messages between domains.................8,480,000
     Total of bytes between domains (PD=350).........7,394,880,000
     Total of bytes between domains (PD=3000).......20,220,880,000
   B02 Total number of messages / second.......................294
     Total of bytes per second (PD=350)....................256,767
     Total of bytes per second (PD=3000)...................702,114
   B03 Total number of by msgs per user/day....................212
     Total number of bytes per user/day (PD=350)...........184,872
     Total number of bytes per user/day (PD=3000)..........505,522



Houri, et al.             Expires May 21, 2008                 [Page 47]


Internet-Draft          Presence Scaling Analysis          November 2007


   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,311,760,000
     Total of bytes between domains (PD=3000).......16,063,760,000
   B02 Total number of messages / second.......................272
     Total of bytes per second (PD=350)....................219,158
     Total of bytes per second (PD=3000)...................557,769
   B03 Total number of by msgs per user/day....................196
     Total number of bytes per user/day (PD=350)...........157,794
     Total number of bytes per user/day (PD=3000)..........401,594

                         Figure 14: 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 May 21, 2008                 [Page 48]


Internet-Draft          Presence Scaling Analysis          November 2007


   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)........2,547,000

   Dialog and notify optimizations are applied

   B01 Total of messages between domains................36,000,000
     Total of bytes between domains (PD=350)........30,215,760,000
     Total of bytes between domains (PD=3000).......78,975,760,000
   B02 Total number of messages / second.....................1,250
     Total of bytes per second (PD=350)..................1,049,158
     Total of bytes per second (PD=3000).................2,742,214
   B03 Total number of by msgs per user/day....................900
     Total number of bytes per user/day (PD=350)...........755,394
     Total number of bytes per user/day (PD=3000)........1,974,394

                Figure 15: 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 May 21, 2008                 [Page 49]


Internet-Draft          Presence Scaling Analysis          November 2007


   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)........45,827,280,000
     Total of bytes between domains (PD=3000)......118,967,280,000
   B02 Total number of messages / second.....................1,917
     Total of bytes per second (PD=350)..................1,591,225
     Total of bytes per second (PD=3000).................4,130,808
   B03 Total number of by msgs per user/day....................460
     Total number of bytes per user/day (PD=350)...........381,894
     Total number of bytes per user/day (PD=3000)..........991,394

                      Figure 16: Inter-domain peering

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

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

   No optimizations are applied

   B01 Total of messages between domains............25,600,000,000
     Total of bytes between domains (PD=350)....14,896,000,000,000
     Total of bytes between 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 May 21, 2008                 [Page 50]


Internet-Draft          Presence Scaling Analysis          November 2007


   Dialog and notify optimizations are applied

   B01 Total of messages between domains............18,800,000,000
     Total of bytes between domains (PD=350)....15,644,400,000,000
     Total of bytes between domains (PD=3000)...40,554,280,000,000
   B02 Total number of messages / second...................652,778
     Total of bytes per second (PD=350)................543,208,333
     Total of bytes per second (PD=3000).............1,408,134,722
   B03 Total number of by msgs per user/day....................940
     Total number of bytes per user/day (PD=350)...........782,220
     Total number of bytes per user/day (PD=3000)........2,027,714

   Partial and notify optimizations are applied

   B01 Total of messages between domains............22,400,000,000
     Total of bytes between domains (PD=350)....11,564,000,000,000
     Total of bytes between 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

   Calculation for other protocols

   B01 Total of messages between domains.............9,800,000,000
     Total of bytes between domains (PD=50)......1,940,000,000,000
     Total of bytes between domains (PD=350).....4,760,000,000,000
     Total of bytes between domains (PD=3000)...29,670,000,000,000
   B02 Total number of messages / second...................340,278
     Total of bytes per second (PD=50)..................67,361,111
     Total of bytes per second (PD=350)................165,277,778
     Total of bytes per second (PD=3000).............1,030,208,333
   B03 Total number of by msgs per user/day....................490
     Total number of bytes per user/day (PD=50).............97,000
     Total number of bytes per user/day (PD=350)...........238,000
     Total number of bytes per user/day (PD=3000)........1,483,500


               Figure 17: Very large scale peering networks


7.  Conclusions

   The following conclusions can be drawn from the above numbers:





Houri, et al.             Expires May 21, 2008                 [Page 51]


Internet-Draft          Presence Scaling Analysis          November 2007


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

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

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

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

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




Houri, et al.             Expires May 21, 2008                 [Page 52]


Internet-Draft          Presence Scaling Analysis          November 2007


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

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

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

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


8.  Security Considerations

   This document discusses scalability issues with the existing SIP/
   SIMPLE presence protocol and model.  Therefore, there are no security
   considerations to be considered for this document.  However, a lot of
   the possible optimizations that should emerge as a result of this
   document will have security implications that will need to be solved.




Houri, et al.             Expires May 21, 2008                 [Page 53]


Internet-Draft          Presence Scaling Analysis          November 2007


9.  Changes from Previous Versions

9.1.  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

9.2.  Changes in version 02

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

9.3.  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 [21]
   o  The new suggestions for optimizations were moved to [22]


10.  Acknowledgments

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


11.  References



Houri, et al.             Expires May 21, 2008                 [Page 54]


Internet-Draft          Presence Scaling Analysis          November 2007


11.1.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

11.2.  Informational References

   [2]   Roach, A., "Session Initiation Protocol (SIP)-Specific Event
         Notification", RFC 3265, June 2002.

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

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

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

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

   [7]   Saint-Andre, P., "End-to-End Signing and Object Encryption for
         the Extensible Messaging and Presence Protocol (XMPP)",
         RFC 3923, October 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]   Burger, E., "A Mechanism for Content Indirection in Session
         Initiation Protocol (SIP) Messages", RFC 4483, May 2006.

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

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

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




Houri, et al.             Expires May 21, 2008                 [Page 55]


Internet-Draft          Presence Scaling Analysis          November 2007


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

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

   [15]  Lonnfors, M., "Session Initiation Protocol (SIP) extension for
         Partial Notification of  Presence Information",
         draft-ietf-simple-partial-notify-09 (work in progress),
         February 2007.

   [16]  Lonnfors, M., "Publication of Partial Presence Information",
         draft-ietf-simple-partial-publish-06 (work in progress),
         February 2007.

   [17]  Rosenberg, J., "Presence Authorization Rules",
         draft-ietf-simple-presence-rules-10 (work in progress),
         July 2007.

   [18]  Garcia-Martin, M., "The Presence-Specific Static Dictionary for
         Signaling Compression  (Sigcomp)",
         draft-garcia-simple-presence-dictionary-06 (work in progress),
         August 2007.

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

   [20]  Niemi, A., "An Extension to Session Initiation Protocol (SIP)
         Events for Conditional  Event Notification",
         draft-ietf-sip-subnot-etags-01 (work in progress), August 2007.

   [21]  Houri, A., "Scaling Requirements for Presence in SIP/SIMPLE",
         draft-houri-sipping-presence-scaling-requirements-01 (work in
         progress), November 2007.

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

   [23]  Niemi, A., "Session Initiation Protocol (SIP) Event
         Notification Extension for  Notification Throttling",
         draft-niemi-sipping-event-throttle-05 (work in progress),
         March 2007.

   [24]  Rosenberg, J., Donovan, S., and K. McMurry, "Optimizing



Houri, et al.             Expires May 21, 2008                 [Page 56]


Internet-Draft          Presence Scaling Analysis          November 2007


         Federated Presence with View Sharing",
         draft-rosenberg-simple-view-sharing-00 (work in progress),
         November 2007.

   [25]  Rosenberg, J., "Models for Intra-Domain Presence Federation",
         draft-rosenberg-simple-intradomain-federation-00 (work in
         progress), November 2007.


Authors' Addresses

   Avshalom Houri
   IBM
   Science Park  Building 18/D
   Rehovot,
   Israel

   Email: avshalom@il.ibm.com


   Edwin Aoki
   AOL LLC
   360 W. Caribbean  Drive
   Sunnyvale, CA  94089
   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






Houri, et al.             Expires May 21, 2008                 [Page 57]


Internet-Draft          Presence Scaling Analysis          November 2007


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

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


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

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






























Houri, et al.             Expires May 21, 2008                 [Page 58]


Internet-Draft          Presence Scaling Analysis          November 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

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

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


Intellectual Property

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

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

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


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Houri, et al.             Expires May 21, 2008                 [Page 59]