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

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


          Presence Interdomain Scaling Analysis for SIP/SIMPLE
         draft-ietf-simple-interdomain-scaling-analysis-02.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 January 25, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   The document analyses the traffic that is generated due to presence
   subscriptions between domains.  It is shown that the amount of



Houri, et al.           Expires January 25, 2008                [Page 1]


Internet-Draft          Presence Scaling Analysis              July 2007


   traffic can be extremely big.  In addition to the very large traffic
   the document also analyses the affects of a large presence system on
   the memory footprint and the CPU load.  Current approved and in work
   optimizations to the SIMPLE protocol are analysed with the possible
   impact on the load.  Separate documents contain the requirements for
   optimizations and suggestions for new optimizations.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Message Load . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Known Optimizations  . . . . . . . . . . . . . . . . . . .  5
     2.2.  Assumptions  . . . . . . . . . . . . . . . . . . . . . . .  5
     2.3.  Analysis . . . . . . . . . . . . . . . . . . . . . . . . .  6
       2.3.1.  Constants  . . . . . . . . . . . . . . . . . . . . . .  7
       2.3.2.  Initial Messages . . . . . . . . . . . . . . . . . . .  8
       2.3.3.  Steady State Messages  . . . . . . . . . . . . . . . .  9
       2.3.4.  Termination Messages . . . . . . . . . . . . . . . . . 10
       2.3.5.  Bottom Line  . . . . . . . . . . . . . . . . . . . . . 10
       2.3.6.  Rush Hour Calculations . . . . . . . . . . . . . . . . 10
     2.4.  SIMPLE with no optimizations . . . . . . . . . . . . . . . 11
     2.5.  SIMPLE with dialog optimization  . . . . . . . . . . . . . 13
     2.6.  SIMPLE with NOTIFY optimization  . . . . . . . . . . . . . 15
     2.7.  SIMPLE with Dialog & NOTIFY optimizations  . . . . . . . . 17
     2.8.  Presence Federations . . . . . . . . . . . . . . . . . . . 19
       2.8.1.  Widely distributed inter-domain presence . . . . . . . 19
       2.8.2.  Associated inter-domain presence . . . . . . . . . . . 23
       2.8.3.  Very large network peering . . . . . . . . . . . . . . 24
       2.8.4.  Intra-domain peering . . . . . . . . . . . . . . . . . 28
     2.9.  Partial Notifications Optimization . . . . . . . . . . . . 32
     2.10. Other Protocols  . . . . . . . . . . . . . . . . . . . . . 34
   3.  State Management . . . . . . . . . . . . . . . . . . . . . . . 37
     3.1.  State Size Calculations  . . . . . . . . . . . . . . . . . 38
       3.1.1.  Tiny System  . . . . . . . . . . . . . . . . . . . . . 38
       3.1.2.  Medium System  . . . . . . . . . . . . . . . . . . . . 38
       3.1.3.  Large System . . . . . . . . . . . . . . . . . . . . . 38
       3.1.4.  Very Large System  . . . . . . . . . . . . . . . . . . 38
   4.  Processing complexities  . . . . . . . . . . . . . . . . . . . 39
     4.1.  Aggregation  . . . . . . . . . . . . . . . . . . . . . . . 40
     4.2.  Partial Publish and Notify . . . . . . . . . . . . . . . . 40
     4.3.  Filtering  . . . . . . . . . . . . . . . . . . . . . . . . 40
     4.4.  Authorization  . . . . . . . . . . . . . . . . . . . . . . 41
     4.5.  Resource List Service  . . . . . . . . . . . . . . . . . . 41
   5.  Current Optimizations  . . . . . . . . . . . . . . . . . . . . 42
   6.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 43
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 44
   8.  Changes from Previous Versions . . . . . . . . . . . . . . . . 45



Houri, et al.           Expires January 25, 2008                [Page 2]


Internet-Draft          Presence Scaling Analysis              July 2007


     8.1.  Changes in version 02  . . . . . . . . . . . . . . . . . . 45
     8.2.  Changes in version 01  . . . . . . . . . . . . . . . . . . 45
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 45
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 45
     10.2. Informational References . . . . . . . . . . . . . . . . . 45
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
   Intellectual Property and Copyright Statements . . . . . . . . . . 49











































Houri, et al.           Expires January 25, 2008                [Page 3]


