[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08                                    
SIMPLE WG                                                       A. Houri
Internet-Draft                                                       IBM
Intended status: Standards Track                                 T. Rang
Expires: August 30, 2007                           Microsoft Corporation
                                                                 E. Aoki
                                                                 AOL LLC
                                                                V. Singh
                                                          H. Schulzrinne
                                                             Columbia U.
                                                       February 26, 2007


                    Problem Statement for SIP/SIMPLE
         draft-ietf-simple-interdomain-scaling-analysis-00.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 August 30, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).








Houri, et al.            Expires August 30, 2007                [Page 1]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


Abstract

   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.  Several suggested
   optimization to the SIMPLE protocol are analysed with the possible
   impact on the load.


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Message Load . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Known Optimizations  . . . . . . . . . . . . . . . . . . .  7
     3.2.  Assumptions  . . . . . . . . . . . . . . . . . . . . . . .  7
     3.3.  Analysis . . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.4.  SIMPLE with no optimizations . . . . . . . . . . . . . . . 10
     3.5.  SIMPLE with suggested optimizations  . . . . . . . . . . . 11
     3.6.  Presence Federations . . . . . . . . . . . . . . . . . . . 12
       3.6.1.  Widely distributed inter-domain presence . . . . . . . 12
       3.6.2.  Associated inter-domain presence . . . . . . . . . . . 14
       3.6.3.  Very large network peering . . . . . . . . . . . . . . 15
       3.6.4.  Intra-domain peering . . . . . . . . . . . . . . . . . 17
   4.  Resource List Service  . . . . . . . . . . . . . . . . . . . . 20
   5.  State Management . . . . . . . . . . . . . . . . . . . . . . . 22
     5.1.  State Size Calculations  . . . . . . . . . . . . . . . . . 23
       5.1.1.  Tiny System  . . . . . . . . . . . . . . . . . . . . . 23
       5.1.2.  Medium System  . . . . . . . . . . . . . . . . . . . . 23
       5.1.3.  Large System . . . . . . . . . . . . . . . . . . . . . 23
       5.1.4.  Very Large System  . . . . . . . . . . . . . . . . . . 24
   6.  Processing complexities  . . . . . . . . . . . . . . . . . . . 25
     6.1.  Aggregation  . . . . . . . . . . . . . . . . . . . . . . . 25
     6.2.  Partial Publish and Notify . . . . . . . . . . . . . . . . 25
     6.3.  Filtering  . . . . . . . . . . . . . . . . . . . . . . . . 26
     6.4.  Privacy  . . . . . . . . . . . . . . . . . . . . . . . . . 26
   7.  Possible Optimizations . . . . . . . . . . . . . . . . . . . . 27
     7.1.  Common NOTIFY for multiple watchers  . . . . . . . . . . . 27
       7.1.1.  Privacy filtering  . . . . . . . . . . . . . . . . . . 27
       7.1.2.  NOTIFY failure aggregation . . . . . . . . . . . . . . 28
       7.1.3.  Transferring the watcher list  . . . . . . . . . . . . 28
       7.1.4.  Message flow example . . . . . . . . . . . . . . . . . 29
       7.1.5.  SIP message examples for common NOTIFY . . . . . . . . 31
     7.2.  Aggregation of NOTIFY messages (Batched notification)  . . 32
       7.2.1.  Extracting and sending individual NOTIFY using
               Aggregated NOTIFY message body . . . . . . . . . . . . 32



Houri, et al.            Expires August 30, 2007                [Page 2]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


       7.2.2.  Subscription termination and failure indication in
               NOTIFY delivery  . . . . . . . . . . . . . . . . . . . 33
       7.2.3.  Message flow example . . . . . . . . . . . . . . . . . 33
       7.2.4.  SIP message flow example for batched notification  . . 35
     7.3.  Timed presence . . . . . . . . . . . . . . . . . . . . . . 37
     7.4.  On-Demand presence (Fetch or Pull Model) . . . . . . . . . 38
     7.5.  Adapting the subscription rate . . . . . . . . . . . . . . 38
     7.6.  Other Optimizations  . . . . . . . . . . . . . . . . . . . 38
   8.  Extremely Optimized  Model . . . . . . . . . . . . . . . . . . 41
   9.  Suggested Requirements . . . . . . . . . . . . . . . . . . . . 43
   10. Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 45
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 46
   12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 47
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 48
     13.2. Informational References . . . . . . . . . . . . . . . . . 48
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
   Intellectual Property and Copyright Statements . . . . . . . . . . 52

































Houri, et al.            Expires August 30, 2007                [Page 3]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [1].














































Houri, et al.            Expires August 30, 2007                [Page 4]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


2.  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.  Several suggested
   optimization to the SIMPLE protocol are analysed with the possible
   impact on the load.

   Although this document is an analysis document and not a BCP
   document, several possible optimizations and directions are listed in
   addition to an initial set of requirements for what should be the
   characteristic of the solution to the problem stated in the document

   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 [12] optimize the number of
      sessions that are created between the watchers and the presence
      server.  On the other hand, this optimization may create an



Houri, et al.            Expires August 30, 2007                [Page 5]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


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

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











































Houri, et al.            Expires August 30, 2007                [Page 6]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


3.  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) [12] introduce very
   similar traffic pattern within a domain as between domains.  See
   detailed discussion on resource lists in section Section 4.

3.1.  Known Optimizations

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

   o  Dialogs saving optimization - Here we refer to optimizations as
      the resource list RFC [12] or to the Uri list subscriptions draft
      [18].  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 [20].  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.

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



Houri, et al.            Expires August 30, 2007                [Page 7]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


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

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

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

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

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

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

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

3.3.  Analysis

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

   o  SUBSCRIBE/200

   o  Initial NOTIFY/200

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

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



Houri, et al.            Expires August 30, 2007                [Page 8]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


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

   o  NOTIFY/200 ending the dialog

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

   o  Number of watchers connected to the system

   o  Number of presentities connected to the system

   o  Frequency of changes to presence information

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

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

   o  (A02) Presence state changes / hour - The average time that a
      presentity changes his/hers status in one hour.  We assumed 3
      times per hour for most calculations.  Note that for some users in
      consumer messaging systems, the actual number of changes is likely
      to be much higher.

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

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

   o  (A05) 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  (A06) Number of watchers in a federated presence domain - The
      number of watchers in one presence domain that watch presentities
      in the other domain.  The number here varies according to the
      assumptions for a specific deployment




