SIPPING WG                                                      A. Houri
Internet-Draft                                                       IBM
Intended status: Informational                             S. Parameswar
Expires: January 14, 2010                          Microsoft Corporation
                                                                 E. Aoki
                                                                AOL  LLC
                                                                V. Singh
                                                          H. Schulzrinne
                                                             Columbia U.
                                                           July 13, 2009

            Scaling Requirements for Presence in SIP/SIMPLE

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with 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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 14, 2010.

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

Houri, et al.           Expires January 14, 2010                [Page 1]

Internet-Draft      Scaling Requirements for Presence          July 2009


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

Table of Contents

   1.  Requirements notation . . . . . . . . . . . . . . . . . . . . . 3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . . . 4
     3.1.  Backward Compatibility Requirements . . . . . . . . . . . . 4
     3.2.  Policy, Privacy, Permissions Requirements . . . . . . . . . 4
     3.3.  Scalability Requirements  . . . . . . . . . . . . . . . . . 4
     3.4.  Topology Requirements . . . . . . . . . . . . . . . . . . . 5
   4.  Considerations for Possible Optimizations . . . . . . . . . . . 5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Changes from Previous Versions  . . . . . . . . . . . . . . . . 7
     7.1.  Changes in version 01 . . . . . . . . . . . . . . . . . . . 7
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     9.2.  Informational References  . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8

Houri, et al.           Expires January 14, 2010                [Page 2]

Internet-Draft      Scaling Requirements for Presence          July 2009

1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

2.  Introduction

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

   The scaling analysis document shows that the following aspects of
   SIP/SIMPLE can be optimized: the number of bytes sent between two
   federating domains, the number of messages processed, and the amount
   of state managed by the presence server.

   For example, for two peering networks that have a total of 20 million
   users, we calculated that approximately 19 billion messages per 8
   hours work day are exchanged between the networks for the presence

   For very large session peering (150 million subscriptions), we
   calculated that the presence server needs to manage approximately a
   terabyte of state.

   It may be that very large systems require the deployment of
   significant resources, but we should consider the following:

   o  The scaling analysis document makes moderate assumptions about the
      number of presence status changes per hour and the the size of the
      presence document.

   o  Even when applying all optimizations for presence as described by
      drafts and RFCs, we still calculated around 10 billion messages
      per 8 hours work day for a total of 20 million federating users.
      This is better than the base case, but not enough given the
      moderate assumptions and given that, when presence is deployed in
      a mass market, the number of federating users will be much larger
      than 20 million.

Houri, et al.           Expires January 14, 2010                [Page 3]

Internet-Draft      Scaling Requirements for Presence          July 2009

3.  Requirements

   This section lists the requirements for a solution that optimizes the
   inter-domain presence loads.  The requirements are based on the
   presence scaling draft

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

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

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

   o  REQ-005: Systems that do not use 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 of presentities
      to present different views of presence to different watchers.

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

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

3.3.  Scalability Requirements

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

   o  REQ-010: The solution SHOULD NOT require a significant increase in
      the size of maintained state, compared to the current state size
      required by SIP/SIMPLE.

Houri, et al.           Expires January 14, 2010                [Page 4]

Internet-Draft      Scaling Requirements for Presence          July 2009

   o  REQ-011: 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-012: The solution MUST support a high percentage of watcher/
      presentity intersections between the domains and it MUST support
      various intersection models such as either small or large
      percentage of users from each domain subscribing to users from the
      other domain.

   o  REQ-013: Protocol changes MUST NOT prohibit optimizations in
      deployment models where there is a high number of inter-domain

   o  REQ-014: New functionalities and extensions to the presence
      protocol SHOULD consider scalability with respect to the number of
      messages, state size, and management and processing load.

3.4.  Topology Requirements

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

4.  Considerations for Possible Optimizations

   This section discusses the possible paths for optimization.  One of
   the most important considerations is whether SIP, which was designed
   more as an end-to-end protocol, needs to be optimized for direct
   interactions between presence servers.

   It is very possible that the issues described here are inherent to
   presence systems in general and not specific to SIP/SIMPLE.
   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 IETF work is needed 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 that the 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 and the size of each message are of extreme
   importance.  Care must be taken to address scalability during the
   initial phase of protocol design; shoehorning scalability at a later

Houri, et al.           Expires January 14, 2010                [Page 5]

Internet-Draft      Scaling Requirements for Presence          July 2009

   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, between inter-domain servers or even intra-domain servers (such
   as between RLSes [RFC4662] and presence servers), there needs to be a
   different protocol that is optimized for the load and that can make
   assumptions about the network (using only TCP, for example.  In
   [I-D.ietf-simple-interdomain-scaling-analysis], see the section that
   calculates the number of bytes and messages for an imaginary,
   optimized SIP).

   When a presence server connects to another server using current SIP/
   SIMPLE, there is an extreme number of redundant messages due to SIP's
   support of both TCP and UDP and due to privacy controls that cause
   the sending of multiple presence documents for the same presentity.
   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 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, similar to the
   way the INVITE method negotiates media parameters.  This way, the
   load can be shifted to specialized NOTIFY "relays" and taken off the
   control path of SIP.  One of the possible ideas (Marc Willekens) is
   to use SIP for client/server NOTIFY but use a more optimized and
   controllable protocol for the server-to-server interface.  Another
   possibility is to use the MSRP [RFC4975], [RFC4976] protocol for the

5.  Security Considerations

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

   For example, a potential protocol change that may have security
   implications is the single sending of a presence document between
   domains in order to reduce the number of messages and network load.
   This possible optimization will delegate privacy protection from one
   domain to the other, and this delegated protection should be
   addressed during design.

Houri, et al.           Expires January 14, 2010                [Page 6]

Internet-Draft      Scaling Requirements for Presence          July 2009

   An important part of work on the requirements and optimizations will
   be to ensure that all the security aspects are covered.

6.  IANA Considerations

   This document has no IANA actions.

7.  Changes from Previous Versions

7.1.  Changes in version 01

   Editorial language changes.

8.  Acknowledgments

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

9.  References

9.1.  Normative References

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

9.2.  Informational References

              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-07 (work in
              progress), July 2009.

              Rosenberg, J., Houri, A., Smyth, C., and F. Audet, "Models
              for Intra-Domain Presence and Instant Messaging (IM)
              Bridging", draft-ietf-simple-intradomain-federation-03
              (work in progress), March 2009.

Houri, et al.           Expires January 14, 2010                [Page 7]

Internet-Draft      Scaling Requirements for Presence          July 2009

              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-05 (work in progress),
              March 2009.

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

   [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
   3 Pekris Street, Science Park


   Sriram Parameswar
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052


Houri, et al.           Expires January 14, 2010                [Page 8]

Internet-Draft      Scaling Requirements for Presence          July 2009

   Edwin Aoki
   401 Ellis St.
   Mountain View, CA  94043


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


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

   Phone: +1 212 939  7004

Houri, et al.           Expires January 14, 2010                [Page 9]