draft-ietf-sipcore-presence-scaling-requirements-00.txt   draft-ietf-sipcore-presence-scaling-requirements-01.txt 
SIPPING WG A. Houri SIPPING WG A. Houri
Internet-Draft IBM Internet-Draft IBM
Intended status: Informational S. Parameswar Intended status: Informational S. Parameswar
Expires: October 22, 2009 Microsoft Corporation Expires: January 14, 2010 Microsoft Corporation
E. Aoki E. Aoki
AOL LLC AOL LLC
V. Singh V. Singh
H. Schulzrinne H. Schulzrinne
Columbia U. Columbia U.
April 20, 2009 July 13, 2009
Scaling Requirements for Presence in SIP/SIMPLE Scaling Requirements for Presence in SIP/SIMPLE
draft-ietf-sipcore-presence-scaling-requirements-00.txt draft-ietf-sipcore-presence-scaling-requirements-01.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 22, 2009. This Internet-Draft will expire on January 14, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
The document provides a set of requirements for enabling interdomain The document provides a set of requirements for enabling inter-domain
scaling in presence for SIP/SIMPLE. scaling in presence for SIP/SIMPLE.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Backward Compatibility Requirements . . . . . . . . . . . . 4 3.1. Backward Compatibility Requirements . . . . . . . . . . . . 4
3.2. Policy, Privacy, Permissions Requirements . . . . . . . . . 4 3.2. Policy, Privacy, Permissions Requirements . . . . . . . . . 4
3.3. Scalability Requirements . . . . . . . . . . . . . . . . . 4 3.3. Scalability Requirements . . . . . . . . . . . . . . . . . 4
3.4. Topology Requirements . . . . . . . . . . . . . . . . . . . 5 3.4. Topology Requirements . . . . . . . . . . . . . . . . . . . 5
4. Considerations for Possible Optimizations . . . . . . . . . . . 5 4. Considerations for Possible Optimizations . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Changes from Previous Versions . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Changes in version 01 . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
8.2. Informational References . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informational References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Requirements notation 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
The document lists requirements for optimizations of the SIP/SIMPLE The document lists requirements for optimizations of SIP/SIMPLE. See
protocol. See [I-D.ietf-simple-simple] for the list of RFCs and [I-D.ietf-simple-simple] for the list of RFCs and drafts that are
drafts that are considered as part of the SIP/SIMPLE protocol. These considered as part of SIP/SIMPLE. These optimizations should reduce
optimizations should reduce the load on the network and the presence the load on the network and the presence servers due to inter-domain
servers in interdomain presence subscriptions. The need for the presence subscriptions. The need for the requirements is based on a
requirements is based on a separate scaling analysis document separate scaling analysis document
[I-D.ietf-simple-interdomain-scaling-analysis]. [I-D.ietf-simple-interdomain-scaling-analysis].
The scaling analysis document have shown that there is much room for The scaling analysis document shows that the following aspects of
optimizations in the SIP/SIMPLE protocol. The need for optimizations SIP/SIMPLE can be optimized: the number of bytes sent between two
is in the number of bytes that are sent between two federating federating domains, the number of messages processed, and the amount
domains, the number of messages that need to be processed and the of state managed by the presence server.
amount of state that needs to be managed by the presence servers.
For example, for two peering networks that have total of 20 million For example, for two peering networks that have a total of 20 million
users, we got around 19 billion messages per 8 hours work day that users, we calculated that approximately 19 billion messages per 8
needs to be exchanged between the networks only for supporting the hours work day are exchanged between the networks for the presence
presence service. service.
For very large session peering (150 million subscriptions) we got a For very large session peering (150 million subscriptions), we
state close to a tera byte that needs to be managed by the server in calculated that the presence server needs to manage approximately a
order to manage presence. terabyte of state.
It may be that when deploying a very large systems big resources need It may be that very large systems require the deployment of
to be allocated but we should take into the considration the significant resources, but we should consider the following:
following:
o The assumptions that have been used in the scaling analysis o The scaling analysis document makes moderate assumptions about the
document are very moderate from the aspect of number of presence number of presence status changes per hour and the the size of the
status changes per hour and the the size of the presence document presence document.
that was assumed.
o Even when applying all current drafted and/or RFCd optimizations o Even when applying all optimizations for presence as described by
for presence we still got around 10 billion messages per 8 hours drafts and RFCs, we still calculated around 10 billion messages
work day for a total of 20 million fedearting users. This is good per 8 hours work day for a total of 20 million federating users.
but not enough given the moderate assumptions that we have used This is better than the base case, but not enough given the
and given that when presence will be deployed to a mass market the moderate assumptions and given that, when presence is deployed in
number of federating users will be much more then 20 million a mass market, the number of federating users will be much larger
federating users. than 20 million.
3. Requirements 3. Requirements
This section lists requirements for a solution that will optimize the This section lists the requirements for a solution that optimizes the
interdomain presence loads. The requirements are based on the inter-domain presence loads. The requirements are based on the
presence scaling draft presence scaling draft
[I-D.ietf-simple-interdomain-scaling-analysis]. [I-D.ietf-simple-interdomain-scaling-analysis].
3.1. Backward Compatibility Requirements 3.1. Backward Compatibility Requirements
o REQ-001: The solution SHOULD NOT deprecate existing protocol o REQ-001: The solution SHOULD NOT deprecate existing protocol
mechanisms defined in SIP/SIMPLE. mechanisms defined in SIP/SIMPLE.
o REQ-002: Existing SIP/SIMPLE clients SHOULD be able to communicate o REQ-002: Existing SIP/SIMPLE clients SHOULD be able to communicate
with clients and servers that implement new presence scaling with clients and servers that implement new presence scaling
features. features.
o REQ-003: The solution SHOULD NOT constrain any existing RFC o REQ-003: The solution SHOULD NOT constrain any existing RFC
functional requirements for presence. functional requirements for presence.
o REQ-004: The solution MUST NOT constrain any existing RFC security o REQ-004: The solution MUST NOT constrain any existing RFC security
requirements for presence. requirements for presence.
o REQ-005: Systems that are not using the new additions to the o REQ-005: Systems that do not use the new additions to the protocol
protocol SHOULD operate at the same level as they do today. SHOULD operate at the same level as they do today.
3.2. Policy, Privacy, Permissions Requirements 3.2. Policy, Privacy, Permissions Requirements
o REQ-006: The solution SHOULD NOT limit the ability for o REQ-006: The solution SHOULD NOT limit the ability of presentities
presentities to present different views of presence to different to present different views of presence to different watchers.
watchers.
o REQ-007: The solution SHOULD NOT restrict the ability of a o REQ-007: The solution SHOULD NOT restrict the ability of a
presentity to obtain its list of watchers. presentity to obtain its list of watchers.
o REQ-008: The solution MUST NOT create any new or make worse any o REQ-008: The solution MUST NOT create any new privacy holes or
existing privacy holes. make any existing ones worse.
3.3. Scalability Requirements 3.3. Scalability Requirements
o REQ-009: Presence systems (intra or inter-domain) SHOULD scale in o REQ-009: Presence systems (intra- or inter-domain) SHOULD scale in
linear proportion to the number of watchers and presentities in linear proportion to the number of watchers and presentities in
the system. the system.
o REQ-010: The solution SHOULD NOT require a significant increase in o REQ-010: The solution SHOULD NOT require a significant increase in
the size of state to maintain, compared to the current state size the size of maintained state, compared to the current state size
required by SIP/SIMPLE. required by SIP/SIMPLE.
o REQ-011: The solution MUST allow presence systems to scale. Note: 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 we view scalability on the order of tens of millions of users in
each peer domain. each peer domain.
o REQ-012: There may be various usage patterns when users of one o REQ-012: The solution MUST support a high percentage of watcher/
domain subscribe to users from another domain. It may be that presentity intersections between the domains and it MUST support
only small percentage of users from each domain will subscribe to various intersection models such as either small or large
users from the other domain, it may be that most watchers will be percentage of users from each domain subscribing to users from the
from the other domain while there will be few watchers from the other domain.
same domain. The solution MUST support high percentage of
watcher/presentity intersections between the domains and it MUST
support various intersection models.
o REQ-013: Protocol changes MUST NOT prohibit optimizations in o REQ-013: Protocol changes MUST NOT prohibit optimizations in
deployment models where there is a high level of cross deployment models where there is a high number of inter-domain
subscriptions between the domains. subscriptions.
o REQ-014: New functionalities and extensions to the presence o REQ-014: New functionalities and extensions to the presence
protocol SHOULD take into account scalability with respect to the protocol SHOULD consider scalability with respect to the number of
number of messages, state size and management and processing load. messages, state size, and management and processing load.
3.4. Topology Requirements 3.4. Topology Requirements
o REQ-015: The solution SHOULD allow for arbitrary federation o REQ-015: The solution SHOULD allow for arbitrary federation
topologies including direct and indirect peering. topologies including direct and indirect peering.
4. Considerations for Possible Optimizations 4. Considerations for Possible Optimizations
The document provides an initial list of requirements for a solution This section discusses the possible paths for optimization. One of
of scalability of interdomain presence systems using the SIP/SIMPLE the most important considerations is whether SIP, which was designed
protocol. The issue of scalability was shown in a separate document more as an end-to-end protocol, needs to be optimized for direct
[I-D.ietf-simple-interdomain-scaling-analysis]. interactions between presence servers.
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 It is very possible that the issues described here are inherent to
document are inherent to presence systems in general and not specific presence systems in general and not specific to SIP/SIMPLE.
to the SIP/SIMPLE protocol. Organizations need to be prepared to Organizations need to be prepared to invest substantial resources in
invest substantial resources in the form of networks and hardware in the form of networks and hardware in order to create sizable systems.
order to create sizable systems. However, it is apparent that However, it is apparent that additional protocol optimizations are
additional protocol optimizations are possible and further work is possible and further IETF work is needed in order to provide better
needed in the IETF in order to provide better scalability of large scalability of large presence systems.
presence systems.
We should remember that SIP was originally designed for end to end We should remember that SIP was originally designed for end-to-end
session creation and number and size of messages are of secondary session creation and that the number and size of messages are of
importance for an end to end session negotiation protocol. For large secondary importance for an end-to-end session negotiation protocol.
scale and especially for very large scale presence the number of For large scale and especially for very large scale presence, the
messages that are needed and the size of each message are of extreme number of messages and the size of each message are of extreme
importance. Adequate care must be taken in addressing scalability as importance. Care must be taken to address scalability during the
part of the initial protocol design phase; Trying to to shoehorn initial phase of protocol design; shoehorning scalability at a later
scalability at a later phase will be doomed to failure. phase will be doomed to failure.
We should also consider whether using the same protocol between We should also consider whether using the same protocol between
clients and servers and between servers is a good choice. It may be 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 that, between inter-domain servers or even intra-domain servers (such
between RLSs [RFC4662], and presence servers) there is a need to have as between RLSes [RFC4662] and presence servers), there needs to be a
a different protocol that will be very optimized for the load and can different protocol that is optimized for the load and that can make
assume some assumptions about the network (for example do not use assumptions about the network (using only TCP, for example. In
unreliable protocol as UDP but only TCP, see the section that [I-D.ietf-simple-interdomain-scaling-analysis], see the section that
calculates the number of bytes and messages for imaginary very calculates the number of bytes and messages for an imaginary,
optimized SIP). optimized SIP).
When a presence server connects to another server using the current When a presence server connects to another server using current SIP/
SIP/SIMPLE protocol, there will be an extreme number of redundant SIMPLE, there is an extreme number of redundant messages due to SIP's
messages due to the overhead in the SIP protocol of supporting both support of both TCP and UDP and due to privacy controls that cause
TCP and UDP and due to the need to send multiple presence documents the sending of multiple presence documents for the same presentity.
for the same watched user because of privacy issues. A server to A server-to-server protocol will have to address these issues. Some
server protocol will have to address these issues. Some initial work initial work to address= these issues can be found in:
to address these issues can be found in:
[I-D.ietf-simple-view-sharing] and [I-D.ietf-simple-view-sharing] and
[I-D.ietf-simple-intradomain-federation] and in other (still [I-D.ietf-simple-intradomain-federation] and in other (still
individual) drafts. individual) drafts.
Another issue that is more related to protocol design is whether Another issue related to protocol design is whether NOTIFY messages
NOTIFY messages should not be considered as media just like audio, should not be considered as media just like audio, video, and even
video and even text messaging. The SUBSCRIBE method may be extended text messaging. The SUBSCRIBE method may be extended to negotiate
to negotiate the route and other parameters of the NOTIFY messages, the route and other parameters of the NOTIFY messages, similar to the
in a similar way that the INVITE method negotiates media parameters. way the INVITE method negotiates media parameters. This way, the
This way the load can be offloaded to a specialized NOTIFY "relays" load can be shifted to specialized NOTIFY "relays" and taken off the
thus not loading the control path of SIP. One of the possible ideas control path of SIP. One of the possible ideas (Marc Willekens) is
(Marc Willekens) is to use the SIP protocol for client/server NOTIFY to use SIP for client/server NOTIFY but use a more optimized and
but make use of a more optimized and controllable protocol for the controllable protocol for the server-to-server interface. Another
server-to-server interface. Another possibility is to use the MSRP possibility is to use the MSRP [RFC4975], [RFC4976] protocol for the
[RFC4975], [RFC4976] protocol for the notifications. notifications.
5. Security Considerations 5. Security Considerations
This document discusses scalability requirements for the existing This document discusses the scalability requirements for the existing
SIP/SIMPLE protocol and model. Many of the changes to the protocol SIP/SIMPLE protocol and model. Many of the above-mentioned changes
will have security implications as mentioned in some of the to the protocol will have security implications.
requirements above.
One example of possible protocol changes that may have security For example, a potential protocol change that may have security
implications is sending a presence document only once between domains implications is the single sending of a presence document between
in order to optimize the number of messages and network load. This domains in order to reduce the number of messages and network load.
possible optimization will delegate privacy protection from one This possible optimization will delegate privacy protection from one
domain to another domain and should be addressed when designing domain to the other, and this delegated protection should be
protocol optimizations addressed during design.
Important part of work on the requirements and optimizations will be An important part of work on the requirements and optimizations will
to make sure that all the security aspects are covered. be to ensure that all the security aspects are covered.
6. IANA Considerations 6. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
7. Acknowledgments 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 We would like to thank Jonathan Rosenberg, Ben Campbell, Markus
Isomaki Piotr Boni, David Viamonte, Aki Niemi, Marc Willekens Gonzalo Isomaki Piotr Boni, David Viamonte, Aki Niemi, Marc Willekens, and
Camarillo for their ideas and input. Special thanks to Jean-Francois Gonzalo Camarillo for their ideas and input. Special thanks to Jean-
Mule, Vijay K. Gurbani and Hisham Khartabil for their a detailed Francois Mule, Vijay K. Gurbani and Hisham Khartabil for their a
review. detailed review. Very sprecial thanks A. Jean Mahoney for reviewing
this draft.
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informational References 9.2. Informational References
[I-D.ietf-simple-interdomain-scaling-analysis] [I-D.ietf-simple-interdomain-scaling-analysis]
Houri, A., Aoki, E., Parameswar, S., Rang, T., Singh, V., Houri, A., Aoki, E., Parameswar, S., Rang, T., Singh, V.,
and H. Schulzrinne, "Presence Interdomain Scaling Analysis and H. Schulzrinne, "Presence Interdomain Scaling Analysis
for SIP/SIMPLE", for SIP/SIMPLE",
draft-ietf-simple-interdomain-scaling-analysis-05 (work in draft-ietf-simple-interdomain-scaling-analysis-07 (work in
progress), October 2008. progress), July 2009.
[I-D.ietf-simple-intradomain-federation] [I-D.ietf-simple-intradomain-federation]
Rosenberg, J., Houri, A., Smyth, C., and F. Audet, "Models Rosenberg, J., Houri, A., Smyth, C., and F. Audet, "Models
for Intra-Domain Presence and Instant Messaging (IM) for Intra-Domain Presence and Instant Messaging (IM)
Bridging", draft-ietf-simple-intradomain-federation-03 Bridging", draft-ietf-simple-intradomain-federation-03
(work in progress), March 2009. (work in progress), March 2009.
[I-D.ietf-simple-simple] [I-D.ietf-simple-simple]
Rosenberg, J., "SIMPLE made Simple: An Overview of the Rosenberg, J., "SIMPLE made Simple: An Overview of the
IETF Specifications for Instant Messaging and Presence IETF Specifications for Instant Messaging and Presence
using the Session Initiation Protocol (SIP)", using the Session Initiation Protocol (SIP)",
draft-ietf-simple-simple-05 (work in progress), draft-ietf-simple-simple-05 (work in progress),
March 2009. March 2009.
[I-D.ietf-simple-view-sharing] [I-D.ietf-simple-view-sharing]
Rosenberg, J., Donovan, S., and K. McMurry, "Optimizing Rosenberg, J., Donovan, S., and K. McMurry, "Optimizing
Federated Presence with View Sharing", Federated Presence with View Sharing",
draft-ietf-simple-view-sharing-02 (work in progress), draft-ietf-simple-view-sharing-02 (work in progress),
November 2008. November 2008.
[RFC3857] Rosenberg, J., "A Watcher Information Event Template-
Package for the Session Initiation Protocol (SIP)",
RFC 3857, August 2004.
[RFC3858] Rosenberg, J., "An Extensible Markup Language (XML) Based
Format for Watcher Information", RFC 3858, August 2004.
[RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session
Initiation Protocol (SIP) Event Notification Extension for Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", RFC 4662, August 2006. Resource Lists", RFC 4662, August 2006.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007. Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions
for the Message Sessions Relay Protocol (MSRP)", RFC 4976, for the Message Sessions Relay Protocol (MSRP)", RFC 4976,
September 2007. September 2007.
 End of changes. 39 change blocks. 
144 lines changed or deleted 130 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/