Houri, et al.            Expires August 30, 2007                [Page 9]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


   o  (A07) Initial SUBSCRIBE/200 per watcher = A05*2 (message and an OK

   o  (A08) Initial NOTIFY/200 per watcher = A05*2 (message and an OK)

   o  (A09) Total initial messages = (A07+A08)*A06

   o  (A10) NOTIFY/200 per watched presentity = (A02*A01*A04*2) (message
      and an OK)

   o  (A11) SUBSCRIBE/200 refreshes = (A01/A03)*A05*2 (message and an
      OK)

   o  (A12) NOTIFY/200 due to subscribe refresh - In a deployment where
      the notification optimization is not deployed this number will be
      ((A01/A03)*A05), otherwise it is 0

   o  (A13) Number of steady state messages = (A10+A11+A12)*A06

   o  (A14) SUBSCRIBE termination = A05*2 (message and an OK)

   o  (A15) NOTIFY terminated = A05*2 (message and an OK)

   o  (A16) Number of sign-out messages = (A14+A15)*A06

   o  (A17) Total messages between domains (both directions where users
      from domain A subscribe to users from domain B and vice versa)=
      (A09+A13+A16)*2

   o  (A18) Total number of messages / second = A17/A01/3600 (seconds in
      hour)

   o  (A19) Total number of K bytes per second.  Assuming 1K bytes per
      SUBSCRIBE/200 pair and 4K bytes per NOTIFY/200 pair.  Note that in
      reality the NOTIFY size may be much bigger but using partial
      NOTIFY should reduce the size considerably

3.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, each with 20,000 federating users with an average of 4
   contacts in the peer domain







Houri, et al.            Expires August 30, 2007               [Page 10]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


   (A01) Subscription lifetime (hours)...........................8
   (A02) Presence state changes / hour...........................3
   (A03) Subscription refresh interval / hour....................1
   (A04) Total federated presentities per watcher................4
   (A05) Number of dialogs to maintain per watcher...............4
   (A06) Number of watchers in a federated presence domain..20,000

   (A07) Initial SUBSCRIBE/200 per watcher.......................8
   (A08) Initial NOTIFY/200 per watcher..........................8
   (A09) Total initial messages............................320,000

   (A10) NOTIFY/200 per watched presentity.....................192
   (A11) SUBSCRIBE/200 refreshes................................64
   (A12) NOTIFY/200 due to subscribe refresh....................64
   (A13) Number of steady state messages.................6,400,000

   (A14) SUBSCRIBE termination...................................8
   (A15) NOTIFY terminated.......................................8
   (A16) Number of sign-out messages.......................320,000

   (A17) Total messages between domains.................14,080,000
   (A18) Total number of messages / second.....................489
   (A19) Total number of bytes / second on the wire..........830KB

                  Figure 1: SIMPLE with no optimizations

3.5.  SIMPLE with suggested optimizations

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

   The optimizations enable the creation of a single dialog to the other
   domain from each watcher for the set of presentities it is watching.
   The optimizations also enable that there will be no need for a NOTIFY
   upon refreshing a SUBSCRIBE since the NOTIFY should not be sent in
   the refresh since it should be the same one that was sent when there
   was a state change for the presentity.












Houri, et al.            Expires August 30, 2007               [Page 11]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


   (A01) Subscription lifetime (hours)...........................8
   (A02) Presence state changes /hour............................3
   (A03) Subscription refresh interval / hour....................1
   (A04) Total federated presentities per watcher................4
   (A05) Number of dialogs to maintain per watcher...............1
   (A06) Number of watchers in a federated presence domain..20,000

   (A07) Initial SUBSCRIBE/200 per watcher.......................2
   (A08) Initial NOTIFY/200 per watcher..........................2
   (A09) Total initial messages.............................80,000

   (A10) NOTIFY/200 per watched presentity.....................192
   (A11) SUBSCRIBE/200 refreshes................................16
   (A12) NOTIFY/200 due to subscribe refresh.....................0
   (A13) Number of steady state messages.................4,160,000

   (A14) SUBSCRIBE termination...................................2
   (A15) NOTIFY terminated.......................................2
   (A16) Number of sign-out messages........................80,000

   (A17) Total messages between domains..................8,640,000
   (A18) Total number of messages / second.....................300
   (A19) Total number of bytes / second on the wire..........571KB

                    Figure 2: SIMPLE with optimizations

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

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



Houri, et al.            Expires August 30, 2007               [Page 12]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


   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.

   (A01) Subscription lifetime (hours)...........................8
   (A02) Presence state changes / hour...........................3
   (A03) Subscription refresh interval / hour....................1
   (A04) Total federated presentities per watcher...............20
   (A05) Number of dialogs to maintain per watcher..............20
   (A06) Number of watchers in a federated presence domain..20,000

   (A07) Initial SUBSCRIBE/200 per watcher......................40
   (A08) Initial NOTIFY/200 per watcher.........................40
   (A09) Total initial messages..........................1,600,000

   (A10) NOTIFY/200 per watched presentity.....................960
   (A11) SUBSCRIBE/200 refreshes...............................320
   (A12) NOTIFY/200 due to subscribe refresh...................320
   (A13) Number of steady state messages................32,000,000

   (A14) SUBSCRIBE termination..................................40
   (A15) NOTIFY terminated......................................40
   (A16) Number of sign-out messages.....................1,600,000

   (A17) Total messages between domains.................70,400,000
   (A18) Total number of messages / second...................2,444
   (A19) Total number of bytes / second on the wire.........1968KB




Houri, et al.            Expires August 30, 2007               [Page 13]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


      Figure 3: Widely distributed inter-domain with no optimizations


   (A01) Subscription lifetime (hours)...........................8
   (A02) Presence state changes / hour...........................3
   (A03) Subscription refresh interval / hour....................1
   (A04) Total federated presentities per watcher...............20
   (A05) Number of dialogs to maintain per watcher...............1
   (A06) Number of watchers in a federated presence domain..20,000

   (A07) Initial SUBSCRIBE/200 per watcher.......................2
   (A08) Initial NOTIFY/200 per watcher..........................2
   (A09) Total initial messages.............................80,000

   (A10) NOTIFY/200 per watched presentity.....................960
   (A11) SUBSCRIBE/200 refreshes................................16
   (A12) NOTIFY/200 due to subscribe refresh.....................0
   (A13) Number of steady state messages................19,520,000

   (A14) SUBSCRIBE termination...................................2
   (A15) NOTIFY terminated.......................................2
   (A16) Number of sign-out messages........................80,000

   (A17) Total messages between domains.................39,360,000
   (A18) Total number of messages / second...................1,367
   (A19) Total number of bytes / second on the wire..........571KB

       Figure 4: Widely distributed inter-domain with optimizations

3.6.2.  Associated inter-domain presence

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

   Common characteristics of this deployment are:

   o  Federated subscriptions are large minority or small majority of
      subscription traffic

   o  Individual users are likely to subscribe to multiple users in any
      one domain, especially their own





Houri, et al.            Expires August 30, 2007               [Page 14]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


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

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

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















Houri, et al.            Expires August 30, 2007               [Page 15]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


   (A01) Subscription lifetime (hours)..............................8
   (A02) Presence state changes / hour..............................6
   (A03) Subscription refresh interval / hour.......................1
   (A04) Total federated presentities per watcher..................10
   (A05) Number of dialogs to maintain per watcher.................10
   (A06) Number of watchers in a federated presence domain.10,000,000

   (A07) Initial SUBSCRIBE/200 per watcher.........................20
   (A08) Initial NOTIFY/200 per watcher............................20
   (A09) Total initial messages...........................400,000,000

   (A10) NOTIFY/200 per watched presentity........................960
   (A11) SUBSCRIBE/200 refreshes..................................160
   (A12) NOTIFY/200 due to subscribe refresh......................160
   (A13) Number of steady state messages...............12,800,000,000

   (A14) SUBSCRIBE termination.....................................20
   (A15) NOTIFY terminated.........................................20
   (A16) Number of sign-out messages....................4,000,000,000

   (A17) Total messages between domains................27,200,000,000
   (A18) Total number of messages / second....................944,444
   (A19) Total number of bytes / second on the wire.........880,555KB

        Figure 5: Very large network peering with no optimizations


























Houri, et al.            Expires August 30, 2007               [Page 16]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


   (A01) Subscription lifetime (hours)..............................8
   (A02) Presence state changes / hour..............................6
   (A03) Subscription refresh interval / hour.......................1
   (A04) Total federated presentities per watcher..................10
   (A05) Number of dialogs to maintain per watcher..................1
   (A06) Number of watchers in a federated presence domain.10,000,000

   (A07) Initial SUBSCRIBE/200 per watcher..........................2
   (A08) Initial NOTIFY/200 per watcher.............................2
   (A09) Total initial messages............................40,000,000

   (A10) NOTIFY/200 per watched presentity........................960
   (A11) SUBSCRIBE/200 refreshes...................................16
   (A12) NOTIFY/200 due to subscribe refresh........................0
   (A13) Number of steady state messages................9,760,000,000

   (A14) SUBSCRIBE termination......................................2
   (A15) NOTIFY terminated..........................................2
   (A16) Number of sign-out messages.......................40,000,000

   (A17) Total messages between domains................19,680,000,000
   (A18) Total number of messages / second....................683,333
   (A19) Total number of bytes / second on the wire.........545,833KB


          Figure 6: Very large network peering with optimizations

3.6.4.  Intra-domain peering

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

   Common characteristics of this deployment are

   o  The difference between subscriptions to presentities in one system
      vs. the other are completely arbitrary.  Any one presentity is as
      likely to be homed on one infrastructure as the other

   o  Active users are almost guaranteed of subscribing to many users in
      the peer infrastructure





Houri, et al.            Expires August 30, 2007               [Page 17]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


   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

   (A01) Subscription lifetime (hours)..............................8
   (A02) Presence state changes / hour..............................3
   (A03) Subscription refresh interval / hour.......................1
   (A04) Total federated presentities per watcher..................10
   (A05) Number of dialogs to maintain per watcher.................10
   (A06) Number of watchers in a federated presence domain.....60,000

   (A07) Initial SUBSCRIBE/200 per watcher.........................20
   (A08) Initial NOTIFY/200 per watcher............................20
   (A09) Total initial messages.............................2,400,000

   (A10) NOTIFY/200 per watched presentity........................480
   (A11) SUBSCRIBE/200 refreshes..................................160
   (A12) NOTIFY/200 due to subscribe refresh......................160
   (A13) Number of steady state messages...................48,400,000

   (A14) SUBSCRIBE termination.....................................20
   (A15) NOTIFY terminated.........................................20
   (A16) Number of sign-out messages........................2,400,000

   (A17) Total messages between domains...................105,600,000
   (A18) Total number of messages / second......................3,667
   (A19) Total number of bytes / second on the wire...........3,683KB

           Figure 7: Inter-domain peering with no optimizations


















Houri, et al.            Expires August 30, 2007               [Page 18]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


   (A01) Subscription lifetime (hours)..............................8
   (A02) Presence state changes / hour..............................3
   (A03) Subscription refresh interval / hour.......................1
   (A04) Total federated presentities per watcher..................10
   (A05) Number of dialogs to maintain per watcher..................1
   (A06) Number of watchers in a federated presence domain.....60,000

   (A07) Initial SUBSCRIBE/200 per watcher..........................2
   (A08) Initial NOTIFY/200 per watcher.............................2
   (A09) Total initial messages...............................240,000

   (A10) NOTIFY/200 per watched presentity........................480
   (A11) SUBSCRIBE refreshes.......................................16
   (A12) NOTIFY/200 due to subscribe refresh........................0
   (A13) Number of steady state messages...................29,760,000

   (A14) SUBSCRIBE termination......................................2
   (A15) NOTIFY terminated..........................................2
   (A16) Number of sign-out messages..........................240,000

   (A17) Total messages between domains....................60,480,000
   (A18) Total number of messages / second......................2,100
   (A19) Total number of bytes / second on the wire...........1,675KB

             Figure 8: Inter-domain peering with optimizations


























Houri, et al.            Expires August 30, 2007               [Page 19]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


4.  Resource List Service

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

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

   o  Subscriptions and state - The resource list may contain reference
      to many other presence servers in many other domains.  This
      requires the RLS to create subscriptions to other presence servers
      and buffer the state of all presentities in order to be able to
      provide the full state of the presentities in the list when
      needed.  So in the overall system, the subscriptions that were
      saved between the watcher and the presence server are moved to the
      backend system while state has been duplicated between the various
      presence servers that serve the various presentities and the RLSs.
      This issue could have been mitigated if there was a way for the
      RLS to retrieve the presence information for many watchers while
      adhering to privacy when sending the actual notifications to the
      watchers.

   o  Interlinkage - The resource list subscription will reach one RLS
      that will open it and send it to many presence servers and to
      other RLSs (if there is a subgroup inside the list).  This way a
      complex linkage between the state of many components is created.
      This linkage makes state management and other maintenance of a
      presence systems quite complex.

   o  Big lists are easy - There are two types of groups that may be
      used with this feature, private groups that are defined by/for
      each watcher and public groups that are defined in the system and
      can be used by any watcher.  Although we should expect IT
      administrators to take caution when creating public groups, this
      may be not the case in real life.  The connection between the size
      of the public group and the load on the presence server system may
      not apparent to everyone.  Furthermore many public groups that are
      used in presence systems may have been created for other purposes
      as email systems (where the size of the lists was not so
      important) and are taken as they are to presence systems.  So for
      example we may very easily find that a public group that actually
      covers all the users in the enterprise are used by many users in
      the enterprise thus creating unbearable load on the presence



Houri, et al.            Expires August 30, 2007               [Page 20]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


      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.



































Houri, et al.            Expires August 30, 2007               [Page 21]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


5.  State Management

   In previous section 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 [5], [7] 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  Privacy 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 August 30, 2007               [Page 22]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


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

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

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

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





Houri, et al.            Expires August 30, 2007               [Page 23]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


5.1.4.  Very Large System

   o  150M subscriptions = 292,969M bytes.

   o  75M subscribed to presentities = 73,242M bytes.

   o  100M presentities with state = 585,937M bytes.

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

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

   o  Dynamic state - Although the state may seem not so big for
      databases even for the very large system, we need to remember that
      this state is a very dynamic state.  Subscriptions come and go all
      the time, the status of presentities is being updated and so
      forth.  This means that the presence server has to manage its
      state in a medium that is very dynamic and for such large sizes
      this task is not trivial.

   o  Interlinked state - The subscriptions and the subscribed to
      presentities are dependent on each other.  There need to be a link
      from the presentity to the subscriptions and vice versa.  See
      section Section 4 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...








Houri, et al.            Expires August 30, 2007               [Page 24]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


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

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

6.2.  Partial Publish and Notify

   Drafts [13], [14] 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 [13] specifies a versioning
   mechanism that enables the watcher to get the updates based on the



Houri, et al.            Expires August 30, 2007               [Page 25]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


   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.

6.3.  Filtering

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

6.4.  Privacy

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




























Houri, et al.            Expires August 30, 2007               [Page 26]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


7.  Possible Optimizations

   This section contains techniques which can be employed by the
   presence server and clients to reduce presence traffic, specifically,
   on inter-domain links.  Several techniques proposed and briefly
   described here.  The quantitative analysis of these techniques is not
   fully done yet and will be present in a future version of this
   document.  Protocol mechanisms to employ these techniques are
   described briefly.  This section is intended to help us evaluate and
   decide if such techniques should become a part of SIMPLE protocol
   suite.

7.1.  Common NOTIFY for multiple watchers

   When multiple watchers from a domain (for example, domain B)
   SUBSCRIBE to a presentity in another domain (for example, domain A),
   a single NOTIFY [2] per presentity in domain B can be sent to domain
   B's presence server (PS).  The presence server in domain B can then
   distribute the NOTIFY messages to each of the watchers.  This
   eliminates the need to send individual NOTIFY messages from domain
   A's presence server to each watcher in domain B. The presence server
   and resource list server (RLS) are assumed to be co--located as a
   result of which NOTIFY messages are sent to presence server (RLS) in
   domain B rather then delivered directly to the watchers of domain B.

   The server distributes the NOTIFY message to a list of watchers based
   on a single NOTIFY message received from another presence agent.
   There are three main issues namely, privacy filtering, failure
   aggregation and transfer of watcher list to watcher's domain presence
   server to distribute NOTIFY.  We discuss these in next subsections.

7.1.1.  Privacy filtering

   Privacy filtering is typically done by presentity's presence server.
   We propose that presentity's privacy filtering task be handled by
   watcher domain's presence server, in this case domain B's presence
   server.  There are two possibilities about privacy filtering rules of
   the presentity as described below.

   Per domain privacy filters: Presentity in domain A having same
   privacy filter rules for all the watchers in domain B. In other
   words, there is a domain level privacy filter specified by the
   presentity for users from domain B. Privacy filtering can be done by
   the presence server in domain A and a single NOTIFY can be sent from
   presence server in domain B.

   Per watcher privacy filters: Presentity in domain A has different
   privacy filter rules for different watchers in domain B. Since,



Houri, et al.            Expires August 30, 2007               [Page 27]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


   presentity in domain A has different privacy filtering rules for
   watchers from domain B, the privacy filter has to be applied by the
   presence server in domain B. Complete presence state information
   needs to be sent from the presentity's domain to watcher's domain.

   Delegating the task of privacy filtering doesn't compromise any
   additional privacy information when compared with normal operations.
   The model is very similar to e-mail trust model.  Transfer of a
   single NOTIFY from presentity's domain to watcher's domain implies
   that the presence server in watcher's domain receives that
   information and can potentially distribute it to unauthorized
   watchers.  Thus, presentity implicitly trusts the presence server in
   its own domain as well as watcher's domain.  The proposed mechanism
   extends such a trust to the presence server in domain B so that it
   performs the privacy filtering on behalf of presentity in domain A.
   One potential issue is when presence server in domain A encrypts the
   presence document for each watcher using SMIME in which case the
   watcher domain PS cannot perform privacy filtering.  Hence, this kind
   of privacy filtering requires a layer 8 security negotiation between
   the presence servers of the two domains

7.1.2.  NOTIFY failure aggregation

   The success or failure of NOTIFY message by the server changes the
   subscription status of the watcher on the presentity's presence
   server.  Hence, to update about failure of NOTIFY delivery, domain
   B's presence server aggregates the success and failure responses for
   each watcher and send it to the presence server in domain A.
   Alternatively, application level negative acknowledgement can be
   used.

7.1.3.  Transferring the watcher list

   In order to distribute the NOTIFY message received from domain A, the
   watcher domain presence server requires the list of watchers in its
   domain for that presentity.  We propose the following ways to achieve
   this.

   o  Watcher list sent in NOTIFY message: The watcher list can be sent
      from domain A's presence server to domain B's presence server in
      each NOTIFY message.  The NOTIFY is then distributed to each
      watcher in the list.  This has a disadvantage when the number of
      watcher's from domain B is very large, every NOTIFY message
      increases in size proportionately.  An alternative could be
      sending the complete list initially and sending changes to the
      list using the XML-patch operations [16] specified in partial-
      publication and maintaining the list on presence server in domain
      B. Sending watcher- list and distributing it, is similar to multi



Houri, et al.            Expires August 30, 2007               [Page 28]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


      recipient messages i.e., [19], and SUBSCRIBE contained list or
      Exploders.

   o  Watcher list obtained by subscribing to WINFO [5]package: In this
      technique, the watcher's domain (domain B) presence server obtains
      the watcher list from domain A's PS.  It also receives any changes
      to the watcher-list from domain A's PS by subscribing to the
      presentity with presence.winfo event package.  The domain A's PS
      maintains and updates the watcher list as a part of its normal
      operation.  The updates are sent whenever watcher list changes.
      They contain information about watchers from domain B only.

   o  Watcher list created on subscriber's presence server: The watcher
      domain presence server maintains and updates the list of watchers
      per presentity based on the SUBSCRIBE requests from these
      watchers.  Such a list is like a resource list of watchers per
      presentity in watcher's domain built dynamically based on
      SUBSCRIBE request which are not directly sent to presentity's PS.

7.1.4.  Message flow example

   Below is the message flow diagram of how the system may work.





























Houri, et al.            Expires August 30, 2007               [Page 29]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


    Watchers             Domain B            Domain A       Presentity
   (userB1, B2)         (PS + RLS)          (PS + RLS)      (userA1, A2)
       -----------------------------------------------------------
     1 |  SUBSCRIBE t:userA1  |                   |              |
     2 |--------------------->|                   |              |
     3 |     f:userB1)        |    SUBSCRIBE      |              |
     4 |<-------200OK---------|------------------>|              |
     5 |                      |<-----200OK -------|              |
     6 |                      |                   |              |
     7 |                      |      NOTIFY       |              |
     8 |                      |<------------------|              |
     9 |    NOTIFY (f:userA1  |------200OK------->|              |
    10 |<---------------------|                   |              |
    11 |     t:userB1)        |                   |              |
    12 |---------200 OK------>|   XCAP Filter B1   |              |
    13 |                      |<-----------------<|              |
    14 |                      |                   |              |
    15 |  SUBSCRIBE t:userA1  |                   |              |
    16 |--------------------->|    SUBSCRIBE      |              |
    17 |     f:userB2)        |------------------>|              |
    18 |<-------200OK---------|<-----200OK -------|              |
    19 |                      |                   |              |
    20 |                      |      NOTIFY       |              |
    21 |    NOTIFY (f:userA1  |<------------------|              |
    22 |<---------------------|------200OK------->|              |
    23 |     t:userB2)        |                   |              |
    24 |---------200 OK------>|   XCAP Filter B2  |              |
    25 |                      |<-----------------<|    PUBLISH   |
    26 |                      |                   |<-------------|
    27 |                      |                   |------200OK ->|
    28 |                      | NOTIFY (f:userA1  |              |
    29 |                      |<------------------|              |
    30 |                      | t: userB1, UserB2)|              |
    31 |    NOTIFY (f:userA1  |------200OK------->|              |
    32 |<---------------------|                   |              |
    33 |     t:userB1)        |                   |              |
    34 |---------200 OK------>|                   |              |
    35 |    NOTIFY (f:userA1  |                   |              |
    36 |<---------------------|                   |              |
    37 |     t:userB2)        |                   |    PUT XCAP  |
    38 |---------200 OK------>|                   |<-------------|
    39 |                      | NOTIFY (filter)   <update filters>
    40 |                      |<------------------|              |
    41 |                      |------200OK------->|              |
    42 |                      |                   |              |
    43 |                      |   XCAP Filter B2  |              |
    44 |                      |<-----------------<|              |
       -----------------------------------------------------------



