Scaling Requirements for Presence in SIP/SIMPLE
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 January 4, 2009.

Abstract

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

Table of Contents

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

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

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 [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,” August 2009.).

3.  Suggested Requirements

In the presence scaling draft [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,” August 2009.), 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

• REQ-001: The solution SHOULD NOT hinder the ability of existing SIMPLE clients and/or servers from peering with a domain or client implementing the solution. No changes may be required of existing servers to interoperate.
  
  
• REQ-002: The solution SHOULD NOT constrain any existing RFC functional or security requirements for presence.
  
  
• 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

• REQ-004: The solution SHOULD NOT limit the ability for presentities to present different views of presence to different watchers.
  
  
• REQ-005: The solution SHOULD NOT restrict the ability of a presentity to obtain its list of watchers.
  
  
• REQ-006: The solution MUST NOT create any new or make worse any existing privacy holes.
  
  

3.3.  Scalability Requirements

• REQ-007: Presence systems (intra or inter-domain) SHOULD scale in linear proportion to the number of watchers and presentities in the system.
  
  
• REQ-008: The solution SHOULD NOT require significantly more state in order to implement the solution.
  
  
• REQ-009: It MUST be able to scale to tens of millions of concurrent users in each domain and in each peer domain.
  
  
• 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 high percentage of watcher/presentity intersections between the domains and it MUST support various intersection models.
  
  
• 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.
  
  
• 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

• REQ-013: The solution SHOULD allow for arbitrary federation topologies including direct peering and intermediary routing.
  
  

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] (Houri, A., Aoki, E., Parameswar, S., Rang, T., Singh, V., and H. Schulzrinne, “Presence Interdomain Scaling Analysis for SIP/SIMPLE,” August 2009.).

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 substantial resources in the form of networks and hardware in order to create 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 sometimes does not give the right priority to 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] (Roach, A., Campbell, B., and J. Rosenberg, “A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists,” August 2006.)) 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 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 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.houri‑simple‑interdomain‑scaling‑optimizations] (Houri, A., “Scaling Optimizations for Presence in SIP/SIMPLE,” July 2007.), [I‑D.ietf‑simple‑view‑sharing] (Rosenberg, J., Donovan, S., and K. McMurry, “Optimizing Federated Presence with View Sharing,” November 2008.) and [I‑D.ietf‑simple‑intradomain‑federation] (Rosenberg, J., Houri, A., Smyth, C., and F. Audet, “Models for Intra-Domain Presence and Instant Messaging (IM) Bridging,” July 2009.)

Another issue that is more concerning 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 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 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] (Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” September 2007.), [RFC4976] (Jennings, C., Mahy, R., and A. Roach, “Relay Extensions for the Message Sessions Relay Protocol (MSRP),” September 2007.)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 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, Marc Willekens Gonzalo Camarillo for their ideas and input. Special thanks to Vijay K. Gurbani for the a detailed review.

8.  References

8.1. Normative References

8.2. Informational References

Authors' Addresses

Full Copyright Statement

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