SIPPING WG                                                      A. Houri
Internet-Draft                                                       IBM
Intended status: Informational                             S. Parameswar
Expires: May 6, July 31, 2009                             Microsoft Corporation
                                                                 E. Aoki
                                                                AOL  LLC
                                                                V. Singh
                                                          H. Schulzrinne
                                                             Columbia U.
                                                        November 2, 2008
                                                        January 27, 2009

            Scaling Requirements for Presence in SIP/SIMPLE
        draft-ietf-sipping-presence-scaling-requirements-02.txt
        draft-ietf-sipping-presence-scaling-requirements-03.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she

   This Internet-Draft is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, submitted to IETF in accordance full conformance with Section 6 the
   provisions of BCP 78 and BCP 79.

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

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

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

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

   This Internet-Draft will expire on May 6, July 31, 2009.

Copyright Notice

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

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

Abstract

   The document provides a set of requirements for enabling interdomain
   scaling in presence for SIP/SIMPLE.

Table of Contents

   1.  Requirements notation . . . . . . . . . . . . . . . . . . . . . 3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     2.1.  Very large network peering . . . . . . . . . . . . . . . .  3
     2.2.  State Management . . . . . . . . . . . . . . . . . . . . .  8
       2.2.1.  State Size Calculations  . . . . . . . . . . . . . . .  8
   3.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . . . 10 4
     3.1.  Backward Compatibility Requirements . . . . . . . . . . . 10 . 4
     3.2.  Policy, Privacy, Permissions Requirements . . . . . . . . 11 . 4
     3.3.  Scalability Requirements  . . . . . . . . . . . . . . . . . 11 4
     3.4.  Topology Requirements . . . . . . . . . . . . . . . . . . 12 . 5
   4.  Considerations for Possible Optimizations . . . . . . . . . . 12
     4.1.  Very Optimized SIP . . . . . . . . . . . . . . . . . . . . 13 5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . 18 . 7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 . 7
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 . 7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 19 7
     8.2.  Informational References  . . . . . . . . . . . . . . . . . 19 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 20
   Intellectual Property and Copyright Statements . . . . . . . . . . 22 8

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

2.  Introduction

   The document lists requirements for optimizations of the SIP/SIMPLE
   protocol.  See [I-D.ietf-simple-simple] for the list of RFCs and
   drafts that are considered as part of the SIP/SIMPLE protocol.  These
   optimizations should reduce the load on the network and the presence
   servers in interdomain presence subscriptions.  The need for the
   requirements are is based on a separate scaling analysis document
   [I-D.ietf-simple-interdomain-scaling-analysis].

   The scaling analysis document have shown that there is much room for
   optimizations in the SIP/SIMPLE protocol.  The need for optimizations
   is in the number of by teds bytes that are sent between two federating
   domains, the number of messages that need to be processed and the
   amount of state that needs to be managed by the presence servers.
   The following is a snaphot of various numbers from the scaling
   analysis document.  This snapshot is in clouded here

   For example, for
   completeness, please refer two peering networks that have total of 20 million
   users, we got around 19 billion messages per 8 hours work day that
   needs to be exchanged between the scaling analysis document networks only for supporting the
   full details including the description of the calculations and the
   various SIP optimizations investigated.

2.1.  Very large network peering

   In this environment, two or more
   presence service.

   For very large networks create a session peering
   relationship allowing their users (150 million subscriptions) we got a
   state close to subscribe a tera byte that needs to presence in the
   other domains.  Where as be managed by the number of users server in other deployment
   types ranges from hundreds to several hundred thousand, these large
   networks host up
   order to hundreds of millions of users.  Examples of these
   networks are manage presence.

   It may be that when deploying a very large wireless carriers and consumer IM networks.

   Common characteristics of this deployment are:

   o  As users become accustomed systems big resources need
   to network boundaries disappearing,
      federated subscriptions become as common as subscriptions within be allocated but we should take into the same domain
   o  Individual users are highly likely to want to see presence of
      multiple presentities in considration the peer network
   following:

   o  The intersection of users assumptions that have been used in the deployment watching the same
      presentities is very high (i.e., two or more users in network A scaling analysis
      document are extremely likely to be watching a same user in network B)
   o  Status very moderate from the aspect of number of presence
      status changes increase greatly due to typical observed consumer
      behavior

   The first table below provides per hour and the calculations without optimizations the second table provides size of the calculations with optimizations. presence document
      that was assumed.

   o  Even
   though the when applying all current drafted and/or RFCd optimizations help
      for presence we still got around 10 billion messages per 8 hours
      work day for a lot (almost cut the number total of
   messages by half), 20 million fedearting users.  This is good
      but not enough given the numbers are still very high.  Note also moderate assumptions that
   the bandwidth required is very high.

   ** Constants
   (C01) Subscription lifetime (hours)...........................8
   (C02) Presence state changes / hour...........................6
   (C03) Subscription refresh interval / hour....................1
   (C04) Total federated presentities per watcher...............10
   (C05) Number of dialogs we have used
      and given that when presence will be deployed to maintain per watcher..............10
   (C06) Total a mass market the
      number of watchers in domains............20,000,000
   (C07) SUBSCRIBE message size in bytes.......................450
   (C08) 200 OK federating users will be much more then 20 million
      federating users.

