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

Versions: 00                                                            
SIMPLE WG                                                 A. Houri (Ed.)
Internet-Draft                                                       IBM
Intended status: Standards Track                                V. Singh
Expires: January 2, 2008                                  H. Schulzrinne
                                                             Columbia U.
                                                           S. Parameswar
                                                   Microsoft Corporation
                                                                 E. Aoki
                                                                 AOL LLC
                                                            July 1, 2007


            Scaling Optimizations for Presence in SIP/SIMPLE
      draft-houri-simple-interdomain-scaling-optimizations-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 January 2, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   The document suggests various optimizations for presence that uses
   the SIP/SIMPLE protocol.  The suggestions are based on a separate



Houri (Ed.), et al.      Expires January 2, 2008                [Page 1]


Internet-Draft     Scaling Optimizations for Presence          July 2007


   document that contains scaling analysis and requirements.  The
   current document reviews only suggestions that are not yet part of
   the work of the various SIP working groups while approved and in-work
   optimizations are reviewed in the scaling document.  The intention
   here is to keep these suggestions at this document as a place holder
   until a set of requirements will be discussed and accepted and the
   work on optimizations will commence.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Possible Optimizations . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Common NOTIFY for multiple watchers  . . . . . . . . . . .  3
       2.1.1.  Privacy filtering  . . . . . . . . . . . . . . . . . .  4
       2.1.2.  NOTIFY failure aggregation . . . . . . . . . . . . . .  4
       2.1.3.  Transferring the watcher list  . . . . . . . . . . . .  5
       2.1.4.  Message flow example . . . . . . . . . . . . . . . . .  5
       2.1.5.  SIP message examples for common NOTIFY . . . . . . . .  7
     2.2.  Aggregation of NOTIFY messages (Batched notification)  . .  8
       2.2.1.  Extracting and sending individual NOTIFY using
               Aggregated NOTIFY message body . . . . . . . . . . . .  8
       2.2.2.  Subscription termination and failure indication in
               NOTIFY delivery  . . . . . . . . . . . . . . . . . . .  9
       2.2.3.  Message flow example . . . . . . . . . . . . . . . . .  9
       2.2.4.  SIP message flow example for batched notification  . . 11
     2.3.  Timed presence . . . . . . . . . . . . . . . . . . . . . . 13
     2.4.  On-Demand presence (Fetch or Pull Model) . . . . . . . . . 14
     2.5.  Adapting the subscription rate . . . . . . . . . . . . . . 14
   3.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 14
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   5.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     6.2.  Informational References . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 19














Houri (Ed.), et al.      Expires January 2, 2008                [Page 2]


Internet-Draft     Scaling Optimizations for Presence          July 2007


1.  Introduction

   The document gathers various optimizations for enabling better
   scaling of presence traffic between domains.  The optimizations were
   suggested during the work on the scaling analysis document [6].  The
   intention by this document at this stage is to serve as a place
   holder for the various optimizations until there will be agreement on
   the requirements for scaling and the work on the actual optimizations
   will start.

   Note that most of the optimizations that are suggested here were
   suggested by Vishal Singh and Henning Schulzrine.

   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.


2.  Possible Optimizations

   This section contains suggested 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.

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



Houri (Ed.), et al.      Expires January 2, 2008                [Page 3]


Internet-Draft     Scaling Optimizations for Presence          July 2007


   aggregation and transfer of watcher list to watcher's domain presence
   server to distribute NOTIFY.  We discuss these in next subsections.

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

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



Houri (Ed.), et al.      Expires January 2, 2008                [Page 4]


Internet-Draft     Scaling Optimizations for Presence          July 2007


   Alternatively, application level negative acknowledgement can be
   used.

2.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 [7] specified in partial-
      publication and maintaining the list on presence server in domain
      B. Sending watcher- list and distributing it, is similar to multi
      recipient messages i.e., [8], and SUBSCRIBE contained list or
      Exploders.
   o  Watcher list obtained by subscribing to WINFO [3]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.

