SIPPING WG                                                      A. Houri
Internet-Draft                                                       IBM
Intended status: Informational                             S. Parameswar
Expires: August 12, 2008 January 4, 2009                           Microsoft Corporation
                                                                 E. Aoki
                                                                 AOL LLC
                                                                V. Singh
                                                          H. Schulzrinne
                                                             Columbia U.
                                                        February 9,
                                                            July 3, 2008

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

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

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

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

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

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

   This Internet-Draft will expire on August 12, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008). January 4, 2009.

Abstract

   The document provides a set of requirements for enabling interdomain
   scaling in presence for SIP/SIMPLE.  The requirements are based on a
   separate scaling analysis document.

Table of Contents

   1.  Requirements notation . . . . . . . . . . . . . . . . . . . . . 3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Suggested Requirements  . . . . . . . . . . . . . . . . . . . . 3
     3.1.  Backward Compatibility Requirements . . . . . . . . . . . . 3
     3.2.  Policy, Privacy, Permissions Requirements . . . . . . . . . 3
     3.3.  Scalability Requirements  . . . . . . . . . . . . . . . . . 3 4
     3.4.  Topology Requirements . . . . . . . . . . . . . . . . . . . 4
   4.  Conclusions  Considerations for Possible Optimizations . . . . . . . . . . . 4
   5.  Security Considerations . . . . . . . . . . . . . . . 4
   5.  Security . . . . . 6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . 5
   6. . . 6
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
   7. 6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     7.1.
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     7.2.
     8.2.  Informational References  . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6 7
   Intellectual Property and Copyright Statements  . . . . . . . . . . 8 9

1.  Requirements notation

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

2.  Introduction

   The document lists requirements for optimizations of the SIP/SIMPLE
   protocol.  These optimizations should reduce the traffic in
   interdomain presence subscriptions.  The requirements are based on a
   separate scaling analysis document [4].
   [I-D.ietf-simple-interdomain-scaling-analysis].

3.  Suggested Requirements

   In the presence scaling draft [4],
   [I-D.ietf-simple-interdomain-scaling-analysis], several areas where
   the deployment of a presence system is far from being trivial are
   described, these include network load, memory load and CPU load.  In
   this section lists an initial set of requirements for a solution that
   will optimize the interdomain presence traffic.

3.1.  Backward Compatibility Requirements

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

   o  REQ-002: It does The solution SHOULD NOT constrain any existing RFC
      functional or security requirements for presence.

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

3.2.  Policy, Privacy, Permissions Requirements

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

   o  REQ-005: The solution does not 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: It is highly desirable for any presence system Presence systems (intra or inter-domain) to SHOULD scale linearly as in
      linear proportion to the number of watchers and presentities increase linearly. in
      the system.

   o  REQ-008: The solution SHOULD NOT require significantly more state
      in order to implement the solution.

   o  REQ-009: It MUST be able to scale to tens of millions of
      concurrent users in each domain and 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
      coming from one domain while there will be few watchers form the
      other domain.  The solution MUST support a very high level percentage of
      watcher/presentity intersections in between the domains and it MUST
      support various intersection models.

   o  REQ-011: Protocol changes MUST NOT prohibit optimizations in
      different deployment models esp. 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 peering and intermediary routing.

4.  Conclusions  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
   [4].
   [I-D.ietf-simple-interdomain-scaling-analysis].

   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
   substantial resources in network the form of networks and hardware in order
   to create real big sizable 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

   Nevertheless, 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 end to end session negotiation.  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.  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 sometimes does not give the right priority
   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 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.  It may be
   that in interdomain or even between servers in the same domain (as
   between RLSs (Resource List Servers [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 (e.g. do not use unreliable protocol as UDP but only TCP).

   When servers a server is connecting to another server using current 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 due to because of privacy issue. issues.  A server to server protocol will
   have to address these issues.  Some initial work to address these
   issues can be found in: [5], [6]
   [I-D.houri-simple-interdomain-scaling-optimizations],
   [I-D.ietf-simple-view-sharing] and [7]
   [I-D.ietf-simple-intradomain-federation]

   Another issue that is more concerning protocol design is whether
   NOTIFY messages should not be considered as media as just like audio,
   video and even text messaging.  The SUBSCRIBE can method may be extended
   to do similar
   three way handshake as INVITE and negotiate where the notify messages
   should go, rate route and other parameters of the NOTIFY messages,
   in a similar way that the INVITE method is negotiating 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 stack protocol for the
   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 [2], [3]protocol [RFC4975], [RFC4976]protocol for the
   notifies.

5.  Security Considerations

   This document discusses scalability requirements for the existing
   SIP/SIMPLE presence 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 delagate 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

   None.

7.  Acknowledgments

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

7.  Special thanks to Vijay K.
   Gurbani for the a detailed review.

8.  References

7.1.

8.1.  Normative References

   [1]

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

7.2.

8.2.  Informational References

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

   [3]  Jennings, C., Mahy, R., and A. Roach, "Relay Extensions

   [I-D.houri-simple-interdomain-scaling-optimizations]
              Houri, A., "Scaling Optimizations for the
        Message Sessions Relay Protocol (MSRP)", RFC 4976,
        September Presence in SIP/
              SIMPLE",
              (work in progress), July 2007.

   [4]

   [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-03 SIP/SIMPLE",
              draft-ietf-simple-interdomain-scaling-analysis-04 (work in
              progress), November 2007.

   [5] February 2008.

   [I-D.ietf-simple-intradomain-federation]
              Rosenberg, J. and A. Houri, A., "Scaling Optimizations "Models for Intra-Domain
              Presence in SIP/SIMPLE",
        draft-houri-simple-interdomain-scaling-optimizations-00 Federation",
              draft-ietf-simple-intradomain-federation-00 (work in
              progress), July 2007.

   [6] February 2008.

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

   [7]
              February 2008.

   [RFC4662]  Roach, A., Campbell, B., and J. Rosenberg, J., "Models "A Session
              Initiation Protocol (SIP) Event Notification Extension for Intra-Domain Presence Federation",
        draft-rosenberg-simple-intradomain-federation-00 (work in
        progress), November
              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  Building 18/D
   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
   360 W. Caribbean  Drive
   Sunnyvale, CA  94089
   USA

   Email: aoki@aol.net

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

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

   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.

Acknowledgment

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