3.  Requirements

   This section lists requirements for SUBSCRIBE message size in bytes............370
   (C09) NOTIFY message size not including a solution that will optimize the
   interdomain presence doc........500
   (C10) 200 OK for NOTIFY message size in bytes...............370
   (C11) Size of an average loads.  The requirements are based on the
   presence document..................350

   ** Initial Messages
   (I01) Initial SUBSCRIBE msgs per watcher.....................10
   (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher............10
   (I03) Initial NOTIFY msgs per watcher........................10
   (I04) Initial 200 OK msgs (NOTIFY) per watcher...............10
   (I05) Total number & bytes of initial SUBSCRIBE msgs
             Number of msgs for all watchers...........200,000,000
             Bytes scaling draft
   [I-D.ietf-simple-interdomain-scaling-analysis].

3.1.  Backward Compatibility Requirements

   o  REQ-001: The solution SHOULD NOT deprecate existing protocol
      mechanisms defined in SIP/SIMPLE.

   o  REQ-002: Existing SIP/SIMPLE clients SHOULD be able to communicate
      with clients and servers that implement new presence scaling
      features.

   o  REQ-003: The solution SHOULD NOT constrain any existing RFC
      functional requirements for all watchers.................90,000,000,000
   (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
             Number of msgs presence.

   o  REQ-004: The solution MUST NOT constrain any existing RFC security
      requirements for all watchers...........200,000,000
             Bytes presence.

   o  REQ-005: Systems that are not using the new additions to the
      protocol SHOULD operate at the same level as they do today.

3.2.  Policy, Privacy, Permissions Requirements

   o  REQ-006: The solution SHOULD NOT limit the ability for all watchers.................74,000,000,000
   (I07) Total number & bytes of initial NOTIFY msgs
             Number
      presentities to present different views of msgs for all watchers...........200,000,000
             Bytes for all watchers................170,000,000,000
   (I08) Total number & bytes presence to different
      watchers.

   o  REQ-007: The solution SHOULD NOT restrict the ability of initial 200 OK (NOTIFY) msgs
             Number a
      presentity to obtain its list of msgs for all watchers...........200,000,000
             Bytes for all watchers.................74,000,000,000
   (I09) Total watchers.

   o  REQ-008: The solution MUST NOT create any new or make worse any
      existing privacy holes.

3.3.  Scalability Requirements

   o  REQ-009: Presence systems (intra or inter-domain) SHOULD scale in
      linear proportion to the number & bytes of initial messages per day
             Number watchers and presentities in
      the system.

   o  REQ-010: The solution SHOULD NOT require a significant increase in
      the size of msgs for all watchers...........800,000,000
             Bytes for all watchers................408,000,000,000

   ** Steady State Messages
   (S01) NOTIFY msgs due to state change
             per watched presentity per day.....................46
   (S02) 200 (for NOTIFY due to maintain, compared to the current state change) msgs
             per watched presentity per day.....................46
   (S03) Total number and size of msgs due
      required by SIP/SIMPLE.

   o  REQ-011: The solution MUST allow presence systems to state change per day
             Number scale.  Note:
      we view scalability on the order of msgs for all watchers........18,400,000,000
             Bytes for all watchers.............11,224,000,000,000
   (S04) Number tens of SUBSCRIBE msgs for refreshes
             per watcher per day................................70
   (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
             per watcher per day................................70
   (S06) Number millions of NOTIFY msgs for refreshes
             per watcher per day................................70
   (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
             per watcher per day................................70
   (S08) Total number and size users in
      each peer domain.

   o  REQ-012: There may be various usage patterns when users of msgs due one
      domain subscribe to SUBSCRIBE refreshes
             Number users from another domain.  It may be that
      only small percentage of msgs for all users from each domain will subscribe to
      users from the other domain, it may be that most watchers per day.5,600,000,000
             Bytes for all will be
      from the other domain while there will be few watchers per day......2,856,000,000,000
   (S09) Total number & bytes from the
      same domain.  The solution MUST support high percentage of steady messages per day
             Number
      watcher/presentity intersections between the domains and it MUST
      support various intersection models.

   o  REQ-013: Protocol changes MUST NOT prohibit optimizations in
      deployment models where there is a high level of msgs for all watchers........24,000,000,000
             Bytes for all watchers.............14,080,000,000,000

   ** Termination Messages
   (T01) Terminating SUBSCRIBE msgs per watcher.................10
   (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........10
   (T03) Terminating NOTIFY msgs per watcher....................10
   (T04) Terminating 200 OK msgs (NOTIFY) per watcher...........10
   (T05) Total cross
      subscriptions between the domains.

   o  REQ-014: New functionalities and extensions to the presence
      protocol SHOULD take into account scalability with respect to the
      number & bytes of Terminating SUBSCRIBE msgs
             Number of msgs messages, state size and management and processing load.

3.4.  Topology Requirements

   o  REQ-015: The solution SHOULD allow for all watchers...........200,000,000
             Bytes arbitrary federation
      topologies including direct and indirect peering.

4.  Considerations for all watchers.................90,000,000,000
   (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
             Number Possible Optimizations

   The document provides an initial list of msgs for all watchers...........200,000,000
             Bytes requirements for all watchers.................74,000,000,000
   (T07) Total number & bytes a solution
   of terminating NOTIFY msgs
             Number scalability of msgs for all watchers...........200,000,000
             Bytes for all watchers................170,000,000,000
   (T08) Total number & bytes interdomain presence systems using the SIP/SIMPLE
   protocol.  The issue of terminating 200 OK (NOTIFY) msgs
             Number scalability was shown in a separate document
   [I-D.ietf-simple-interdomain-scaling-analysis].

   The following is a discussion of msgs for all watchers...........200,000,000
             Bytes the various possible paths for all watchers.................74,000,000,000
   (T09) Total number & bytes of terminating messages per day
             Number of msgs for all watchers...........800,000,000
             Bytes for all watchers................408,000,000,000

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

        Figure 1: Very large network peering with no optimizations

   ** Constants
   (C01) Subscription lifetime (hours)...........................8
   (C02) Presence state changes / hour...........................6
   (C03) Subscription refresh interval / hour....................1
   (C04) Total federated presentities per watcher...............10
   (C05) Number
   optimizations.  One of dialogs the most important considerations is whether
   there is a need to maintain per watcher...............1
   (C06) Total number of watchers in domains............20,000,000
   (C07) SUBSCRIBE message size in bytes.......................450
   (C08) 200 OK for SUBSCRIBE message size in bytes............370
   (C09) NOTIFY message size not including presence doc........500
   (C10) 200 OK for NOTIFY message size in bytes...............370
   (C11) Size of adapt SIP that was designed more as an average presence document..................350
   (C13) Additional data per document in RLMI..................160
   (C14) Multiparty boundary in RLMI document..................144
   (C15) XML root node in RLMI document........................144

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

   ** Steady State Messages
   (S01) NOTIFY msgs due end to state change
             per watched presentity per day.....................46
   (S02) 200 (for NOTIFY due end
   protocol to state change) msgs
             per watched presentity per day.....................46
   (S03) Total number and size of msgs due be much more optimized when presence server interacts
   directly with another presence server.

   It is very possible that the issues that are described in this
   document are inherent to state change per day
             Number of msgs for all watchers........18,400,000,000
             Bytes for all watchers.............16,670,400,000,000
   (S04) Number of SUBSCRIBE msgs for refreshes
             per watcher per day.................................7
   (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
             per watcher per day.................................7
   (S06) Number of NOTIFY msgs for refreshes
             per watcher per day.................................0
   (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
             per watcher per day.................................0
   (S08) Total number presence systems in general and size of msgs due to SUBSCRIBE refreshes
             Number of msgs for all watchers per day...280,000,000
             Bytes for all watchers per day........114,800,000,000
   (S09) Total number & bytes of steady messages per day
             Number of msgs for all watchers........18,680,000,000
             Bytes for all watchers.............16,785,200,000,000

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

   ** Bottom Line
   (B01) Total of messages between domains..........18,800,000,000
         Total of bytes bet. domains (PD=350)...16,971,960,000,000
         Total of bytes bet. domains (PD=3000)..41,881,960,000,000
   (B02) Total number of messages / second.................652,778
         Total of bytes per second (PD=350)............589,304,167
         Total of bytes per second (PD=3000).........1,454,234,722
   (B03) Total number of by msgs per user/day..................940
         Total number of bytes per user/day (PD=350).......848,598
         Total number of bytes per user/day (PD=3000)....2,094,098
          Figure 2: Very large network peering with optimizations

2.2.  State Management

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

   The presence server has two parallel tasks.

   1.  Maintain the state of the presentities to which watchers
       subscribe.
   2.  Maintain the state of the subscriptions of watchers and provide
       timely updates to the watchers.

   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 [RFC3857], [RFC3858] that is the result of the
      subscription in order to enable watched presentities to see who is
      watching them.

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

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

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

2.2.1.  State Size Calculations

   Assuming the following sizes, the state size is calculated for
   various systems:

   o  Subscription size - 2K bytes.  This includes watcher information
      that need to be created by the presence server for each
      subscription.  This is for each subscription that is done by each
      watcher to each presentity that the watcher is watching.  So if we
      have 10K watchers we should have 10K of these.
   o  Subscribed to resource - 1K bytes (for privacy information and
      other management info).  This is for each presentity that is being
      watched.  No matter how many watchers are watching it.  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.  This is for each presentity that has state other
      then the default empty state.  It does not matter if it is being
      watched or not.

   Tiny System:

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

   The total for tiny system is 82M bytes.

   Medium System:

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

   The total for medium system is 830M bytes.

   Large System:

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

   The total for large system is 38G bytes.

   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.

   The total for very large system is 952G bytes which is a very big
   number for a very dynamic storage as needed by the presence server.

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

   o  Dynamic state - Although the state may seem not so big for
      databases even for the very large system, we need to remember that
      this state is a very dynamic state.  Subscriptions come and go all
      the time, the status of presentities is being updated and so
      forth.  This means that the presence server has to manage its
      state in a medium that is very dynamic and for such large sizes
      this task is not trivial.
   o  Interlinked state - The subscriptions and the subscribed to
      presentities are dependent on each other.  There needs to be a
      link from the presentity to the subscriptions and vice versa.
      There is a need to be a linkage between the Resource List Server
      (RLS [RFC4662]) and the various presence servers that hold the
      presence data.  See section 4.5 in the presence scaling document
      for more details.
   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...

3.  Requirements

   This section lists requirements for a solution that will optimize the
   interdomain presence loads.  The requirements are based on the
   presence scaling draft
   [I-D.ietf-simple-interdomain-scaling-analysis].

3.1.  Backward Compatibility Requirements

   o  REQ-001: The solution SHOULD NOT deprecate existing protocol
      mechanisms defined in SIP/SIMPLE.  The ability of existing SIP/
      SIMPLE clients and/or servers from peering with a domain or a
      client implementing the solution SHOULD be retained with no
      changes required of existing servers to interoperate.

   o  REQ-002-A: The solution SHOULD NOT constrain any existing RFC
      functional requirements for presence.

   o  REQ-002-B: The solution MUST NOT constrain any existing RFC
      security requirements for presence.

   o  REQ-003: Systems that are not using the new additions to the
      protocol SHOULD operate at the same level as they do today.

3.2.  Policy, Privacy, Permissions Requirements

   o  REQ-004: The solution SHOULD NOT limit the ability for
      presentities to present different views of presence to different
      watchers.

   o  REQ-005: The solution SHOULD NOT restrict the ability of a
      presentity to obtain its list of watchers.

   o  REQ-006: The solution MUST NOT create any new or make worse any
      existing privacy holes.

3.3.  Scalability Requirements

   o  REQ-007: Presence systems (intra or inter-domain) SHOULD scale in
      linear proportion to the number of watchers and presentities in
      the system.

   o  REQ-008: The solution SHOULD NOT require significantly more state
      then solutions based on current protocol in order to implement the
      optimizations.

   o  REQ-009: The solution MUST allow presence systems to scale.  Note:
      we view scalability on the order of tens of millions of users in
      each peer domain.

   o  REQ-010: There may be various usage patterns when users of one
      domain subscribe to users from another domain.  It may be that
      only small percentage of users from each domain will subscribe to
      users from the other domain, it may be that most watchers will be
      from the other domain while there will be few watchers from the
      same domain.  The solution MUST support high percentage of
      watcher/presentity intersections between the domains and it MUST
      support various intersection models.

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

   o  REQ-012: 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.

3.4.  Topology Requirements

   o  REQ-013: The solution SHOULD allow for arbitrary federation
      topologies including direct and indirect peering.

4.  Considerations for Possible Optimizations

   The document provides an initial list of requirements for a solution
   of scalability of interdomain presence systems using the SIP/SIMPLE
   protocol.  The issue of scalability was shown in a separate document
   [I-D.ietf-simple-interdomain-scaling-analysis].

   The following is a discussion of the various possible paths for
   optimizations.  One of the most important considerations is whether
   there is a need to adapt SIP that was designed more as an end to end
   protocol to be much more optimized when presence server interacts
   directly with another presence server.

   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 SIP/SIMPLE protocol.  Organizations need to be prepared to
   invest substantial resources in the form of networks and hardware in
   order to create sizable systems.  However, it is apparent that
   additional protocol optimizations are possible and further work is
   needed in the IETF in order to provide better scalability of large
   presence systems.

   We should remember that SIP was originally designed for end to end
   session creation and number and size of messages are of secondary
   importance for an end to end session negotiation protocol.  For large
   scale and especially for very large scale presence the number of
   messages that are needed and the size of each message are of extreme
   importance.  Adequate care must be taken in addressing scalability as
   part of the initial protocol design phase; Trying to to shoehorn
   scalability at a later phase will be doomed to failure.

   We should also consider whether using the same protocol between
   clients and servers and between servers is a good choice.  It may be
   that in interdomain or even between servers in the same domain (as
   between RLSs [RFC4662], 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 (for example do not use
   unreliable protocol as UDP but only TCP, see the section that
   calculates the number of bytes and messages for imaginary very
   optimized SIP).

   When a presence server connects to another server using the current
   SIP/SIMPLE protocol, there will be an extreme number of redundant
   messages due to the overhead in the SIP protocol of supporting both
   TCP and UDP and due to the need to send multiple presence documents
   for the same watched user because of privacy issues.  A server to
   server protocol will have to address these issues.  Some initial work
   to address these issues can be found in:
   [I-D.ietf-simple-view-sharing] and
   [I-D.ietf-simple-intradomain-federation] and in other (still
   individual) drafts.

   Another issue that is more related to protocol design is whether
   NOTIFY messages should not be considered as media just like audio,
   video and even text messaging.  The SUBSCRIBE method may be extended
   to negotiate the route and other parameters of the NOTIFY messages,
   in a similar way that the INVITE method negotiates media parameters.
   This way the load can be offloaded to a specialized NOTIFY "relays"
   thus not loading the control path of SIP.  One of the possible ideas
   (Marc Willekens) is to use the SIP protocol for client/server NOTIFY
   but make use of a more optimized and controllable protocol for the
   server-to-server interface.  Another possibility is to use the MSRP
   [RFC4975], [RFC4976] protocol for the notifications.

4.1.  Very Optimized SIP

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

   The following calculation assumes an imaginary TCP only based version
   of SIP that optimizes the following:

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

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

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

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

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

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

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

   ** Bottom Line
   (B01) Total of messages between domains...........9,260,000,000
         Total of bytes between domains (PD=350).8,809,080,000,000
         Total of bytes bet. domains (PD=3000)...9,339,080,000,000
   (B02) Total number of messages / second.................321,528
         Total of bytes per second (PD=350)............305,870,833
         Total of bytes per second (PD=3000)...........324,273,611
   (B03) Total number of by msgs per user/day..................463
         Total number of bytes per user/day (PD=350).......440,454
         Total number of bytes per user/day (PD=3000)......466,954
   <artwork><![CDATA[

    Figure 3: Very large networks peering, TCP only SIP+Partial+Dialog
                               optimizations

   ** Constants
   (C01) Subscription lifetime (hours)...........................8
   (C02) Presence state changes / hour...........................6
   (C03) Subscription refresh interval / hour....................0
   (C04) Total federated presentities per watcher...............10
   (C05) Number of dialogs not specific
   to maintain per watcher..............10
   (C06) Total number the SIP/SIMPLE protocol.  Organizations need to be prepared to
   invest substantial resources in the form of watchers networks and hardware in domains............20,000,000
   (C07) SUBSCRIBE message size
   order to create sizable systems.  However, it is apparent that
   additional protocol optimizations are possible and further work is
   needed in bytes.......................150
   (C08) 200 OK for SUBSCRIBE message size the IETF in bytes..............0
   (C09) NOTIFY message size not including order to provide better scalability of large
   presence doc........150
   (C10) 200 OK systems.

   We should remember that SIP was originally designed for NOTIFY message end to end
   session creation and number and size in bytes.................0
   (C11) Size of an average presence document..................350
   (C12) Size messages are of secondary
   importance for an average partial end to end session negotiation protocol.  For large
   scale and especially for very large scale presence document..........200

   ** Initial Messages
   (I01) Initial SUBSCRIBE msgs per watcher.....................10
   (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............0
   (I03) Initial NOTIFY msgs per watcher........................10
   (I04) Initial 200 OK msgs (NOTIFY) per watcher................0
   (I05) Total the number & bytes of initial SUBSCRIBE msgs
             Number of msgs for all watchers...........200,000,000
             Bytes for all watchers.................30,000,000,000
   (I06) Total number & bytes
   messages that are needed and the size of initial 200 OK (SUBSCRIBE) msgs
             Number each message are of msgs for all watchers.....................0
             Bytes for all watchers..............................0
   (I07) Total number & bytes extreme
   importance.  Adequate care must be taken in addressing scalability as
   part of the initial NOTIFY msgs
             Number of msgs for all watchers...........200,000,000
             Bytes protocol design phase; Trying to to shoehorn
   scalability at a later phase will be doomed to failure.

   We should also consider whether using the same protocol between
   clients and servers and between servers is a good choice.  It may be
   that in interdomain or even between servers in the same domain (as
   between RLSs [RFC4662], and presence servers) there is a need to have
   a different protocol that will be very optimized for all watchers................100,000,000,000
   (I08) Total the load and can
   assume some assumptions about the network (for example do not use
   unreliable protocol as UDP but only TCP, see the section that
   calculates the number & bytes of initial 200 OK (NOTIFY) msgs
             Number of msgs for all watchers.....................0
             Bytes for all watchers..............................0
   (I09) Total number & bytes of initial and messages per day
             Number of msgs for all watchers...........400,000,000
             Bytes for all watchers................130,000,000,000

   ** Steady State Messages
   (S01) NOTIFY msgs due to state change
             per watched presentity per day.....................46
   (S02) 200 (for NOTIFY due imaginary very
   optimized SIP).

   When a presence server connects to state change) msgs
             per watched presentity per day......................0
   (S03) Total another server using the current
   SIP/SIMPLE protocol, there will be an extreme number and size of msgs redundant
   messages due to state change per day
             Number of msgs for all watchers.........9,200,000,000
             Bytes for all watchers..............3,220,000,000,000
   (S04) Number of SUBSCRIBE msgs for refreshes
             per watcher per day.................................0
   (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
             per watcher per day.................................0
   (S06) Number the overhead in the SIP protocol of NOTIFY msgs for refreshes
             per watcher per day.................................0
   (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
             per watcher per day.................................0
   (S08) Total number supporting both
   TCP and UDP and size of msgs due to SUBSCRIBE refreshes
             Number of msgs for all watchers per day.............0
             Bytes the need to send multiple presence documents
   for all watchers per day......................0
   (S09) Total number & bytes of steady messages per day
             Number the same watched user because of msgs for all watchers.........9,200,000,000
             Bytes for all watchers..............3,220,000,000,000

   ** Termination Messages
   (T01) Terminating SUBSCRIBE msgs per watcher.................10
   (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........0
   (T03) Terminating privacy issues.  A server to
   server protocol will have to address these issues.  Some initial work
   to address these issues can be found in:
   [I-D.ietf-simple-view-sharing] and
   [I-D.ietf-simple-intradomain-federation] and in other (still
   individual) drafts.

   Another issue that is more related to protocol design is whether
   NOTIFY msgs per watcher.....................0
   (T04) Terminating 200 OK msgs (NOTIFY) per watcher............0
   (T05) Total number & bytes of Terminating messages should not be considered as media just like audio,
   video and even text messaging.  The SUBSCRIBE msgs
             Number of msgs for all watchers...........200,000,000
             Bytes for all watchers.................30,000,000,000
   (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
             Number of msgs for all watchers.....................0
             Bytes for all watchers..............................0
   (T07) Total number & bytes method may be extended
   to negotiate the route and other parameters of terminating the NOTIFY msgs
             Number of msgs for all watchers.....................0
             Bytes for all watchers..............................0
   (T08) Total number & bytes messages,
   in a similar way that the INVITE method negotiates media parameters.
   This way the load can be offloaded to a specialized NOTIFY "relays"
   thus not loading the control path of terminating 200 OK (NOTIFY) msgs
             Number SIP.  One of msgs for all watchers.....................0
             Bytes the possible ideas
   (Marc Willekens) is to use the SIP protocol for all watchers..............................0
   (T09) Total number & bytes of terminating messages per day
             Number client/server NOTIFY
   but make use of msgs a more optimized and controllable protocol for all watchers...........200,000,000
             Bytes the
   server-to-server interface.  Another possibility is to use the MSRP
   [RFC4975], [RFC4976] protocol for all watchers.................30,000,000,000

   ** Bottom Line
   (B01) Total of messages between domains...........9,800,000,000
         Total of bytes between domains (PD=350).3,380,000,000,000
         Total of bytes bet. domains (PD=3000)...3,910,280,000,000
   (B02) Total number of messages / second.................340,278
         Total of bytes per second (PD=350)............117,361,111
         Total of bytes per second (PD=3000)...........135,763,889
   (B03) Total number of by msgs per user/day..................490
         Total number of bytes per user/day (PD=350).......169,000
         Total number of bytes per user/day (PD=3000)......195,500

        Figure 4: Very large networks peering, TCP only SIP+Partial
                               optimizations the notifications.

5.  Security Considerations

   This document discusses scalability requirements for the existing
   SIP/SIMPLE protocol and model.  Many of the changes to the protocol
   will have security implications as mentioned in some of the
   requirements above.

   One example of possible protocol changes that may have security
   implications is sending a presence document only once between domains
   in order to optimize the number of messages and network load.  This
   possible optimization will delegate privacy protection from one
   domain to another domain and should be addressed when designing
   protocol optimizations

   Important part of work on the requirements and optimizations will be
   to make sure that all the security aspects are covered.

6.  IANA Considerations

   This document has no IANA actions.

7.  Acknowledgments

   We would like to thank Jonathan Rosenberg, Ben Campbell, Markus
   Isomaki Piotr Boni, David Viamonte, Aki Niemi, Marc Willekens Gonzalo
   Camarillo for their ideas and input.  Special thanks to Jean-Francois
   Mule, Vijay K. Gurbani and Hisham Khartabil for their a detailed
   review.

8.  References

8.1.  Normative References

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

8.2.  Informational References

   [I-D.ietf-simple-interdomain-scaling-analysis]
              Houri, A., Aoki, E., Parameswar, S., Rang, T., Singh, V.,
              and H. Schulzrinne, "Presence Interdomain Scaling Analysis
              for SIP/SIMPLE",
              draft-ietf-simple-interdomain-scaling-analysis-05 (work in
              progress), October 2008.

   [I-D.ietf-simple-intradomain-federation]
              Rosenberg, J., Houri, A., and C. Smyth, C., and F. Audet, "Models
              for Intra-
              Domain Intra-Domain Presence and Instant Messaging (IM) Federation",
              draft-ietf-simple-intradomain-federation-01
              Bridging", draft-ietf-simple-intradomain-federation-02
              (work in progress), July November 2008.

   [I-D.ietf-simple-simple]
              Rosenberg, J., "SIMPLE made Simple: An Overview of the
              IETF Specifications for Instant  Messaging and Presence
              using the Session Initiation Protocol (SIP)",
              draft-ietf-simple-simple-04 (work in progress),
              October 2008.

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

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

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

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

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

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

Authors' Addresses

   Avshalom Houri
   IBM
   3 Pekris Street, Science Park
   Rehovot,
   Israel

   Email: avshalom@il.ibm.com
   Sriram Parameswar
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052
   USA

   Email: Sriram.Parameswar@microsoft.com

   Edwin Aoki
   AOL  LLC
   401 Ellis St.
   Mountain View, CA  94043
   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

   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

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.