Houri, et al.            Expires August 30, 2007               [Page 30]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


    Figure 9: Example message flow for common NOTIFY for watchers in a
                                  domain

   We can see in figure above that a single NOTIFY from userA1@
   domainA.com is sent to watchers {userB1, userB2}@domainB.com.  Also,
   we can see that a change in privacy filter rule causes a NOTIFY which
   triggers an XCAP-based download of privacy filtering rules by domain
   B PS.

7.1.5.  SIP message examples for common NOTIFY

   The following NOTIFY message contains the list of watchers and the
   presence document of the presentity.  The RLS /presence server in B
   will distribute it to all the watchers in the list.
  NOTIFY sip:rlserver.domainB.com SIP/2.0
  Via: SIP/2.0/TCP rlsserver.domainA.com;branch=z9hG4bK4EPlfSFQK1
  Max-Forwards: 70
  From: <sip:userA1@domainA.com>;tag=zpNctbZq
  To: <sip:rlsserver@domainB.com>;tag=ie4hbb8t
  Call-ID: cdB34qLToC@domainA.com
  CSeq: 997935769 NOTIFY
  Contact: <sip:rlsserver.domainA.com>
  Event: presence
  Subscription-State: active;expires=7200
  Content-Type: multipart/related;type="resource-lists+xml";
         start="<2BEI83@rlsserver.domainA.com >";
         boundary=" tuLLl3lDyPZX0GMr2YOo "
  Content-Length: 2014

  --tuLLl3lDyPZX0GMr2YOo
  Content-Transfer-Encoding: binary
  Content-ID: <2BEI83@rlsserver.domainA. com>
  Content-Type: application/resource-lists+xml; charset="UTF-8"
     <?xml version="1.0" encoding="UTF-8"?>
     <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
       <list>
         <entry uri="sip:userB1@domainB.com" />
         <entry uri="sip:userB2@domainB.com" />
       </list>
     </resource-lists>

  --tuLLl3lDyPZX0GMr2YOo
  Content-Transfer-Encoding: binary
  Content-ID: <2BEI83@rlsserver.domainA.example.com >
  Content-Type:type="application/pidf+xml;charset="UTF-8"
         start="<AAAA@rlsserver.domainB.example.com >";
         boundary=" TfZxoxgAvLqgj4wRWPDL"



