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
401 Ellis St.
Mountain View CA 94043
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 lists requirements for optimizations of SIP/SIMPLE. These
optimizations should reduce the load on the network and the presence servers due
to inter-domain presence subscriptions. The need for the requirements is based
on a separate document that provides scaling analysis for inter-domain presence over
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 SIP/SIMPLE.
See for the list of RFCs and drafts that
are considered as part of SIP/SIMPLE. These optimizations should
reduce the load on the network and the presence servers due to inter-domain presence
subscriptions. The need for the requirements is based on a separate scaling analysis
document .
The scaling analysis document shows that
the following aspects of SIP/SIMPLE can be optimized: the
number of bytes sent between two federating domains, the number of
messages processed, and the amount of state
managed by the presence server.
For example, for two peering networks that have a total of 20 million users,
we calculated that approximately 19 billion messages per 8 hours work day are exchanged
between the networks for the presence service.
For very large session peering (150 million subscriptions), we calculated
that the presence server needs to manage approximately a terabyte of state.
It may be that very large systems require the deployment of significant resources,
but we should consider the following:
The scaling analysis document makes
moderate assumptions about the number of presence status changes per hour and the
the size of the presence document.
Even when applying all optimizations for presence as described by drafts and RFCs,
we still calculated around 10 billion messages per 8 hours work day for a total of 20
million federating users. This is better than the base case, but not enough given the moderate
assumptions and given that, when presence is deployed in a
mass market, the number of federating users will be much larger than 20 million.
This section lists the requirements for a solution that optimizes the
inter-domain presence loads. The requirements are based on the presence scaling
draft .
REQ-001: The solution SHOULD NOT deprecate existing protocol mechanisms
defined in SIP/SIMPLE.
REQ-002: Existing SIP/SIMPLE clients SHOULD be able to communicate with
clients and servers that implement new presence scaling features.
REQ-003: The solution SHOULD NOT constrain any existing RFC functional
requirements for presence.
REQ-004: The solution MUST NOT constrain any existing RFC security
requirements for presence.
REQ-005: Systems that do not use the new additions to the protocol SHOULD
operate at the same level as they do today.
REQ-006: The solution SHOULD NOT limit the ability of presentities to present
different views of presence to different watchers.
REQ-007: The solution SHOULD NOT restrict the ability of a presentity to obtain
its list of watchers.
REQ-008: The solution MUST NOT create any new privacy holes or make any
existing ones worse.
REQ-009: Presence systems (intra- or inter-domain) SHOULD scale in linear
proportion to the number of watchers and presentities in the system.
REQ-010: The solution SHOULD NOT require a significant increase in the
size of maintained state, compared to the current state size required by
SIP/SIMPLE.
REQ-011: The solution MUST allow presence systems to scale. Note: we view
scalability on the order of tens of millions of users in each peer
domain.
REQ-012: The solution MUST support a
high percentage of watcher/presentity intersections between the domains and
it MUST support various intersection models such as either small or large
percentage of users from each domain subscribing to users from the other
domain.
REQ-013: Protocol changes MUST NOT prohibit optimizations in deployment
models where there is a high number of inter-domain subscriptions.
REQ-014: New functionalities and extensions to the presence protocol
SHOULD consider scalability with respect to the number of messages,
state size, and management and processing load.
REQ-015: The solution SHOULD allow for arbitrary federation topologies
including direct and indirect peering.
This section discusses the possible paths for optimization.
One of the most important considerations is whether SIP,
which was designed more as an end-to-end protocol, needs to be optimized for
direct interactions between presence servers.
It is very possible that the issues described here are
inherent to presence systems in general and not specific to SIP/SIMPLE.
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 additional protocol optimizations are possible and further IETF work is
needed in order to provide better scalability of large presence
systems.
We should remember that SIP was originally designed for end-to-end
session creation and that the number and size of messages are of secondary importance
for an end-to-end session negotiation protocol. For large scale and especially for very
large scale presence, the number of messages and the size of each
message are of extreme importance. Care must be taken to address
scalability during the initial phase of protocol design;
shoehorning scalability at a later phase will be doomed to failure.
We should also consider whether using the same protocol between clients and
servers and between servers is a good choice. It may be that, between inter-domain servers or
even intra-domain servers (such as between RLSes and presence servers), there needs to be a different protocol
that is optimized for the load and that can make assumptions about the network
(using only TCP, for example. In , see the section
that calculates the number of bytes and messages for an imaginary, optimized
SIP).
When a presence server connects to another server using current
SIP/SIMPLE, there is an extreme number of redundant messages
due to SIP's support of both TCP and UDP and due
to privacy controls that cause the sending of multiple presence documents for the same presentity.
A server-to-server protocol will have to address
these issues. Some initial work to address these issues can be found in:
and
and in other (still individual) drafts.
Another issue related to 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, similar to the way the INVITE method
negotiates media parameters. This way, the load can be shifted to
specialized NOTIFY "relays" and taken off the control path of SIP. One of the
possible ideas (Marc Willekens) is to use SIP for client/server
NOTIFY but use a more optimized and controllable protocol for the
server-to-server interface. Another possibility is to use the MSRP , protocol for the notifications.
This document discusses the scalability requirements for the existing
SIP/SIMPLE protocol and model. Many of the above-mentioned changes to the protocol
will have security implications.
For example, a potential protocol change that may have security
implications is the single sending of a presence document between domains in
order to reduce the number of messages and network load. This possible
optimization will delegate privacy protection from one domain to the other,
and this delegated protection should be addressed during design.
An important part of work on the requirements and optimizations will be to ensure
that all the security aspects are covered.
This document has no IANA actions.
Editorial language changes.
We would like to thank Jonathan Rosenberg, Ben Campbell, Markus Isomaki
Piotr Boni, David Viamonte, Aki Niemi, Marc Willekens, and Gonzalo Camarillo
for their ideas and input. Special thanks to Jean-Francois Mule, Vijay K.
Gurbani and Hisham Khartabil for their a detailed review. Very sprecial
thanks A. Jean Mahoney for reviewing this draft.