One document matched: draft-houri-sipping-presence-scaling-requirements-00.txt
SIPPING WG A. Houri
Internet-Draft IBM
Intended status: Standards Track S. Parameswar
Expires: January 3, 2008 Microsoft Corporation
E. Aoki
AOL LLC
V. Singh
H. Schulzrinne
Columbia U.
July 2, 2007
Scaling Requirements for Presence in SIP/SIMPLE
draft-houri-sipping-presence-scaling-requirements-00.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 3, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The document provides a set of requirements for enabling interdomain
scaling in presence for SIP/SIMPLE. The requirements are based on a
Houri, et al. Expires January 3, 2008 [Page 1]
Internet-Draft Scaling Requirements for Presence July 2007
separate scaling analysis document.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Suggested Requirements . . . . . . . . . . . . . . . . . . . . 3
3.1. Backward Compatibility Requirements . . . . . . . . . . . . 3
3.2. Policy, Privacy, Permissions Requirements . . . . . . . . . 3
3.3. Scalability Requirements . . . . . . . . . . . . . . . . . 3
3.4. Topology Requirements . . . . . . . . . . . . . . . . . . . 4
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
7.2. Informational References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Houri, et al. Expires January 3, 2008 [Page 2]
Internet-Draft Scaling Requirements for Presence July 2007
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].
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 [2].
3. Suggested Requirements
In the presence scaling draft [2], 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 we
are listing an initial set of requirements for a solution that will
optimize the interdomain presence traffic.
3.1. Backward Compatibility Requirements
o 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.
o REQ-002: It does NOT constrain any existing RFC functional or
security requirements for presence.
o 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
o REQ-004: The solution does not limit the ability for presentities
to present different views of presence to different watchers.
o REQ-005: The solution does not restrict the ability of a
presentity to obtain its list of watchers.
o REQ-006: The solution MUST NOT create any new or make worse any
existing privacy holes.
3.3. Scalability Requirements
o REQ-007: It is highly desirable for any presence system (intra or
inter-domain) to scale linearly as number of watchers and
presentities increase linearly.
Houri, et al. Expires January 3, 2008 [Page 3]
Internet-Draft Scaling Requirements for Presence July 2007
o REQ-008: The solution SHOULD NOT require significantly more state
in order to implement the solution.
o REQ-009: It MUST be able to scale to tens of millions of
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-011: Protocol changes MUST NOT prohibit optimizations in
different deployment models esp. where there is a high level of
cross subscriptions between the domains.
o 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
o REQ-013: The solution SHOULD allow for arbitrary federation
topologies including direct peering and intermediary routing.
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
[2].
Several optimizations are already part of the SIP/SIMPLE protocol
were also surveyed in [2] while many other suggested optimizations
were not discussed yet.
It is very possible that the issues that are described in the scaling
analysis [2] 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.
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 not 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
Houri, et al. Expires January 3, 2008 [Page 4]
Internet-Draft Scaling Requirements for Presence July 2007
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).
Another issue that is more concerning protocol design is whether
NOTIFY messages should not be considered as media as the 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 specialized NOTIFY "relays" thus not
loading the control path of SIP.
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. Important part of work on the requirements and
optimizations will be to make sure that all the security aspects are
covered.
6. Acknowledgments
We would like to thank Jonathan Rosenberg, Ben Campbell, Markus
Isomaki Piotr Boni, David Viamonte and Aki Niemi for their ideas and
input.
7. References
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
7.2. Informational References
[2] Houri, A., "Problem Statement for SIP/SIMPLE",
draft-ietf-simple-interdomain-scaling-analysis-00 (work in
progress), February 2007.
Houri, et al. Expires January 3, 2008 [Page 5]
Internet-Draft Scaling Requirements for Presence July 2007
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
Houri, et al. Expires January 3, 2008 [Page 6]
Internet-Draft Scaling Requirements for Presence July 2007
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
Houri, et al. Expires January 3, 2008 [Page 7]
Internet-Draft Scaling Requirements for Presence July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Houri, et al. Expires January 3, 2008 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-23 11:47:21 |