Houri, et al.            Expires August 30, 2007               [Page 31]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


  --TfZxoxgAvLqgj4wRWPDL

     <?xml version="1.0" encoding="UTF-8"?>
     <presence xmlns="urn:ietf:params:xml:ns:pidf"
         entity="sip:userA1@domainA.com">
       <tuple id="z98075">
         <status>
           <basic>closed</basic>
         </status>
       </tuple>
     </presence>

  --TfZxoxgAvLqgj4wRWPDL--

       Figure 10: SIP message examples using common notify technique

7.2.  Aggregation of NOTIFY messages (Batched notification)

   When a watcher from a domain (for example domain B) SUBSCRIBE to
   multiple presentities in another domain (domain A), domain A's
   presence server can aggregate the notification messages and send them
   together as a single NOTIFY message to the presence server in domain
   B. The presence server in domain B can then deliver the message to
   the watcher or create individual NOTIFY messages for different
   watchers and send it to them.  This reduces the number of NOTIFY/ 200
   OK messages on the inter-domain link as well as access network.  This
   aggregation of NOTIFY can be done on per watcher or per domain basis.
   The RLS specification describes aggregation and throttling however,
   leaves it open to the implementers.

   One problem in aggregation is that presence status update for
   presentities may not occur simultaneously.  Hence, in order to bundle
   the NOTIFY messages for each watcher or domain, the presence server
   may have to delay some of the NOTIFY messages.  One approach to solve
   this issue could be that the watcher specifies a tolerable delay for
   receiving presence state update of the presentities.  The watcher can
   specify this delay value using the watcher filtering mechanism or a
   SIP-header extension in the SUBSCRIBE message.  The presence server
   in presentity's domain can hold the NOTIFY message only for the
   amount of time specified.

