TOC 
SIPPING WGA. Houri
Internet-DraftIBM
Intended status: InformationalS. Parameswar
Expires: July 31, 2009Microsoft Corporation
 E. Aoki
 AOL LLC
 V. Singh
 H. Schulzrinne
 Columbia U.
 January 27, 2009


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

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-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 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). 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
2.  Introduction
3.  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




 TOC 

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



 TOC 

2.  Introduction

The document lists requirements for optimizations of the SIP/SIMPLE protocol. See [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),” March 2009.) 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 is 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.).

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

For example, for 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 networks only for supporting the presence service.

For very large session peering (150 million subscriptions) we got a state close to a tera byte that needs to be managed by the server in order to manage presence.

It may be that when deploying a very large systems big resources need to be allocated but we should take into the considration the following:



 TOC 

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



 TOC 

3.1.  Backward Compatibility Requirements



 TOC 

3.2.  Policy, Privacy, Permissions Requirements



 TOC 

3.3.  Scalability Requirements



 TOC 

3.4.  Topology Requirements



 TOC 

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

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] (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 (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] (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.) 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] (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 notifications.



 TOC 

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.



 TOC 

6.  IANA Considerations

This document has no IANA actions.



 TOC 

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.



 TOC 

8.  References



 TOC 

8.1. Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).


 TOC 

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-08 (work in progress), August 2009 (TXT).
[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,” draft-ietf-simple-intradomain-federation-04 (work in progress), July 2009 (TXT).
[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-05 (work in progress), March 2009 (TXT).
[I-D.ietf-simple-view-sharing] Rosenberg, J., Donovan, S., and K. McMurry, “Optimizing Federated Presence with View Sharing,” draft-ietf-simple-view-sharing-02 (work in progress), November 2008 (TXT).
[RFC3857] Rosenberg, J., “A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP),” RFC 3857, August 2004 (TXT).
[RFC3858] Rosenberg, J., “An Extensible Markup Language (XML) Based Format for Watcher Information,” RFC 3858, August 2004 (TXT).
[RFC4662] Roach, A., Campbell, B., and J. Rosenberg, “A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists,” RFC 4662, August 2006 (TXT).
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” RFC 4975, September 2007 (TXT).
[RFC4976] Jennings, C., Mahy, R., and A. Roach, “Relay Extensions for the Message Sessions Relay Protocol (MSRP),” RFC 4976, September 2007 (TXT).


 TOC 

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