TOC 
SIPPING WGA. Houri
Internet-DraftIBM
Intended status: InformationalS. Parameswar
Expires: May 21, 2008Microsoft Corporation
 E. Aoki
 AOL LLC
 V. Singh
 H. Schulzrinne
 Columbia U.
 November 18, 2007


Scaling Requirements for Presence in SIP/SIMPLE
draft-houri-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 May 21, 2008.

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
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.  Conclusions
5.  Security Considerations
6.  Acknowledgments
7.  References
    7.1.  Normative References
    7.2.  Informational References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 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 [1] (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. These optimizations should reduce the traffic in interdomain presence subscriptions. The requirements are based on a separate scaling analysis document [4] (Houri, A., Aoki, E., Parameswar, S., Rang, T., Singh, V., and H. Schulzrinne, “Presence Interdomain Scaling Analysis for SIP/SIMPLE,” August 2009.).



 TOC 

3.  Suggested Requirements

In the presence scaling draft [4] (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.



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

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] (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 a lot in network and hardware in order to create real big 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 not 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 with this problem? It may be that in interdomain or even between servers in the same domain (as between RLSs 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 is connecting to another server using current protocol, there will be an extreme number of redundant messages due to the overhead of supporting UDP and to the need to send multiple presence documents for the same watched user due to privacy issue. A server to server protocol will have to address these issues. Some initial work to address these issues can be found in: [5] (Houri, A., “Scaling Optimizations for Presence in SIP/SIMPLE,” July 2007.), [6] (Rosenberg, J., Donovan, S., and K. McMurry, “Optimizing Federated Presence with View Sharing,” February 2008.) and [7] (Rosenberg, J., “Models for Intra-Domain Presence Federation,” February 2008.)

Another issue that is more concerning protocol design is whether NOTIFY messages should not be considered as media as audio, video and even text messaging are considered? The SUBSCRIBE can be extended to do similar three way handshake as INVITE and negotiate where the notify messages should go, rate and other 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 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] (Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” September 2007.), [3] (Jennings, C., Mahy, R., and A. Roach, “Relay Extensions for the Message Sessions Relay Protocol (MSRP),” September 2007.)protocol for the notifies.



 TOC 

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

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



 TOC 

7.  References



 TOC 

7.1. Normative References

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


 TOC 

7.2. Informational References

[2] Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” RFC 4975, September 2007 (TXT).
[3] Jennings, C., Mahy, R., and A. Roach, “Relay Extensions for the Message Sessions Relay Protocol (MSRP),” RFC 4976, September 2007 (TXT).
[4] 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).
[5] Houri, A., “Scaling Optimizations for Presence in SIP/SIMPLE,” draft-houri-simple-interdomain-scaling-optimizations-00 (work in progress), July 2007 (TXT).
[6] Rosenberg, J., Donovan, S., and K. McMurry, “Optimizing Federated Presence with View Sharing,” draft-rosenberg-simple-view-sharing-01 (work in progress), February 2008 (TXT).
[7] Rosenberg, J., “Models for Intra-Domain Presence Federation,” draft-rosenberg-simple-intradomain-federation-01 (work in progress), February 2008 (TXT).


 TOC 

Authors' Addresses

  Avshalom Houri
  IBM
  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


 TOC 

Full Copyright Statement

Intellectual Property