7.2.1.  Extracting and sending individual NOTIFY using Aggregated NOTIFY
        message body

   The aggregation of NOTIFY bodies originating from different
   presentities to a single NOTIFY body works on the basis of Multipart
   (MIME).  Bundling of notification imply aggregating multiple NOTIFY
   bodies destined to a single watcher (or watcher domain) into a single



Houri, et al.            Expires August 30, 2007               [Page 32]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


   NOTIFY and delivered to watcher domain presence server.  If all the
   NOTIFY messages are destined to a single watcher, the watcher domain
   presence server delivers the message directly.  Otherwise, the server
   extracts multiple presence bodies (PIDF) from the received NOTIFY
   message.  Each presence document (PIDF [6]) contains an entity field
   which uniquely identifies the presentity; hence, there is no
   dependency on SIP headers to construct individual NOTIFY messages for
   delivering them to watchers.  Delivering bundled NOTIFY messages
   reduces the traffic on access network as well.

7.2.2.  Subscription termination and failure indication in NOTIFY
        delivery

   The Subscription-state header in the NOTIFY message is used to
   indicate subscription termination to a watcher.  Bundled notification
   doesn't indicate subscription termination, hence, terminating NOTIFY
   messages cannot be sent using this mechanism.  Additionally, the
   notifier needs to know if the NOTIFY was delivered successfully or
   not.  The subscription can be terminated if NOTIFY is not delivered
   successfully.  The presence server in domain B should aggregate and
   send to PS in domain A the success or failure of NOTIFY messages.
   The advantage is observed when a single watcher subscribes to
   multiple presentities from another domain.  The delay tolerance
   interval specified by the watcher should be good enough so that
   multiple NOTIFY messages can be bundled or aggregated.  The reduction
   in traffic can be seen under two scenarios, i.e., (i) when watcher
   logs in and subscribes to all the presentities.  The NOTIFY from
   multiple presentities can be bundled and delivered as a single
   message to the watcher. (ii) In steady state, the gain can be
   calculated based on the delay tolerance interval, number of
   presentities to which a watcher is subscribed, probability of these
   presentities changing state in that interval.  With increase in
   number of presentities, the probability that presentities will update
   presence state within a time difference of delay tolerance interval
   will increase and hence the inter domain traffic reduction (gain)
   will increase.

