Scaling Requirements for Presence in SIP/SIMPLE
IBM 3 Pekris Street, Science Park
Rehovot
Israel avshalom@il.ibm.com
Microsoft Corporation
One Microsoft Way Redmond WA
98052
USA
Sriram.Parameswar@microsoft.com
AOL LLC 360 W. Caribbean
Drive Sunnyvale CA 94089
USA aoki@aol.net
Columbia University
Department of Computer Science 450 Computer
Science Building New York NY
10027
US
vs2140@cs.columbia.edu
http://www.cs.columbia.edu/~vs2140
Columbia University
Department of Computer Science 450 Computer
Science Building New York NY
10027
US +1 212 939
7004 hgs+ecrit@cs.columbia.edu
http://www.cs.columbia.edu/~hgs
Real Time
SIPPING WG I-D Internet-
Draft SIMPLE problem statement
The document provides a set of requirements for enabling interdomain scaling
in presence for SIP/SIMPLE.
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 .
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 .
In the presence scaling draft ,
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.
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.
REQ-002: The solution SHOULD NOT constrain any existing RFC functional or security
requirements for presence.
REQ-003: Systems that are not using the new additions to the protocol SHOULD
operate at the same level as they do today.
REQ-004: The solution SHOULD NOT limit the ability for presentities to present
different views of presence to different watchers.
REQ-005: The solution SHOULD NOT restrict the ability of a presentity to obtain
its list of watchers.
REQ-006: The solution MUST NOT create any new or make worse any existing
privacy holes.
REQ-007: Presence systems (intra or inter-domain) SHOULD scale in
linear proportion to the number of watchers and presentities in the system.
REQ-008: The solution SHOULD NOT require significantly more state in order to
implement the solution.
REQ-009: It MUST be able to scale to tens of millions of concurrent users in
each domain and in each peer domain.
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.
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.
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.
REQ-013: The solution SHOULD allow for arbitrary federation topologies
including direct peering and intermediary routing.
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 .
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 substantial resources in the form of
networks and hardware in order to create sizable 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 sometimes does not give the right priority to 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. It may be that
in interdomain or even between servers in the same domain (as between RLSs (Resource List Servers
) 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 a server is connecting to another server using current 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:
, and
Another issue that is more concerning 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 is
negotiating 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 , protocol for the notifies.
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 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.
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.