Internet-Draft          Presence Scaling Analysis              July 2007


1.  Introduction

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

   This document is intended to be used by the SIMPLE WG in order to
   work on possible solutions that will make the deployment of a
   presence server more reasonable task.  Note that the document does
   not try to compare the SIP based presence server to other types of
   presence servers but only analyses the SIP based presence server.  It
   is very likely that similar scalability issues are inherent to the
   deployment of presence systems and not to a certain protocol.

   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 [10] 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
   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



Houri, et al.           Expires January 25, 2008                [Page 4]


Internet-Draft          Presence Scaling Analysis              July 2007


   enterprise or in a very large consumer network.


2.  Message Load

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

   Note that even though this document talks about inter domain traffic,
   the introduction of resource list servers (RLSs) [10] introduce very
   similar traffic pattern within a domain as between domains.  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 [10] or to the Uri list subscriptions draft
      [15].  These documents define ways to reduce the number of dialogs
      that are required between the subscriber and the presence system.
   o  Notification optimizations - Here we refer to the optimizations
      that are suggested in the subnot-etags draft [16].  This draft
      suggests ways to suppress the sending of unnecessary notifies when
      for example a subscription is refreshed.  There are other drafts
      that reduce the size of messages as partial notifies or filtering
      but in this document we mostly care about the amount of messages &
      bandwidth so the partial optimizations can help a bit in the
      bandwidth but will not help in the number of messages.

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 messages but more from experience on
   other types of presence based systems.

   Even though the assumptions in this document are not based on
   rigorous statistical data the target here is not to analyse specific
   system but show that even with VERY moderate assumptions, the number
   of messages, the network bandwidth, the required state management and



Houri, et al.           Expires January 25, 2008                [Page 5]


Internet-Draft          Presence Scaling Analysis              July 2007


   the load on the CPU is very high.  Real life systems should have a
   much bigger scalability requirements. for example the presence state
   change that we assumed (one presence state change per hour) is maybe
   one of the most moderate assumptions that we have taken.  Experience
   from consumer networks show that the frequency here is much bigger
   and especially with the younger generation.  In an environment where
   a user may have several devices and other resources for presence
   information as geographical location and calendar the frequency of
   presence state changes will be much higher.

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

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

   o  Get rigorous statistical data that can be formally published from
      real presence systems.
   o  Add to the model the possibility of having multiple sources of
      presence data per presentity and change calculations accordingly
   o  Add "rush hour" calculations for the end and the beginning of the
      day

   The authors will especially appreciate any input in this area that
   will help us to create a more real life model.  We intend to try and
   gather more data and improve the assumptions and the model in the
   next revisions of this document.

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





Houri, et al.           Expires January 25, 2008                [Page 6]


Internet-Draft          Presence Scaling Analysis              July 2007


   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

   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.



Houri, et al.           Expires January 25, 2008                [Page 7]


Internet-Draft          Presence Scaling Analysis              July 2007


   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.  The size is assumed
      to be 3000 bytes based on sizes from examples in RFCs.  Note that
      assuming 3000 bytes for presence document is relatively modest if
      we take into account multiple devices and location information.
      When there will be multiple presentities in the same NOTIFY as in
      the initial NOTIFY for a resource list [10] or there is less
      information in the presence document due to partial notifications
      these factors will be taken into account.

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, Bytes - (I03*C06*C09)+((C04/
      C05)*C11).  The calculation of the size is a bit complicates since
      it takes into account the case where the optimization of resource
      lists is used and there is a single NOTIFY with all the
      presentities for the single subscription.
   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 January 25, 2008                [Page 8]


Internet-Draft          Presence Scaling Analysis              July 2007


2.3.3.  Steady State Messages

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

   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, Bytes - ((S01*C06*C04*(C09+C11))
      + (S02*C06* C04*C10)).
   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.
   o  (S07) Number of 200 OK messages for NOTIFY messages for refreshes
      per watcher per day = ((C01/C03)-1)*C05.
   o  (S08) Total number and size of messages due to SUBSCRIBE refreshes
      per day = Number - (S04+S05+S06+S07)*C06, Size - SUBSCIRBE bytes
      (S04*C06*C07) + OK for SUBSCRIBE bytes (S05*C06*C08) + NOTIFY
      bytes (S06*C06*(C09+((C04/C05)*C11))) + OK for NOTIFY
      (S07*C06*C08).  The calculation of the size is a bit complicates
      since it takes into account the case where the optimization of
      resource lists is used and there is a single NOTIFY with all the
      presentities for the single subscription.  Note that a full state
      should be given in SUBSCRIBE refreshes in resource lists.  See
      section 4.5 in [10].  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.







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