7.2.3.  Message flow example

   The message flow diagram in Figure below assumes watchers in domain B
   (userB1, userB2) and presentities in domain A (userA1, userA2).  We
   can see that when userA1 and userA2 send PUBLISH, a single NOTIFY is
   sent from domain A to domain B, which is converted to individual
   NOTIFY messages by presence server at domain B.







Houri, et al.            Expires August 30, 2007               [Page 33]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


   Watchers             Domain B            Domain A         Presentity
   (userB1,B2)          (PS + RLS)          (PS + RLS)       (userA1,A2)
       -----------------------------------------------------------
     1 |  SUBSCRIBE t:userA1  |                   |              |
     2 |--------------------->|                   |              |
     3 |     f:userB1)        |                   |              |
     4 |<-------200OK---------|    SUBSCRIBE      |              |
     5 |                      |------------------>|              |
     6 |                      |<-----200OK -------|              |
     7 |                      |                   |              |
     8 |                      |      NOTIFY       |              |
     9 |                      |<------------------|              |
    10 |    NOTIFY (f:userA1  |------200OK------->|              |
    11 |<---------------------|                   |              |
    12 |     t:userB1)        |                   |              |
    13 |---------200 OK------>|                   |              |
    14 |                      |                   |              |
    15 |                      |                   |              |
    16 |  SUBSCRIBE t:userA2  |                   |              |
    17 |--------------------->|    SUBSCRIBE      |              |
    18 |     f:userB1)        |------------------>|              |
    19 |<-------200OK---------|<-----200OK -------|              |
    20 |                      |                   |              |
    21 |                      |      NOTIFY       |              |
    22 |    NOTIFY (f:userA2  |<------------------|              |
    23 |<---------------------|------200OK------->|              |
    24 |     t:userB1)        |                   |              |
    25 |---------200 OK------>|                   |    PUBLISH   |
    26 |                      |             userA1|<-------------|
    27 |                      |                   |------200OK ->|
    28 |                      |                   |              |
    29 |                      |                   |    PUBLISH   |
    30 |                      |             userA2|<-------------|
    31 |                      |                   |------200OK ->|
    32 |                      |                   |              |
    33 |                      | NOTIFY (multipart)|              |
    34 |                      |<------------------|              |
    35 |    NOTIFY (f:userA1  | (userA1,userA2)   |              |
    36 |<---------------------|------200OK------->|              |
    37 |     t:userB1)        |                   |              |
    38 |---------200 OK------>|                   |              |
    39 |                      |                   |              |
    40 |                      |                   |              |
    41 |    NOTIFY (f:userA1  |                   |              |
    42 |<---------------------|                   |              |
    43 |     t:userB1)        |                   |              |
    44 |---------200 OK------>|                   |              |
       -----------------------------------------------------------



Houri, et al.            Expires August 30, 2007               [Page 34]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


      Figure 11: Message flow for aggregation or batched notification

7.2.4.  SIP message flow example for batched notification

   The following NOTIFY message contains presence documents of multiple
   presentities.  In the example, all the presence documents are
   destined to a single watcher.












































Houri, et al.            Expires August 30, 2007               [Page 35]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


 NOTIFY sip:rlserver.domainB.com SIP/2.0
 Via: SIP/2.0/TCP rlsserver.domainA.example.com;branch=z9hG4bK4EPlfSFQK1
 Max-Forwards: 70
 From: <sip:rlsserver@domainA.com>;tag=zpNctbZq
 To: <sip:userA@domainB.com>;tag=ie4hbb8t
 Call-ID: cdB34qLToC@ domainA.com
 CSeq: 997935769 NOTIFY
 Contact: <sip:rlsserver.domainA.com>
 Event: presence
 Subscription-State: active;expires=7200
 Content-Type: multipart/related;type="rlmi+xml";
        start="<2BEI83@rlsserver.domainB.example.com >";
        boundary=" tuLLl3lDyPZX0GMr2YOo "
 Content-Length: 2862

 --tuLLl3lDyPZX0GMr2YOo
    Content-Transfer-Encoding: binary
    Content-ID: <2BEI83@rlsserver.domainB.example.com>
    Content-Type: application/pidf+xml;charset="UTF-8"

    <?xml version="1.0" encoding="UTF-8"?>
    <presence xmlns="urn:ietf:params:xml:ns:pidf"
        entity="sip:userA1@domainA.com">
      <tuple id="x823a4">
        <status>
          <basic>open</basic>
        </status>
        <contact priority="1.0">sip:joe@stockholm.example.org</contact>
      </tuple>
    </presence>

    --tuLLl3lDyPZX0GMr2YOo
    Content-Transfer-Encoding: binary
    Content-ID: <KKMDmv@stockholm.example.org>
    Content-Type: application/pidf+xml;charset="UTF-8"

    <?xml version="1.0" encoding="UTF-8"?>
    <presence xmlns="urn:ietf:params:xml:ns:pidf"
        entity="sip:userA2@domainA.com">
      <tuple id="z98075">
        <status>
          <basic>closed</basic>
        </status>
      </tuple>
    </presence>
    --tuLLl3lDyPZX0GMr2YOo--

      Figure 12: Message Flow for Aggregation or Batched Notification



Houri, et al.            Expires August 30, 2007               [Page 36]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


7.3.  Timed presence

   Watchers may be interested in general, coarse-grained availability
   information of certain presentities rather then getting notification
   for every status change of the presentity.  For example, a manager
   may be interested in knowing if the employees under him are available
   or on vacation (calendar/timed-presence) rather then getting
   notification about every status change.  This can be achieved using
   timed-presence [8].  An example of Timed-presence status is below:

   <presence xmlns="urn:ietf:params:xml:ns:pidf"
      xmlns:ts="urn:ietf:params:xml:ns:pidf:timed-status"
      entity="pres:someone@columbia.edu">
      <tuple id="c8dqui">
          <status>
             <basic>open</basic>
          </status>
          <ts:timed-status from="2006-11-04T10:20:00.000-05:00"
                  until="2006-11-08T19:30:00.000-05:00">
              <ts:basic>closed</ts:basic>
          </ts:timed-status>
          <contact>sip:Vishal@cs.columbia.edu</contact>
       </tuple>
       <note>I'll be in San Diego IETF meeting</note>
   </presence>

                  Figure 13: Time-presence status example

   Thus, timed-presence can be used to automatically switch the
   subscription on or off which can lower the presence notification
   traffic.  However, with current watcher filtering specification it is
   not straightforward to automatically enable or disable notifications
   based on calendar information from timed-presence.  Watchers cannot
   specify a watcher filter indicating not to send NOTIFY based on
   timed-status as it would require them to know the 'from'/'until'
   attribute in <timed-status> before hand.  Watcher filtering
   specification does not allow watchers to specify filter rules to
   disable notifications based on comparison of timestamps.  A watcher
   application upon obtaining the <timed-status> can specify a watcher
   filter using the 'from' and 'until' attribute in the received <timed-
   status>, indicating the server not to send a NOTIFY unless the
   <timed-status> or 'from' or 'until' attribute changes.  A watcher
   should not blindly un-subscribe for the time specified in the <timed-
   status> because presentity may update the time-status and watcher may
   not be aware of this.  Hence, watcher must specify a watcher filter
   which triggers a notification upon changes in elements of <timed-
   status>, after it has received the first <timed-status>.  Once the
   interval for the received <timed-status> is over, the watcher