2.1.4.  Message flow example

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











Houri (Ed.), et al.      Expires January 2, 2008                [Page 5]


Internet-Draft     Scaling Optimizations for Presence          July 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 (Ed.), et al.      Expires January 2, 2008                [Page 6]


Internet-Draft     Scaling Optimizations for Presence          July 2007


    Figure 1: 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.

2.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 (Ed.), et al.      Expires January 2, 2008                [Page 7]


Internet-Draft     Scaling Optimizations for Presence          July 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 2: SIP message examples using common notify technique

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

2.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 (Ed.), et al.      Expires January 2, 2008                [Page 8]


Internet-Draft     Scaling Optimizations for Presence          July 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 [4]) 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.

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

2.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 (Ed.), et al.      Expires January 2, 2008                [Page 9]


Internet-Draft     Scaling Optimizations for Presence          July 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 (Ed.), et al.      Expires January 2, 2008               [Page 10]


Internet-Draft     Scaling Optimizations for Presence          July 2007


      Figure 3: Message flow for aggregation or batched notification

2.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 (Ed.), et al.      Expires January 2, 2008               [Page 11]


Internet-Draft     Scaling Optimizations for Presence          July 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 4: Message Flow for Aggregation or Batched Notification



Houri (Ed.), et al.      Expires January 2, 2008               [Page 12]


Internet-Draft     Scaling Optimizations for Presence          July 2007


2.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 [5].  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 5: 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 (Ed.), et al.      Expires January 2, 2008               [Page 13]


Internet-Draft     Scaling Optimizations for Presence          July 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.

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

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


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



Houri (Ed.), et al.      Expires January 2, 2008               [Page 14]


Internet-Draft     Scaling Optimizations for Presence          July 2007


   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.


4.  Security Considerations

   One of the biggest sources of traffic between commnunities when
   dealing with presence are multiple notifications on the same
   presentities.  The need for multiple notifications is due to the need
   to provide different presence documents to different watchers
   according to the privacy settings of presentity.  Optimizing the
   traffic between domains will most probably mean delegation of privacy
   handling of users to the other domain.  This is one of the most



Houri (Ed.), et al.      Expires January 2, 2008               [Page 15]


Internet-Draft     Scaling Optimizations for Presence          July 2007


   hardest issues that will need to be solved as part of presence
   optimizations that directly touches the security of users.

   Another security threat is actually coming from the fact that users
   from one community subscribe to users on another community.  The fact
   that there are at least two servers between the users, that the users
   need to trust for the real identity behind the watcher and the real
   identity of the provider of the presence information has to be
   considered while providing solutions for the protocol scalability.


5.  Acknowledgments

   We would like to thank Jonathan Rosenberg, Ben Campbell, Markus
   Isomaki Piotr Boni, David Viamonte and Aki Niemi for their ideas and
   input.


6.  References

6.1.  Normative References

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

6.2.  Informational References

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

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

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

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

   [6]  Houri, A., "Problem Statement for SIP/SIMPLE",
        draft-ietf-simple-interdomain-scaling-analysis-00 (work in
        progress), February 2007.

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



Houri (Ed.), et al.      Expires January 2, 2008               [Page 16]


Internet-Draft     Scaling Optimizations for Presence          July 2007


        progress), March 2006.

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


Authors' Addresses

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

   Email: avshalom@il.ibm.com


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

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


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

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











Houri (Ed.), et al.      Expires January 2, 2008               [Page 17]


Internet-Draft     Scaling Optimizations for Presence          July 2007


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

   Email: Sriram.Parameswar@microsoft.com


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

   Email: aoki@aol.net



































Houri (Ed.), et al.      Expires January 2, 2008               [Page 18]


Internet-Draft     Scaling Optimizations for Presence          July 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

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

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


Intellectual Property

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

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

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


Acknowledgment

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





Houri (Ed.), et al.      Expires January 2, 2008               [Page 19]