Internet-Draft          Presence Scaling Analysis              July 2007


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.
   o  (T04) Number of terminating 200 OK messages for NOTIFY messages
      per watcher = C05.
   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, Bytes - (T03*C06*(C09+C11).  It
      is assumed that there will be a single presence document in the
      terminating NOTIFY.
   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 the total number of messages
   and bytes per day and per second that will be sent on the link
   between the federating domains.

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

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.




Houri, et al.           Expires January 25, 2008               [Page 10]


Internet-Draft          Presence Scaling Analysis              July 2007


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

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

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

   ** Steady State Messages
   (S01) NOTIFY msgs due to state change
             per watched presentity per day.....................22
   (S02) 200 (for NOTIFY due to state change) msgs
             per watched presentity per day.....................22



Houri, et al.           Expires January 25, 2008               [Page 11]


Internet-Draft          Presence Scaling Analysis              July 2007


   (S03) Total number and size of msgs due to state change per day
             Number of msgs for all watchers.............7,040,000
             Bytes for all watchers.................13,622,400,000
   (S04) Number of SUBSCRIBE msgs for refreshes
             per watcher per day................................28
   (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
             per watcher per day................................28
   (S06) Number of NOTIFY msgs for refreshes
             per watcher per day................................28
   (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
             per watcher per day................................28
   (S08) Total number and size of msgs due to SUBSCRIBE refreshes
             Number of msgs for all watchers per day.....4,480,000
             Bytes for all watchers per day..........5,252,800,000
   (S09) Total number & bytes of steady messages per day
             Number of msgs for all watchers............11,520,000
             Bytes for all watchers.................18,875,200,000

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

   ** Bottom Line
   (B01) Total number of message & bytes during the day
             Number of msgs.............................12,800,000
             Bytes..................................20,376,000,000
   (B02) Total number of message & bytes per second
             Number of msgs....................................444
             Bytes.........................................707,500

                  Figure 1: SIMPLE with no optimizations



Houri, et al.           Expires January 25, 2008               [Page 12]


Internet-Draft          Presence Scaling Analysis              July 2007


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................3,000

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

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



Houri, et al.           Expires January 25, 2008               [Page 13]


Internet-Draft          Presence Scaling Analysis              July 2007


             Bytes for all watchers.................13,622,400,000
   (S04) Number of SUBSCRIBE msgs for refreshes
             per watcher per day.................................7
   (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
             per watcher per day.................................7
   (S06) Number of NOTIFY msgs for refreshes
             per watcher per day.................................7
   (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
             per watcher per day.................................7
   (S08) Total number and size of msgs due to SUBSCRIBE refreshes
             Number of msgs for all watchers per day.....1,120,000
             Bytes for all watchers per day..........3,833,200,000
   (S09) Total number & bytes of steady messages per day
             Number of msgs for all watchers.............8,160,000
             Bytes for all watchers.................17,455,600,000

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

   ** Bottom Line
   (B01) Total number of message & bytes during the day
             Number of msgs..............................8,480,000
             Bytes..................................18,190,800,000
   (B02) Total number of message & bytes per second
             Number of msgs....................................294
             Bytes.........................................631,625

                Figure 2: SIMPLE with Dialog optimizations





Houri, et al.           Expires January 25, 2008               [Page 14]


Internet-Draft          Presence Scaling Analysis              July 2007


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.  As should be expected this optimization affects the
   steady state and does not affect the initial and termination
   messages.

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

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

   ** Steady State Messages
   (S01) NOTIFY msgs due to state change
             per watched presentity per day.....................22



Houri, et al.           Expires January 25, 2008               [Page 15]


Internet-Draft          Presence Scaling Analysis              July 2007


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

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

   ** Bottom Line
   (B01) Total number of message & bytes during the day
             Number of msgs.............................10,560,000
             Bytes..................................16,041,600,000
   (B02) Total number of message & bytes per second
             Number of msgs....................................367
             Bytes.........................................557,000



Houri, et al.           Expires January 25, 2008               [Page 16]


Internet-Draft          Presence Scaling Analysis              July 2007


                Figure 3: SIMPLE with NOTIFY optimizations

2.7.  SIMPLE with Dialog & NOTIFY optimizations

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

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

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

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



Houri, et al.           Expires January 25, 2008               [Page 17]


Internet-Draft          Presence Scaling Analysis              July 2007


             Number of msgs for all watchers.............7,040,000
             Bytes for all watchers.................13,622,400,000
   (S04) Number of SUBSCRIBE msgs for refreshes
             per watcher per day.................................7
   (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
             per watcher per day.................................7
   (S06) Number of NOTIFY msgs for refreshes
             per watcher per day.................................0
   (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
             per watcher per day.................................0
   (S08) Total number and size of msgs due to SUBSCRIBE refreshes
             Number of msgs for all watchers per day.......560,000
             Bytes for all watchers per day............229,600,000
   (S09) Total number & bytes of steady messages per day
             Number of msgs for all watchers.............7,600,000
             Bytes for all watchers.................13,852,000,000

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

   ** Bottom Line
   (B01) Total number of message & bytes during the day
             Number of msgs..............................7,920,000
             Bytes..................................14,587,200,000
   (B02) Total number of message & bytes per second
             Number of msgs....................................275
             Bytes.........................................506,500

            Figure 4: SIMPLE with Dialog & NOTIFY optimizations




Houri, et al.           Expires January 25, 2008               [Page 18]


Internet-Draft          Presence Scaling Analysis              July 2007


2.8.  Presence Federations

   While these scalability issues exist in any large deployment, certain
   characteristics make the deployment conducive to the existing
   resource- list optimizations, and others have characteristics that
   cannot be exploited with the existing SIMPLE model.  Following is a
   list of federation relationships that have varying usage
   characteristics.  For each, a message rate and bandwidth table is
   provided reflecting typical changes message rates.  Those
   characteristics can alter the overall effectiveness of existing
   optimizations.

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.  Note
   that the number of messages per second decreases by a quarter with
   the optimizations but it is still quite big.  It is interesting to
   see that the bandwidth is almost the quarter of the bandwidth when
   optimizations are applied.

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



Houri, et al.           Expires January 25, 2008               [Page 19]


Internet-Draft          Presence Scaling Analysis              July 2007


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

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

   ** Steady State Messages
   (S01) NOTIFY msgs due to state change
             per watched presentity per day.....................22
   (S02) 200 (for NOTIFY due to state change) msgs
             per watched presentity per day.....................22
   (S03) Total number and size of msgs due to state change per day
             Number of msgs for all watchers............35,200,000
             Bytes for all watchers.................68,112,000,000
   (S04) Number of SUBSCRIBE msgs for refreshes
             per watcher per day...............................140
   (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
             per watcher per day...............................140
   (S06) Number of NOTIFY msgs for refreshes
             per watcher per day...............................140
   (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
             per watcher per day...............................140
   (S08) Total number and size of msgs due to SUBSCRIBE refreshes
             Number of msgs for all watchers per day....22,400,000



Houri, et al.           Expires January 25, 2008               [Page 20]


Internet-Draft          Presence Scaling Analysis              July 2007


             Bytes for all watchers per day.........26,264,000,000
   (S09) Total number & bytes of steady messages per day
             Number of msgs for all watchers............57,600,000
             Bytes for all watchers.................94,376,000,000

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

   ** Bottom Line
   (B01) Total number of message & bytes during the day
             Number of msgs.............................65,000,000
             Bytes.................................101,880,000,000
   (B02) Total number of message & bytes per second
             Number of msgs..................................2,222
             Bytes.......................................3,537,500

      Figure 5: Widely distributed inter-domain with no optimizations


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



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


Internet-Draft          Presence Scaling Analysis              July 2007


   (C11) Size of an average presence document................3,000

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

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

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



Houri, et al.           Expires January 25, 2008               [Page 22]


Internet-Draft          Presence Scaling Analysis              July 2007


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

   ** Bottom Line
   (B01) Total number of message & bytes during the day
             Number of msgs.............................36,080,000
             Bytes..................................70,996,800,000
   (B02) Total number of message & bytes per second
             Number of msgs..................................1,253
             Bytes.......................................2,465,167

       Figure 6: Widely distributed inter-domain with optimizations

2.8.2.  Associated inter-domain presence

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

   Common characteristics of this deployment are:

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




Houri, et al.           Expires January 25, 2008               [Page 23]


Internet-Draft          Presence Scaling Analysis              July 2007


   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 (almost 1GB per second).

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

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



Houri, et al.           Expires January 25, 2008               [Page 24]


Internet-Draft          Presence Scaling Analysis              July 2007


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

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

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



Houri, et al.           Expires January 25, 2008               [Page 25]


Internet-Draft          Presence Scaling Analysis              July 2007


   (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers...........200,000,000
             Bytes for all watchers.................74,000,000,000
   (T07) Total number & bytes of terminating NOTIFY msgs
             Number of msgs for all watchers...........200,000,000
             Bytes for all watchers................700,000,000,000
   (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
             Number of msgs for all watchers...........200,000,000
             Bytes for all watchers.................74,000,000,000
   (T09) Total number & bytes of terminating messages per day
             Number of msgs for all watchers...........800,000,000
             Bytes for all watchers................938,002,000,000

   ** Bottom Line
   (B01) Total number of message & bytes during the day
             Number of msgs.........................25,600,000,000
             Bytes..............................44,046,000,000,000
   (B02) Total number of message & bytes per second
             Number of msgs................................888,889
             Bytes...................................1,529,375,333

        Figure 7: Very large network peering with no optimizations


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

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



Houri, et al.           Expires January 25, 2008               [Page 26]


Internet-Draft          Presence Scaling Analysis              July 2007


   (I07) Total number & bytes of initial NOTIFY msgs
             Number of msgs for all watchers............20,000,000
             Bytes for all watchers................610,000,000,000
   (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
             Number of msgs for all watchers............20,000,000
             Bytes for all watchers..................7,400,000,000
   (I09) Total number & bytes of initial messages per day
             Number of msgs for all watchers............80,000,000
             Bytes for all watchers................663,800,000,000

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

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



Houri, et al.           Expires January 25, 2008               [Page 27]


Internet-Draft          Presence Scaling Analysis              July 2007


             Number of msgs for all watchers............20,000,000
             Bytes for all watchers..................7,400,000,000
   (T09) Total number & bytes of terminating messages per day
             Number of msgs for all watchers............80,000,000
             Bytes for all watchers.................93,800,000,000

   ** Bottom Line
   (B01) Total number of message & bytes during the day
             Number of msgs.........................18,840,000,000
             Bytes..............................36,446,400,000,000
   (B02) Total number of message & bytes per second
             Number of msgs................................654,167
             Bytes...................................1,265,500,000

          Figure 8: Very large network peering with optimizations

2.8.4.  Intra-domain peering

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

   Common characteristics of this deployment are

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



Houri, et al.           Expires January 25, 2008               [Page 28]


Internet-Draft          Presence Scaling Analysis              July 2007


   (C06) Total number of watchers in domains...............120,000
   (C07) SUBSCRIBE message size in bytes.......................450
   (C08) 200 OK for SUBSCRIBE message size in bytes............370
   (C09) NOTIFY message size not including presence doc........500
   (C10) 200 OK for NOTIFY message size in bytes...............370
   (C11) Size of an average presence document................3,000

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

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



Houri, et al.           Expires January 25, 2008               [Page 29]


Internet-Draft          Presence Scaling Analysis              July 2007


             Number of msgs for all watchers............86,400,000
             Bytes for all watchers................141,564,000,000

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

   ** Bottom Line
   (B01) Total number of message & bytes during the day
             Number of msgs.............................96,000,000
             Bytes.................................152,820,000,000
   (B02) Total number of message & bytes per second
             Number of msgs..................................3,333
             Bytes.......................................5,306,250

           Figure 9: Inter-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................3,000




Houri, et al.           Expires January 25, 2008               [Page 30]


Internet-Draft          Presence Scaling Analysis              July 2007


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

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

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



Houri, et al.           Expires January 25, 2008               [Page 31]


Internet-Draft          Presence Scaling Analysis              July 2007


   (T04) Terminating 200 OK msgs (NOTIFY) per watcher............1
   (T05) Total number & bytes of Terminating SUBSCRIBE msgs
             Number of msgs for all watchers...............120,000
             Bytes for all watchers.....................54,000,000
   (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers...............120,000
             Bytes for all watchers.....................44,400,000
   (T07) Total number & bytes of terminating NOTIFY msgs
             Number of msgs for all watchers...............120,000
             Bytes for all watchers....................420,000,000
   (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
             Number of msgs for all watchers...............120,000
             Bytes for all watchers.....................44,400,000
   (T09) Total number & bytes of terminating messages per day
             Number of msgs for all watchers...............480,000
             Bytes for all watchers....................562.800,000

   ** Bottom Line
   (B01) Total number of message & bytes during the day
             Number of msgs.............................55,440,000
             Bytes.................................107,222,400,000
   (B02) Total number of message & bytes per second
             Number of msgs..................................1,925
             Bytes.......................................3,723,417

            Figure 10: Inter-domain peering with optimizations

2.9.  Partial Notifications Optimization

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

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



Houri, et al.           Expires January 25, 2008               [Page 32]


Internet-Draft          Presence Scaling Analysis              July 2007


   (C11) Size of an average presence document................3,000
   (C12) Size of an average partial presence document..........200

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

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

   ** Termination Messages



Houri, et al.           Expires January 25, 2008               [Page 33]


Internet-Draft          Presence Scaling Analysis              July 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............20,000,000
             Bytes for all watchers..................9,000,000,000
   (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers............20,000,000
             Bytes for all watchers..................7,400,000,000
   (T07) Total number & bytes of terminating NOTIFY msgs
             Number of msgs for all watchers............20,000,000
             Bytes for all watchers.................70,000,000,000
   (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
             Number of msgs for all watchers............20,000,000
             Bytes for all watchers..................7,400,000,000
   (T09) Total number & bytes of terminating messages per day
             Number of msgs for all watchers............80,000,000
             Bytes for all watchers.................93,800,000,000

   ** Bottom Line
   (B01) Total number of message & bytes during the day
             Number of msgs.........................18,840,000,000
             Bytes..............................10,630,400,000,000
   (B02) Total number of message & bytes per second
             Number of msgs................................654,167
             Bytes.....................................369,111,111

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

   Compared to the numbers we got for optimized very large peering
   networks (36,446,400,000,000 bytes per day, it seems that the partial
   notify can save a lot in the bandwidth.

2.10.  Other Protocols

   In SIP there are several differences from other protocols of presence
   as XMPP [6] 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



Houri, et al.           Expires January 25, 2008               [Page 34]


Internet-Draft          Presence Scaling Analysis              July 2007


      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................3,000

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

   ** Steady State Messages
   (S01) NOTIFY msgs due to state change
             per watched presentity per day.....................46
   (S02) 200 (for NOTIFY due to state change) msgs
             per watched presentity per day......................0
   (S03) Total number and size of msgs due to state change per day
             Number of msgs for all watchers.........9,200,000,000
             Bytes for all watchers.............28,980,000,000,000



Houri, et al.           Expires January 25, 2008               [Page 35]


Internet-Draft          Presence Scaling Analysis              July 2007


   (S04) Number of SUBSCRIBE msgs for refreshes
             per watcher per day.................................0
   (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
             per watcher per day.................................0
   (S06) Number of NOTIFY msgs for refreshes
             per watcher per day.................................0
   (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
             per watcher per day.................................0
   (S08) Total number and size of msgs due to SUBSCRIBE refreshes
             Number of msgs for all watchers per day.............0
             Bytes for all watchers per day......................0
   (S09) Total number & bytes of steady messages per day
             Number of msgs for all watchers.........9,200,480,000
             Bytes for all watchers.............28,980,000,000,000

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

   ** Bottom Line
   (B01) Total number of message & bytes during the day
             Number of msgs..........................9,800,000,000
             Bytes..............................29,670,000,000,000
   (B02) Total number of message & bytes per second
             Number of msgs................................340,278
             Bytes...................................1,030,208,333

         Figure 12: Very large networks peering in other protocols

   Compared to the numbers we got for optimized very large peering
   networks (18,840,000,000 messages per day and 10,630,400,000,000



Houri, et al.           Expires January 25, 2008               [Page 36]


Internet-Draft          Presence Scaling Analysis              July 2007


   bytes per day, the numbers of message with other protocols are only
   about half and with due to the partial notification optimization we
   get even less bytes per day.  It seems that this shows that the
   scalability issue of presence is less due to some protocol choice but
   more an inherent issue with presence.


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

   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.




Houri, et al.           Expires January 25, 2008               [Page 37]


Internet-Draft          Presence Scaling Analysis              July 2007


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




Houri, et al.           Expires January 25, 2008               [Page 38]


Internet-Draft          Presence Scaling Analysis              July 2007


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






Houri, et al.           Expires January 25, 2008               [Page 39]


Internet-Draft          Presence Scaling Analysis              July 2007


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

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

   In partial notify the processing is even more complex since each
   watcher needs to get the partial update based on the last update that
   was received by that watcher.  Therefore [11] 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 [8], [9] 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.




Houri, et al.           Expires January 25, 2008               [Page 40]


Internet-Draft          Presence Scaling Analysis              July 2007


4.4.  Authorization

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

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

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



Houri, et al.           Expires January 25, 2008               [Page 41]


Internet-Draft          Presence Scaling Analysis              July 2007


      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
   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 the working group yet are
   summarized in [18].

   o  Subnot-etags - Draft [16].  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 - [10] 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



Houri, et al.           Expires January 25, 2008               [Page 42]


Internet-Draft          Presence Scaling Analysis              July 2007


      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 [11], [12] define a way for the
      subscriber to request getting only what was changed in the
      presence document and for the publisher of presence information to
      publish only what was changed in the presence document since the
      last publish.  Although these optimizations 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 [8], [9] enables a watcher to request
      to be notified only when the presence document fulfills certain
      conditions.  Although this optimization enables saving on the
      amount of messages that are sent from the presence server to the
      watcher, this optimization puts more burden on the processing time
      of the presence server as was discussed above.
   o  Throttling [19] 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 [14] 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 [7] 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.  Conclusions

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




Houri, et al.           Expires January 25, 2008               [Page 43]


Internet-Draft          Presence Scaling Analysis              July 2007


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

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

   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

   It seems that we need to think about the problem in a different way.
   We need to think about scalability as part of the protocol design.
   The IETF tends not to think about actual deployments when designing a
   protocol but in this case it seems that if we do not think about
   scalability with the protocol design it will not be very hard to
   scale.

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

   Another issue that is more concerning protocol design is whether
   NOTIFY messages should not be considered as media as the audio, video
   and even text messaging are considered?  The SUBSCRIBE can be
   extended to do similar three way handshake as INVITE and negotiate
   where the notify messages should go, rate and other parameters.  This
   way the load can be offloaded to specialized NOTIFY "relays" thus not
   loading the control path of SIP.


7.  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 January 25, 2008               [Page 44]


Internet-Draft          Presence Scaling Analysis              July 2007


8.  Changes from Previous Versions

8.1.  Changes in version 02

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

8.2.  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 [17]
   o  The new suggestions for optimizations were moved to [18]


9.  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 for finding a bug in the
   calculations.


10.  References

10.1.  Normative References

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

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




Houri, et al.           Expires January 25, 2008               [Page 45]


Internet-Draft          Presence Scaling Analysis              July 2007


   [6]   Saint-Andre, P., "End-to-End Signing and Object Encryption for
         the Extensible Messaging and Presence Protocol (XMPP)",
         RFC 3923, October 2004.

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

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

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

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

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

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

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

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

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

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

   [17]  Houri, A., "Scaling Requirements for Presence in SIP/SIMPLE",
         draft-houri-sipping-presence-scaling-requirements-00 (work in



Houri, et al.           Expires January 25, 2008               [Page 46]


Internet-Draft          Presence Scaling Analysis              July 2007


         progress), July 2007.

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

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


Authors' Addresses

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

   Email: avshalom@il.ibm.com


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

   Email: timrang@microsoft.com


   Edwin Aoki
   AOL LLC
   360 W. Caribbean  Drive
   Sunnyvale, CA  94089
   USA

   Email: aoki@aol.net












Houri, et al.           Expires January 25, 2008               [Page 47]


Internet-Draft          Presence Scaling Analysis              July 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 January 25, 2008               [Page 48]


Internet-Draft          Presence Scaling Analysis              July 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 January 25, 2008               [Page 49]