Houri, et al.            Expires August 30, 2007               [Page 37]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


   application removes the filter and starts receiving notifications in
   a normal manner.  However, differential notification can be used to
   know about changes in the timed-presence.  From the above discussion,
   it is clear that watcher filtering specification requires
   enhancements for timestamp based watcher filters.

7.4.  On-Demand presence (Fetch or Pull Model)

   Watchers need not be notified about every presence update of all the
   contacts at all times.  Watchers may be interested in regularly
   receiving presence updates for some of their contacts.  But for other
   contacts, watchers may only want to know their presence information
   when they want to start a communication session.  This can be labeled
   as on-demand presence and can be accomplished by using fetch based
   SUBSCRIBE with expiration interval set to zero.  This approach
   requires a mechanism in the watcher application to enable watchers to
   indicate that they are not interested in regular presence updates,
   rather they only require presence information when starting a new
   session.  Examples may include services, where presence status does
   not have to be seen or known to a watcher all of the time.  For
   example, a cell-phone associated watcher may need presence updates
   only when the cell-phone application (e.g., phone book) runs in the
   foreground on the device.  Another example is a presence-based call
   routing in telephony, where - before the call is delivered - a
   watcher issues a fetch-based SUBSCRIBE to learn whether and where the
   callee is available.

7.5.  Adapting the subscription rate

   The rate of notification can be adjusted based on statistical
   information about past multimedia sessions with user's contacts.
   This can be initiated by the client or can be automatically done by
   the server as server can procure such information based on stored
   call and text session information.  As a matter of fact, 60-70% of
   the calls/IM messages are sent to 20% of the contacts [Reference
   required, Observation based on call detail records of friends].
   Nearly 50% of the buddies are called rarely.  This may include
   buddies from old office, old college, and old city who are present in
   the buddy list but are not contacted actively.  Based on such
   information the presence server or the client can adapt the
   subscription rate and use the fetch model for such buddies.

7.6.  Other Optimizations

   This section lists and discusses several other optimizations either
   are already part of the SIMPLE protocol or they have been suggested
   in various drafts. the current protocol optimizations that have been
   defined, are being worked on or are suggested.



Houri, et al.            Expires August 30, 2007               [Page 38]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


   o  Subnot-etags - Draft [20].  This draft suggests ways to suppress
      the sending of unnecessary notifies when for example a
      subscription is refreshed.  This suggestion seems to be an
      efficient optimization since it saves both the number of messages
      sent and on the processing time of the presence server.

   o  Resource List Service - [12] enable creating a single subscription
      session between the watcher and the presence server for
      subscribing on a list of users.  This saves the amount of sessions
      that are created between watchers and presence servers.  On the
      other hand, this mechanism enables creating very large amount of
      subscriptions in the presence server/RLS system thus enabling the
      creation of a very large number of subscriptions between presence
      servers and RLSs with relatively few clients especially if large
      public groups are used.  It seems that in order to really optimize
      in this area, the usage of large public groups should not be
      considered as BCP and there should be a way for an RLS to create a
      single subscription for multiple occurrences of the same resource
      in resource lists.  See consolidates subscriptions below.

   o  Partial notify/publish - Drafts [13], [14] define a way for the
      subscriber to request getting only what was changed in the
      presence document and for the publisher of presence information to
      publish only what was changed in the presence document since the
      last publish.  Although these optimizations help in reducing the
      amount of actual data that is sent from/to the presence server,
      these optimizations create additional processing burden on the
      presence server as was discussed above.

   o  Filtering as defined in RFCs [10], [11] enables a watcher to
      request to be notified only when the presence document fulfills
      certain conditions.  Although this optimization enables saving on
      the amount of messages that are sent from the presence server to
      the watcher, this optimization puts more burden on the processing
      time of the presence server as was discussed above.

   o  Throttling
      [http://tools.ietf.org/html/draft-niemi-sipping-event-throttle-04
      - expired at the time of the writing of this document] 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.



Houri, et al.            Expires August 30, 2007               [Page 39]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


   o  Presence specific sigcomp dictionary [17] defines a SIGCOMP [3]
      dictionary for presence.  This optimization will enable to reduce
      the number of bytes that are transferred in presence systems by
      compressing the textual SIP messages and using the specialized
      presence dictionary the compression may be more significant then
      just using SIGCOMP as is.  Note that number of actual messages
      will remain the same and a calculation of the amount of bytes that
      will be saved may be useful here.

   o  Content Indirection [9] enables sending only the URI of the
      presence document to the watcher thus offloading the presence
      server from sending the presence document to the watcher.  This
      optimization may be useful in some cases but in reality it may
      have several drawbacks:

      1.  Due to partial/privacy/filtering and other functionalities, it
          will be relatively a rare case where many watchers will get
          exactly the same presence document.

      2.  There should be a mechanism that will enable removing the
          content from the content server at the appropriate time.
          Defining the appropriate time is far from trivial since the
          removal should be synchronized with all the watcher that need
          to get the content.

   o  Resubscription to resource list [12] requires that a full state
      will be sent for subscribe refreshes.  In large resource lists the
      amount of data that needs to be sent for each subscribe refresh
      may be very big.  Having an optimization that will enable sending
      only partial information at subscribe refreshes may let RLS
      subscriptions be more optimized.

   o  No Resubscriptions - Due to the nature of SIP that is network
      agnostic and always assumes the worst for the network layer,
      resubscriptions are part of the SIP sub/notify model [2].  In many
      cases it should be possible to negotiate a special connection
      between watchers and presence servers, this type of connection
      will use a different mechanism of e.g. keep alives and will not
      necessitate resubscribes.  This will be mostly important between
      presence domains and between RLSs and presence servers and may
      save many messages.










Houri, et al.            Expires August 30, 2007               [Page 40]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


