draft-ietf-sipping-presence-scaling-requirements-00.txt   draft-ietf-sipping-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: August 12, 2008 Microsoft Corporation Expires: January 4, 2009 Microsoft Corporation
E. Aoki E. Aoki
AOL LLC AOL LLC
V. Singh V. Singh
H. Schulzrinne H. Schulzrinne
Columbia U. Columbia U.
February 9, 2008 July 3, 2008
Scaling Requirements for Presence in SIP/SIMPLE 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 Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 August 12, 2008. This Internet-Draft will expire on January 4, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
The document provides a set of requirements for enabling interdomain The document provides a set of requirements for enabling interdomain
scaling in presence for SIP/SIMPLE. The requirements are based on a scaling in presence for SIP/SIMPLE.
separate scaling analysis document.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Suggested Requirements . . . . . . . . . . . . . . . . . . . . 3 3. Suggested Requirements . . . . . . . . . . . . . . . . . . . . 3
3.1. Backward Compatibility Requirements . . . . . . . . . . . . 3 3.1. Backward Compatibility Requirements . . . . . . . . . . . . 3
3.2. Policy, Privacy, Permissions Requirements . . . . . . . . . 3 3.2. Policy, Privacy, Permissions Requirements . . . . . . . . . 3
3.3. Scalability Requirements . . . . . . . . . . . . . . . . . 3 3.3. Scalability Requirements . . . . . . . . . . . . . . . . . 4
3.4. Topology Requirements . . . . . . . . . . . . . . . . . . . 4 3.4. Topology Requirements . . . . . . . . . . . . . . . . . . . 4
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Considerations for Possible Optimizations . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.2. Informational References . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 8.2. Informational References . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 9
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 [1]. 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 the SIP/SIMPLE
protocol. These optimizations should reduce the traffic in protocol. These optimizations should reduce the traffic in
interdomain presence subscriptions. The requirements are based on a interdomain presence subscriptions. The requirements are based on a
separate scaling analysis document [4]. separate scaling analysis document
[I-D.ietf-simple-interdomain-scaling-analysis].
3. Suggested Requirements 3. Suggested Requirements
In the presence scaling draft [4], several areas where the deployment In the presence scaling draft
of a presence system is far from being trivial are described, these [I-D.ietf-simple-interdomain-scaling-analysis], several areas where
include network load, memory load and CPU load. In this section the deployment of a presence system is far from being trivial are
lists an initial set of requirements for a solution that will described, these include network load, memory load and CPU load. In
optimize the interdomain presence traffic. this section lists an initial set of requirements for a solution that
will optimize the interdomain presence traffic.
3.1. Backward Compatibility Requirements 3.1. Backward Compatibility Requirements
o REQ-001: The solution should not hinder the ability of existing o REQ-001: The solution SHOULD NOT hinder the ability of existing
SIMPLE clients and/or servers from peering with a domain or client SIMPLE clients and/or servers from peering with a domain or client
implementing the solution. No changes may be required of existing implementing the solution. No changes may be required of existing
servers to interoperate. servers to interoperate.
o REQ-002: It does NOT constrain any existing RFC functional or
security requirements for presence. o REQ-002: 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 o REQ-003: Systems that are not using the new additions to the
protocol should operate at the same level as they do today. protocol SHOULD operate at the same level as they do today.
3.2. Policy, Privacy, Permissions Requirements 3.2. Policy, Privacy, Permissions Requirements
o REQ-004: The solution does not limit the ability for presentities o REQ-004: The solution SHOULD NOT limit the ability for
to present different views of presence to different watchers. presentities to present different views of presence to different
o REQ-005: The solution does not restrict the ability of a watchers.
o REQ-005: 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-006: The solution MUST NOT create any new or make worse any o REQ-006: The solution MUST NOT create any new or make worse any
existing privacy holes. existing privacy holes.
3.3. Scalability Requirements 3.3. Scalability Requirements
o REQ-007: It is highly desirable for any presence system (intra or o REQ-007: Presence systems (intra or inter-domain) SHOULD scale in
inter-domain) to scale linearly as number of watchers and linear proportion to the number of watchers and presentities in
presentities increase linearly. the system.
o REQ-008: The solution SHOULD NOT require significantly more state o REQ-008: The solution SHOULD NOT require significantly more state
in order to implement the solution. in order to implement the solution.
o REQ-009: It MUST be able to scale to tens of millions of o REQ-009: It MUST be able to scale to tens of millions of
concurrent users in each domain and in each peer domain. concurrent users in each domain and in each peer domain.
o REQ-010: It MUST support a very high level of watcher/presentity
intersections in various intersection models. 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 high percentage of
watcher/presentity intersections between the domains and it MUST
support various intersection models.
o REQ-011: Protocol changes MUST NOT prohibit optimizations in o REQ-011: Protocol changes MUST NOT prohibit optimizations in
different deployment models esp. where there is a high level of different deployment models esp. where there is a high level of
cross subscriptions between the domains. cross subscriptions between the domains.
o REQ-012: New functionalities and extensions to the presence o REQ-012: New functionalities and extensions to the presence
protocol SHOULD take into account scalability with respect to the protocol SHOULD take into account scalability with respect to the
number of messages, state size and management and processing load. number of messages, state size and management and processing load.
3.4. Topology Requirements 3.4. Topology Requirements
o REQ-013: The solution SHOULD allow for arbitrary federation o REQ-013: The solution SHOULD allow for arbitrary federation
topologies including direct peering and intermediary routing. topologies including direct peering and intermediary routing.
4. Conclusions 4. Considerations for Possible Optimizations
The document provides an initial list of requirements for a solution The document provides an initial list of requirements for a solution
of scalability of interdomain presence systems using the SIP/SIMPLE of scalability of interdomain presence systems using the SIP/SIMPLE
protocol. The issue of scalability was shown in a separate document 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 It is very possible that the issues that are described in this
document are inherent to presence systems in general and not specific document are inherent to presence systems in general and not specific
to the SIMPLE protocol. Organizations need to be prepared to invest to the SIMPLE protocol. Organizations need to be prepared to invest
a lot in network and hardware in order to create real big systems. substantial resources in the form of networks and hardware in order
However, it is apparent that not all the possible optimizations were to create sizable systems. However, it is apparent that not all the
done yet and further work is needed in the IETF in order to provide possible optimizations were done yet and further work is needed in
better scalability the IETF in order to provide better scalability
Nevertheless, we should remember that SIP was originally designed for Nevertheless, we should remember that SIP was originally designed for
end to end session creation and number and size of messages are of end to end session creation and number and size of messages are of
secondary importance for end to end session negotiation. For large secondary importance for end to end session negotiation. For large
scale and especially for very large scale presence the number of scale and especially for very large scale presence the number of
messages that are needed and the size of each message are of extreme 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 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 different way. We need to think about scalability as part of the
protocol design. The IETF tends not to think about actual protocol design. The IETF sometimes does not give the right priority
deployments when designing a protocol but in this case it seems that to actual deployments when designing a protocol but in this case it
if we do not think about scalability with the protocol design it will seems that if we do not think about scalability with the protocol
be very hard to scale. design it will be very hard to scale.
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 in interdomain or even between servers in the same domain (as
between RLSs and presence servers) there is a need to have a between RLSs (Resource List Servers [RFC4662]) and presence servers)
different protocol that will be very optimized for the load and can there is a need to have a different protocol that will be very
assume some assumptions about the network (e.g. do not use unreliable optimized for the load and can assume some assumptions about the
protocol as UDP but only TCP). network (e.g. do not use unreliable protocol as UDP but only TCP).
When servers is connecting to another server using current protocol, When a server is connecting to another server using current protocol,
there will be an extreme number of redundant messages due to the there will be an extreme number of redundant messages due to the
overhead of supporting UDP and to the need to send multiple presence overhead in the SIP protocol of supporting both TCP and UDP and due
documents for the same watched user due to privacy issue. A server to the need to send multiple presence documents for the same watched
to server protocol will have to address these issues. Some initial user because of privacy issues. A server to server protocol will
work to address these issues can be found in: [5], [6] and [7] have to address these issues. Some initial work to address these
issues can be found in:
[I-D.houri-simple-interdomain-scaling-optimizations],
[I-D.ietf-simple-view-sharing] and
[I-D.ietf-simple-intradomain-federation]
Another issue that is more concerning protocol design is whether Another issue that is more concerning protocol design is whether
NOTIFY messages should not be considered as media as audio, video and NOTIFY messages should not be considered as media just like audio,
even text messaging. The SUBSCRIBE can be extended to do similar video and even text messaging. The SUBSCRIBE method may be extended
three way handshake as INVITE and negotiate where the notify messages to negotiate the route and other parameters of the NOTIFY messages,
should go, rate and other parameters. This way the load can be in a similar way that the INVITE method is negotiating media
offloaded to a specialized NOTIFY "relays" thus not loading the parameters. This way the load can be offloaded to a specialized
control path of SIP. One of the possible ideas (Marc Willekens) is NOTIFY "relays" thus not loading the control path of SIP. One of the
to use the SIP stack for the client/server NOTIFY but make use of a possible ideas (Marc Willekens) is to use the SIP protocol for
more optimized and controllable protocol for the server-to-server client/server NOTIFY but make use of a more optimized and
interface. Another possibility is to use the MSRP [2], [3]protocol controllable protocol for the server-to-server interface. Another
for the notifies. possibility is to use the MSRP [RFC4975], [RFC4976]protocol for the
notifies.
5. Security Considerations 5. Security Considerations
This document discusses scalability requirements for the existing This document discusses scalability requirements for the existing
SIP/SIMPLE presence protocol and model. Many of the changes to the SIP/SIMPLE presence protocol and model. Many of the changes to the
protocol will have security implications as mentioned in some of the protocol will have security implications as mentioned in some of the
requirements above. requirements above.
One example of possible protocol changes that may have security One example of possible protocol changes that may have security
implications is sending a presence document only once between domains implications is sending a presence document only once between domains
in order to optimize the number of messages and network load. This in order to optimize the number of messages and network load. This
possible optimization will delagate privacy protection from one possible optimization will delegate privacy protection from one
domain to another domain and should be addressed when designing domain to another domain and should be addressed when designing
protocol optimizations protocol optimizations
Important part of work on the requirements and optimizations will be Important part of work on the requirements and optimizations will be
to make sure that all the security aspects are covered. to make sure that all the security aspects are covered.
6. Acknowledgments 6. IANA Considerations
We would like to thank Jonathan Rosenberg, Ben Campbell, Markus None.
Isomaki Piotr Boni, David Viamonte, Aki Niemi and Marc Willekens for
their ideas and input.
7. References 7. Acknowledgments
7.1. Normative References 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.
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 8. References
Levels", BCP 14, RFC 2119, March 1997.
7.2. Informational References 8.1. Normative References
[2] Campbell, B., Mahy, R., and C. Jennings, "The Message Session [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Relay Protocol (MSRP)", RFC 4975, September 2007. Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the 8.2. Informational References
Message Sessions Relay Protocol (MSRP)", RFC 4976,
September 2007.
[4] Houri, A., Aoki, E., Parameswar, S., Rang, T., Singh, V., and H. [I-D.houri-simple-interdomain-scaling-optimizations]
Schulzrinne, "Presence Interdomain Scaling Analysis for SIP/ Houri, A., "Scaling Optimizations for Presence in SIP/
SIMPLE", draft-ietf-simple-interdomain-scaling-analysis-03 (work SIMPLE",
in progress), November 2007. (work in progress), July 2007.
[5] Houri, A., "Scaling Optimizations for Presence in SIP/SIMPLE", [I-D.ietf-simple-interdomain-scaling-analysis]
draft-houri-simple-interdomain-scaling-optimizations-00 (work in Houri, A., Aoki, E., Parameswar, S., Rang, T., Singh, V.,
progress), July 2007. and H. Schulzrinne, "Presence Interdomain Scaling Analysis
for SIP/SIMPLE",
draft-ietf-simple-interdomain-scaling-analysis-04 (work in
progress), February 2008.
[6] Rosenberg, J., Donovan, S., and K. McMurry, "Optimizing [I-D.ietf-simple-intradomain-federation]
Rosenberg, J. and A. Houri, "Models for Intra-Domain
Presence Federation",
draft-ietf-simple-intradomain-federation-00 (work in
progress), February 2008.
[I-D.ietf-simple-view-sharing]
Rosenberg, J., Donovan, S., and K. McMurry, "Optimizing
Federated Presence with View Sharing", Federated Presence with View Sharing",
draft-rosenberg-simple-view-sharing-00 (work in progress), draft-ietf-simple-view-sharing-00 (work in progress),
November 2007. February 2008.
[7] Rosenberg, J., "Models for Intra-Domain Presence Federation", [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session
draft-rosenberg-simple-intradomain-federation-00 (work in Initiation Protocol (SIP) Event Notification Extension for
progress), November 2007. 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 Authors' Addresses
Avshalom Houri Avshalom Houri
IBM IBM
Science Park Building 18/D 3 Pekris Street, Science Park
Rehovot, Rehovot,
Israel Israel
Email: avshalom@il.ibm.com Email: avshalom@il.ibm.com
Sriram Parameswar Sriram Parameswar
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
skipping to change at page 8, line 44 skipping to change at line 363
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 43 change blocks. 
96 lines changed or deleted 129 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/