8.  Extremely Optimized  Model

   The following calculations are made assuming that the following
   optimizations are deployed:

   o  No resubscriptions are necessary.

   o  Consolidates Subscriptions are possible.

   The following table shows the amount of messages that are required in
   this model using the very large network model numbers.  We assume
   that even though there are 10M watchers from one domain to the other,
   the number of actually watched resources is only 3M.

   (A01) Subscription lifetime (hours)..............................8
   (A02) Presence state changes / hour..............................6
   (A03) Subscription refresh interval / hour.......................0
   (A04) Total federated presentities per watcher..................10
   (A05) Number of dialogs to maintain per watcher..................1
   (A06) Number of watchers in a federated presence domain.10,000,000
   (A06-1) Number of resources watched......................3,000,000

   (A07) Initial SUBSCRIBE/200 per watcher..........................2
   (A08) Initial NOTIFY/200 per watcher.............................2
   (A09) Total initial messages............................12,000,000

   (A10) NOTIFY/200 per watched presentity........................960
   (A11) SUBSCRIBE/200 refreshes....................................0
   (A12) NOTIFY/200 due to subscribe refresh........................0
   (A13) Number of steady state messages................2,880,000,000

   (A14) SUBSCRIBE termination......................................2
   (A15) NOTIFY terminated..........................................2
   (A16) Number of sign-out messages.......................12,000,000

   (A17) Total messages between domains.................5,808,000,000
   (A18) Total number of messages / second....................201,333
   (A19) Total number of bytes / second on the wire.........402,083KB

     Figure 14: Very large network peering with extreme optimizations

   Note that we get almost a 3 fold less messages by only assuming that
   10M watchers subscribe to 3M resources while consolidated
   subscriptions are possible.  However, since the NOTIFY messages are
   big then the saving in the bandwidth is not so big.  Due to the usage
   of the subnot-etags [20] optimization the total removal of
   resubscribes does not save many messages as the following table
   shows:



Houri, et al.            Expires August 30, 2007               [Page 41]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


   (A01) Subscription lifetime (hours)..............................8
   (A02) Presence state changes / hour..............................6
   (A03) Subscription refresh interval / hour.......................1
   (A04) Total federated presentities per watcher..................10
   (A05) Number of dialogs to maintain per watcher..................1
   (A06) Number of watchers in a federated presence domain.10,000,000
   (A06-1) Number of resources watched......................3,000,000

   (A07) Initial SUBSCRIBE/200 per watcher..........................2
   (A08) Initial NOTIFY/200 per watcher.............................2
   (A09) Total initial messages............................12,000,000

   (A10) NOTIFY/200 per watched presentity........................960
   (A11) SUBSCRIBE/200 refreshes...................................16
   (A12) NOTIFY/200 due to subscribe refresh........................0
   (A13) Number of steady state messages................2,928,000,000

   (A14) SUBSCRIBE termination......................................2
   (A15) NOTIFY terminated..........................................2
   (A16) Number of sign-out messages.......................12,000,000

   (A17) Total messages between domains.................5,904,000,000
   (A18) Total number of messages / second....................205,000
   (A19) Total number of bytes / second on the wire.........402,088KB

      Figure 15: Very large network extreme optimizations+resubscribe

   "Only" additional 3.5K messages per second are needed if we re-
   introduce re-subscriptions, since the subnot-etags [20] optimization
   is used.

   Note that even other protocols that do not require subscription
   refreshes etc. will have "hard time" bettering the above scalability
   calculation

















Houri, et al.            Expires August 30, 2007               [Page 42]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


9.  Suggested Requirements

   In the previous sections we have shown several areas where the
   deployment of a presence system is far from being trivial, these
   include network load, memory load and CPU load.  In this section we
   are listing an initial set of requirements to a possible
   optimizations in this area.

   Backward compatibility requirements

   o  The solution should not hinder the ability of existing SIMPLE
      clients and/or servers from peering with a domain or client
      implementing the solution.  No changes may be required of existing
      servers to interoperate

   o  It does NOT constrain any existing RFC functional or security
      requirements for presence

   o  Systems that are not using the new additions to the protocol
      should operate at the same level as they do today

   Policy, privacy, permissions requirements

   o  The solution does not limit the ability for presentities to
      present different views of presence to different watchers

   o  The solution does not restrict the ability of a presentity to
      obtain its list of watchers

   o  The solution MUST NOT create any new or make worse any existing
      privacy holes

   Scalability requirements

   o  It is highly desirable for any presence system (intra or inter-
      domain) to scale linearly as number of watchers and presentities
      increase linearly

   o  The solution SHOULD NOT require significantly more state in order
      to implement the solution

   o  It MUST be able to scale to tens of millions of concurrent users
      in each domain and in each peer domain

   o  It MUST support a very high level of watcher/presentity
      intersections in various intersection models





Houri, et al.            Expires August 30, 2007               [Page 43]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


   o  Protocol changes MUST NOT prohibit optimizations in different
      deployment models esp. where there is a high level of cross
      subscriptions between the domains

   o  New functionalities and extensions to the presence protocol SHOULD
      take into account scalability with respect to the number of
      messages, state size and management and processing load.

   Topology requirement

   o  The solution SHOULD allow for arbitrary federation topologies
      including direct peering and intermediary routing







































Houri, et al.            Expires August 30, 2007               [Page 44]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


10.  Conclusions

   The document analysis 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.

   Several optimizations are suggested or are surveyed in this document.
   It is important to note that not every optimization is really an
   optimization and some of them may seem to optimize in one place while
   they actually create load in other parts of the system.

   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.









Houri, et al.            Expires August 30, 2007               [Page 45]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


11.  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 are discussed in theory in this
   document will most probably have security implications that will need
   to be solved.











































Houri, et al.            Expires August 30, 2007               [Page 46]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


12.  Acknowledgments

   We would like to thank Jonathan Rosenberg (Cisco), Markus Isomaki
   (Nokia) Piotr Boni (Verizon), David Viamonte (Genaker) and Aki Niemi
   (Nokia) for their ideas and input.














































Houri, et al.            Expires August 30, 2007               [Page 47]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


13.  References

13.1.  Normative References

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

13.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 Presence Event Package for the Session
         Initiation Protocol (SIP)", RFC 3856, August 2004.

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

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

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

   [8]   Schulzrinne, H., "Timed Presence Extensions to the Presence
         Information Data Format (PIDF) to Indicate Status Information
         for Past and Future Time Intervals", RFC 4481, July 2006.

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

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

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

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



Houri, et al.            Expires August 30, 2007               [Page 48]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


   [13]  Lonnfors, M., "Session Initiation Protocol (SIP) extension for
         Partial Notification of  Presence Information",
         draft-ietf-simple-partial-notify-08 (work in progress),
         July 2006.

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

   [15]  Rosenberg, J., "Presence Authorization Rules",
         draft-ietf-simple-presence-rules-08 (work in progress),
         October 2006.

   [16]  Urpalainen, J., "An Extensible Markup Language (XML) Patch
         Operations Framework Utilizing XML  Path Language (XPath)
         Selectors", draft-ietf-simple-xml-patch-ops-02 (work in
         progress), March 2006.

   [17]  Garcia-Martin, M., "The Presence-specific Dictionary for the
         Signaling Compression (Sigcomp)  Framework",
         draft-garcia-simple-presence-dictionary-01 (work in progress),
         December 2006.

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

   [19]  Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE
         Requests in the Session Initiation Protocol  (SIP)",
         draft-ietf-sip-uri-list-message-01 (work in progress),
         January 2007.

   [20]  Niemi, A., "An Extension to Session Initiation Protocol (SIP)
         Events for Issuing  Conditional Subscriptions",
         draft-niemi-sip-subnot-etags-02 (work in progress),
         October 2006.














Houri, et al.            Expires August 30, 2007               [Page 49]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 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


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

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













Houri, et al.            Expires August 30, 2007               [Page 50]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 2007


   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 August 30, 2007               [Page 51]


Internet-Draft      Problem Statement for SIP/SIMPLE       February 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 August 30, 2007               [Page 52]