SIPPING WG	A. Houri
Internet-Draft	IBM
Intended status: Informational	S. Parameswar
Expires: May 6, 2009	Microsoft Corporation
	E. Aoki
	AOL LLC
	V. Singh
	H. Schulzrinne
	Columbia U.
	November 02, 2008

Scaling Requirements for Presence in SIP/SIMPLE
draft-ietf-sipping-presence-scaling-requirements-02.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 May 6, 2009.

Abstract

The document provides a set of requirements for enabling interdomain scaling in presence for SIP/SIMPLE.

1. Requirements notation
2. Introduction
    2.1. Very large network peering
    2.2. State Management
        2.2.1. State Size Calculations
3. Requirements
    3.1. Backward Compatibility Requirements
    3.2. Policy, Privacy, Permissions Requirements
    3.3. Scalability Requirements
    3.4. Topology Requirements
4. Considerations for Possible Optimizations
    4.1. Very Optimized SIP
5. Security Considerations
6. IANA Considerations
7. Acknowledgments
8. References
    8.1. Normative References
    8.2. Informational References
§ Authors' Addresses
§ Intellectual Property and Copyright Statements

TOC

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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

TOC

2. Introduction

The document lists requirements for optimizations of the SIP/SIMPLE protocol. See [I‑D.ietf‑simple‑simple] (Rosenberg, J., “SIMPLE made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence using the Session Initiation Protocol (SIP),” March 2009.) for the list of RFCs and drafts that are considered as part of the SIP/SIMPLE protocol. These optimizations should reduce the load on the network and the presence servers in interdomain presence subscriptions. The requirements are based on a separate scaling analysis document [I‑D.ietf‑simple‑interdomain‑scaling‑analysis] (Houri, A., Aoki, E., Parameswar, S., Rang, T., Singh, V., and H. Schulzrinne, “Presence Interdomain Scaling Analysis for SIP/SIMPLE,” August 2009.).

The scaling analysis document have shown that there is much room for optimizations in the SIP/SIMPLE protocol. The need for optimizations is in the number of by teds that are sent between two federating domains, the number of messages that need to be processed and the amount of state that needs to be managed by the presence servers. The following is a snaphot of various numbers from the scaling analysis document. This snapshot is in clouded here for completeness, please refer to the scaling analysis document for the full details including the description of the calculations and the various SIP optimizations investigated.

TOC

2.1. Very large network peering

In this environment, two or more very large networks create a peering relationship allowing their users to subscribe to presence in the other domains. Where as the number of users in other deployment types ranges from hundreds to several hundred thousand, these large networks host up to hundreds of millions of users. Examples of these networks are large wireless carriers and consumer IM networks.

Common characteristics of this deployment are:

As users become accustomed to network boundaries disappearing, federated subscriptions become as common as subscriptions within the same domain
Individual users are highly likely to want to see presence of multiple presentities in the peer network
The intersection of users in the deployment watching the same presentities is very high (i.e., two or more users in network A are extremely likely to be watching a same user in network B)
Status changes increase greatly due to typical observed consumer behavior

The first table below provides the calculations without optimizations the second table provides the calculations with optimizations. Even though the optimizations help a lot (almost cut the number of messages by half), the numbers are still very high. Note also that the bandwidth required is very high.

** Constants
(C01) Subscription lifetime (hours)...........................8
(C02) Presence state changes / hour...........................6
(C03) Subscription refresh interval / hour....................1
(C04) Total federated presentities per watcher...............10
(C05) Number of dialogs to maintain per watcher..............10
(C06) Total number of watchers in domains............20,000,000
(C07) SUBSCRIBE message size in bytes.......................450
(C08) 200 OK for SUBSCRIBE message size in bytes............370
(C09) NOTIFY message size not including presence doc........500
(C10) 200 OK for NOTIFY message size in bytes...............370
(C11) Size of an average presence document..................350

** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher.....................10
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher............10
(I03) Initial NOTIFY msgs per watcher........................10
(I04) Initial 200 OK msgs (NOTIFY) per watcher...............10
(I05) Total number & bytes of initial SUBSCRIBE msgs
          Number of msgs for all watchers...........200,000,000
          Bytes for all watchers.................90,000,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
          Number of msgs for all watchers...........200,000,000
          Bytes for all watchers.................74,000,000,000
(I07) Total number & bytes of initial NOTIFY msgs
          Number of msgs for all watchers...........200,000,000
          Bytes for all watchers................170,000,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
          Number of msgs for all watchers...........200,000,000
          Bytes for all watchers.................74,000,000,000
(I09) Total number & bytes of initial messages per day
          Number of msgs for all watchers...........800,000,000
          Bytes for all watchers................408,000,000,000

** Steady State Messages
(S01) NOTIFY msgs due to state change
          per watched presentity per day.....................46
(S02) 200 (for NOTIFY due to state change) msgs
          per watched presentity per day.....................46
(S03) Total number and size of msgs due to state change per day
          Number of msgs for all watchers........18,400,000,000
          Bytes for all watchers.............11,224,000,000,000
(S04) Number of SUBSCRIBE msgs for refreshes
          per watcher per day................................70
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
          per watcher per day................................70
(S06) Number of NOTIFY msgs for refreshes
          per watcher per day................................70
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
          per watcher per day................................70
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
          Number of msgs for all watchers per day.5,600,000,000
          Bytes for all watchers per day......2,856,000,000,000
(S09) Total number & bytes of steady messages per day
          Number of msgs for all watchers........24,000,000,000
          Bytes for all watchers.............14,080,000,000,000

** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher.................10
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........10
(T03) Terminating NOTIFY msgs per watcher....................10
(T04) Terminating 200 OK msgs (NOTIFY) per watcher...........10
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
          Number of msgs for all watchers...........200,000,000
          Bytes for all watchers.................90,000,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
          Number of msgs for all watchers...........200,000,000
          Bytes for all watchers.................74,000,000,000
(T07) Total number & bytes of terminating NOTIFY msgs
          Number of msgs for all watchers...........200,000,000
          Bytes for all watchers................170,000,000,000
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
          Number of msgs for all watchers...........200,000,000
          Bytes for all watchers.................74,000,000,000
(T09) Total number & bytes of terminating messages per day
          Number of msgs for all watchers...........800,000,000
          Bytes for all watchers................408,000,000,000

** Bottom Line
(B01) Total of messages between domains..........25,600,000,000
      Total of bytes bet. domains (PD=350)...14,896,000,000,000
      Total of bytes bet. domains (PD=3000)..44,046,000,000,000
(B02) Total number of messages / second.................888,889
      Total of bytes per second (PD=350)............517,222,222
      Total of bytes per second (PD=3000).........1,529,375,000
(B03) Total number of by msgs per user/day................1,280
      Total number of bytes per user/day (PD=350).......744,800
      Total number of bytes per user/day (PD=3000)....2,202,300

Figure 1: Very large network peering with no optimizations

** Constants
(C01) Subscription lifetime (hours)...........................8
(C02) Presence state changes / hour...........................6
(C03) Subscription refresh interval / hour....................1
(C04) Total federated presentities per watcher...............10
(C05) Number of dialogs to maintain per watcher...............1
(C06) Total number of watchers in domains............20,000,000
(C07) SUBSCRIBE message size in bytes.......................450
(C08) 200 OK for SUBSCRIBE message size in bytes............370
(C09) NOTIFY message size not including presence doc........500
(C10) 200 OK for NOTIFY message size in bytes...............370
(C11) Size of an average presence document..................350
(C13) Additional data per document in RLMI..................160
(C14) Multiparty boundary in RLMI document..................144
(C15) XML root node in RLMI document........................144

** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher......................1
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1
(I03) Initial NOTIFY msgs per watcher.........................1
(I04) Initial 200 OK msgs (NOTIFY) per watcher................1
(I05) Total number & bytes of initial SUBSCRIBE msgs
          Number of msgs for all watchers............20,000,000
          Bytes for all watchers..................9,000,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
          Number of msgs for all watchers............20,000,000
          Bytes for all watchers..................7,400,000,000
(I07) Total number & bytes of initial NOTIFY msgs
          Number of msgs for all watchers............20,000,000
          Bytes for all watchers................146,560,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
          Number of msgs for all watchers............20,000,000
          Bytes for all watchers..................7,400,000,000
(I09) Total number & bytes of initial messages per day
          Number of msgs for all watchers............80,000,000
          Bytes for all watchers................170,360,000,000

** Steady State Messages
(S01) NOTIFY msgs due to state change
          per watched presentity per day.....................46
(S02) 200 (for NOTIFY due to state change) msgs
          per watched presentity per day.....................46
(S03) Total number and size of msgs due to state change per day
          Number of msgs for all watchers........18,400,000,000
          Bytes for all watchers.............16,670,400,000,000
(S04) Number of SUBSCRIBE msgs for refreshes
          per watcher per day.................................7
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
          per watcher per day.................................7
(S06) Number of NOTIFY msgs for refreshes
          per watcher per day.................................0
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
          per watcher per day.................................0
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
          Number of msgs for all watchers per day...280,000,000
          Bytes for all watchers per day........114,800,000,000
(S09) Total number & bytes of steady messages per day
          Number of msgs for all watchers........18,680,000,000
          Bytes for all watchers.............16,785,200,000,000

** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher..................1
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1
(T03) Terminating NOTIFY msgs per watcher.....................0
(T04) Terminating 200 OK msgs (NOTIFY) per watcher............0
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
          Number of msgs for all watchers............20,000,000
          Bytes for all watchers..................9,000,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
          Number of msgs for all watchers............20,000,000
          Bytes for all watchers..................7,400,000,000
(T07) Total number & bytes of terminating NOTIFY msgs
          Number of msgs for all watchers.....................0
          Bytes for all watchers..............................0
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
          Number of msgs for all watchers.....................0
          Bytes for all watchers..............................0
(T09) Total number & bytes of terminating messages per day
          Number of msgs for all watchers............40,000,000
          Bytes for all watchers.................16,400,000,000

** Bottom Line
(B01) Total of messages between domains..........18,800,000,000
      Total of bytes bet. domains (PD=350)...16,971,960,000,000
      Total of bytes bet. domains (PD=3000)..41,881,960,000,000
(B02) Total number of messages / second.................652,778
      Total of bytes per second (PD=350)............589,304,167
      Total of bytes per second (PD=3000).........1,454,234,722
(B03) Total number of by msgs per user/day..................940
      Total number of bytes per user/day (PD=350).......848,598
      Total number of bytes per user/day (PD=3000)....2,094,098

Figure 2: Very large network peering with optimizations

TOC

2.2. State Management

In previous sections we have demonstrated the large amount of messages that need to be sent to/from a presence server In this section the state that needs to be maintained by a presence server will be analyzed and shown to be far from trivial.

The presence server has two parallel tasks.

Maintain the state of the presentities to which watchers subscribe.
Maintain the state of the subscriptions of watchers and provide timely updates to the watchers.

For a single subscription from a single watcher on a presentity, the presence server has to maintain the following state:

Subscription state including all the parameters that are needed in order to maintain the subscription as timers.
Optional filtering information that was requested by the watcher. This includes enough information that is needed for doing the filtering. In addition additional information has to be maintained if partial notification is being supported for the subscription
Optional rate management information as throttling
Watcher information [RFC3857] (Rosenberg, J., “A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP),” August 2004.), [RFC3858] (Rosenberg, J., “An Extensible Markup Language (XML) Based Format for Watcher Information,” August 2004.) that is the result of the subscription in order to enable watched presentities to see who is watching them.

For each presentity that has been subscribed to in the presence server, the presence server has to maintain the following state:

A list of the subscriptions for the presentity. Note that this is already taken care of from the size calculation point of view by the subscription state above.
Authorization information for the presentity.

For each presentity for which there was any publication and the presentity has a state other then a default value, the presence server has to maintain the current value of the presentity.

TOC

2.2.1. State Size Calculations

Assuming the following sizes, the state size is calculated for various systems:

Subscription size - 2K bytes. This includes watcher information that need to be created by the presence server for each subscription. This is for each subscription that is done by each watcher to each presentity that the watcher is watching. So if we have 10K watchers we should have 10K of these.
Subscribed to resource - 1K bytes (for privacy information and other management info). This is for each presentity that is being watched. No matter how many watchers are watching it. The subscriptions themselves are already calculated in the previous bullet.
Resource with a state - 6K bytes. This is a moderate assumption if we take into account the amount of data that is being put in a presence document as multiple devices, calendar and geographical information. This is for each presentity that has state other then the default empty state. It does not matter if it is being watched or not.

Tiny System:

10K subscriptions = 19M bytes.
5K subscribed to presentities = 5M bytes.
10K presentities with state = 58M bytes.

The total for tiny system is 82M bytes.

Medium System:

100K subscriptions = 195M bytes.
50K subscribed to presentities = 49M bytes.
100K presentities with state = 586M bytes.

The total for medium system is 830M bytes.

Large System:

6M subscriptions = 11,718M bytes.
3M subscribed to presentities = 2,929M bytes.
4M presentities with state = 23437M bytes.

The total for large system is 38G bytes.

Very Large System:

150M subscriptions = 292,969M bytes.
75M subscribed to presentities = 73,242M bytes.
100M presentities with state = 585,937M bytes.

The total for very large system is 952G bytes which is a very big number for a very dynamic storage as needed by the presence server.

Although the numbers above may seem moderate enough for the sizes that the presence server is handling we should consider the following:

Dynamic state - Although the state may seem not so big for databases even for the very large system, we need to remember that this state is a very dynamic state. Subscriptions come and go all the time, the status of presentities is being updated and so forth. This means that the presence server has to manage its state in a medium that is very dynamic and for such large sizes this task is not trivial.
Interlinked state - The subscriptions and the subscribed to presentities are dependent on each other. There needs to be a link from the presentity to the subscriptions and vice versa. There is a need to be a linkage between the Resource List Server (RLS [RFC4662] (Roach, A., Campbell, B., and J. Rosenberg, “A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists,” August 2006.)) and the various presence servers that hold the presence data. See section 4.5 in the presence scaling document for more details.
Moderate assumptions - The size assumptions that were made above are quite moderate. As presence is becoming more a core middleware functionality that holds a lot of data on the user. In real-life the numbers above may be even higher and the presence server can have additional overhead as managing the SIP sessions, networking and more.

Although the calculations above do not show that there is a real issue with state management of presence in medium systems or even in big systems since it should be possible to divide the state between different machines, the state size is still very big. A bigger issue with the state is more when resource lists are involved and create an interlinked state between many servers. In that case the division of very big state to multiple servers becomes less trivial...

TOC

3. Requirements

This section lists requirements for a solution that will optimize the interdomain presence loads. The requirements are based on the presence scaling draft [I‑D.ietf‑simple‑interdomain‑scaling‑analysis] (Houri, A., Aoki, E., Parameswar, S., Rang, T., Singh, V., and H. Schulzrinne, “Presence Interdomain Scaling Analysis for SIP/SIMPLE,” August 2009.).

TOC

3.1. Backward Compatibility Requirements

REQ-001: The solution SHOULD NOT deprecate existing protocol mechanisms defined in SIP/SIMPLE. The ability of existing SIP/SIMPLE clients and/or servers from peering with a domain or a client implementing the solution SHOULD be retained with no changes required of existing servers to interoperate.
REQ-002-A: The solution SHOULD NOT constrain any existing RFC functional requirements for presence.
REQ-002-B: The solution MUST NOT constrain any existing RFC 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.

TOC

3.2. Policy, Privacy, Permissions Requirements

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.

TOC

3.3. Scalability Requirements

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 then solutions based on current protocol in order to implement the optimizations.
REQ-009: 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-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 from the other domain while there will be few watchers from the same 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 especially 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.

TOC

3.4. Topology Requirements

REQ-013: The solution SHOULD allow for arbitrary federation topologies including direct and indirect peering.

TOC

4. Considerations for Possible Optimizations

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 [I‑D.ietf‑simple‑interdomain‑scaling‑analysis] (Houri, A., Aoki, E., Parameswar, S., Rang, T., Singh, V., and H. Schulzrinne, “Presence Interdomain Scaling Analysis for SIP/SIMPLE,” August 2009.).

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 document are inherent to presence systems in general and not specific to the SIP/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 additional protocol optimizations are possible and further work is needed in the IETF 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 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 that are needed and the size of each message are of extreme importance. Adequate care must be taken in addressing scalability as part of the initial protocol design phase; Trying to to shoehorn 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 in interdomain or even between servers in the same domain (as between RLSs [RFC4662] (Roach, A., Campbell, B., and J. Rosenberg, “A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists,” August 2006.), 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 (for example do not use unreliable protocol as UDP but only TCP, see the section that calculates the number of bytes and messages for imaginary very optimized SIP).

When a presence server connects to another server using the current SIP/SIMPLE 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: [I‑D.ietf‑simple‑view‑sharing] (Rosenberg, J., Donovan, S., and K. McMurry, “Optimizing Federated Presence with View Sharing,” November 2008.) and [I‑D.ietf‑simple‑intradomain‑federation] (Rosenberg, J., Houri, A., Smyth, C., and F. Audet, “Models for Intra-Domain Presence and Instant Messaging (IM) Bridging,” July 2009.) and in other (still individual) drafts.

Another issue that is more 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, in a similar way that the INVITE method negotiates 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 [RFC4975] (Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” September 2007.), [RFC4976] (Jennings, C., Mahy, R., and A. Roach, “Relay Extensions for the Message Sessions Relay Protocol (MSRP),” September 2007.) protocol for the notifications.

TOC

4.1. Very Optimized SIP

SIP is network agnostic protocol, therefore, the protocol carries additional messages like 200 OK that would have been redundant in a protocol that is TCP based only.

The following calculation assumes an imaginary TCP only based version of SIP that optimizes the following:

There is no 200 OK for each message. Since only TCP has to be supported, there is not need to compensate for network issues.
There is no refresh for subscriptions.
There is no NOTIFY upon termination of SUBSCRIPTION
The size of each message is smaller since there is no need for the various headers that SIP uses for routing etc. So we need to assume smaller message sizes while we will keep the size of the presence document the same.

As notes above the calculations in this document do not assume offline means of getting parts of the presence information. Therefore, in addition to the above optimizations, the other optimizations that were assumed in the document will be assumed here also. These includes partial notifications and the dialog optimizations. The NOTIFY optimization is not relevant here since there are no refreshes of subscriptions.

The following is a calculation for the very large networks peering scenario assuming the imaginary TCP only SIP. It is very interesting to note that the dialog optimization does not reduce the number of bytes when partial notification optimization is applied (on the contrary) due to the RLMI overhead.

** Constants
(C01) Subscription lifetime (hours)...........................8
(C02) Presence state changes / hour...........................6
(C03) Subscription refresh interval / hour....................0
(C04) Total federated presentities per watcher...............10
(C05) Number of dialogs to maintain per watcher...............1
(C06) Total number of watchers in domains............20,000,000
(C07) SUBSCRIBE message size in bytes.......................150
(C08) 200 OK for SUBSCRIBE message size in bytes..............0
(C09) NOTIFY message size not including presence doc........150
(C10) 200 OK for NOTIFY message size in bytes.................0
(C11) Size of an average presence document..................350
(C12) Size of an average partial presence document..........200

** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher......................1
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............0
(I03) Initial NOTIFY msgs per watcher.........................1
(I04) Initial 200 OK msgs (NOTIFY) per watcher................0
(I05) Total number & bytes of initial SUBSCRIBE msgs
          Number of msgs for all watchers............20,000,000
          Bytes for all watchers..................3,000,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
          Number of msgs for all watchers.....................0
          Bytes for all watchers..............................0
(I07) Total number & bytes of initial NOTIFY msgs
          Number of msgs for all watchers............20,000,000
          Bytes for all watchers................136,680,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
          Number of msgs for all watchers.....................0
          Bytes for all watchers..............................0
(I09) Total number & bytes of initial messages per day
          Number of msgs for all watchers............40,000,000
          Bytes for all watchers................139,680,000,000

** Steady State Messages
(S01) NOTIFY msgs due to state change
          per watched presentity per day.....................46
(S02) 200 (for NOTIFY due to state change) msgs
          per watched presentity per day......................0
(S03) Total number and size of msgs due to state change per day
          Number of msgs for all watchers.........9,200,000,000
          Bytes for all watchers..............8,666,400,000,000
(S04) Number of SUBSCRIBE msgs for refreshes
          per watcher per day.................................0
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
          per watcher per day.................................0
(S06) Number of NOTIFY msgs for refreshes
          per watcher per day.................................0
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
          per watcher per day.................................0
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
          Number of msgs for all watchers per day.............0
          Bytes for all watchers per day......................0
(S09) Total number & bytes of steady messages per day
          Number of msgs for all watchers.........9,200,000,000
          Bytes for all watchers..............8,666,400,000,000

** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher..................1
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........0
(T03) Terminating NOTIFY msgs per watcher.....................0
(T04) Terminating 200 OK msgs (NOTIFY) per watcher............0
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
          Number of msgs for all watchers............20,000,000
          Bytes for all watchers..................3,000,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
          Number of msgs for all watchers.....................0
          Bytes for all watchers..............................0
(T07) Total number & bytes of terminating NOTIFY msgs
          Number of msgs for all watchers.....................0
          Bytes for all watchers..............................0
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
          Number of msgs for all watchers.....................0
          Bytes for all watchers..............................0
(T09) Total number & bytes of terminating messages per day
          Number of msgs for all watchers............20,000,000
          Bytes for all watchers..................3,000,000,000

** Bottom Line
(B01) Total of messages between domains...........9,260,000,000
      Total of bytes between domains (PD=350).8,809,080,000,000
      Total of bytes bet. domains (PD=3000)...9,339,080,000,000
(B02) Total number of messages / second.................321,528
      Total of bytes per second (PD=350)............305,870,833
      Total of bytes per second (PD=3000)...........324,273,611
(B03) Total number of by msgs per user/day..................463
      Total number of bytes per user/day (PD=350).......440,454
      Total number of bytes per user/day (PD=3000)......466,954
<artwork><![CDATA[

Figure 3: Very large networks peering, TCP only SIP+Partial+Dialog optimizations

** Constants
(C01) Subscription lifetime (hours)...........................8
(C02) Presence state changes / hour...........................6
(C03) Subscription refresh interval / hour....................0
(C04) Total federated presentities per watcher...............10
(C05) Number of dialogs to maintain per watcher..............10
(C06) Total number of watchers in domains............20,000,000
(C07) SUBSCRIBE message size in bytes.......................150
(C08) 200 OK for SUBSCRIBE message size in bytes..............0
(C09) NOTIFY message size not including presence doc........150
(C10) 200 OK for NOTIFY message size in bytes.................0
(C11) Size of an average presence document..................350
(C12) Size of an average partial presence document..........200

** Initial Messages
(I01) Initial SUBSCRIBE msgs per watcher.....................10
(I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............0
(I03) Initial NOTIFY msgs per watcher........................10
(I04) Initial 200 OK msgs (NOTIFY) per watcher................0
(I05) Total number & bytes of initial SUBSCRIBE msgs
          Number of msgs for all watchers...........200,000,000
          Bytes for all watchers.................30,000,000,000
(I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs
          Number of msgs for all watchers.....................0
          Bytes for all watchers..............................0
(I07) Total number & bytes of initial NOTIFY msgs
          Number of msgs for all watchers...........200,000,000
          Bytes for all watchers................100,000,000,000
(I08) Total number & bytes of initial 200 OK (NOTIFY) msgs
          Number of msgs for all watchers.....................0
          Bytes for all watchers..............................0
(I09) Total number & bytes of initial messages per day
          Number of msgs for all watchers...........400,000,000
          Bytes for all watchers................130,000,000,000

** Steady State Messages
(S01) NOTIFY msgs due to state change
          per watched presentity per day.....................46
(S02) 200 (for NOTIFY due to state change) msgs
          per watched presentity per day......................0
(S03) Total number and size of msgs due to state change per day
          Number of msgs for all watchers.........9,200,000,000
          Bytes for all watchers..............3,220,000,000,000
(S04) Number of SUBSCRIBE msgs for refreshes
          per watcher per day.................................0
(S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes
          per watcher per day.................................0
(S06) Number of NOTIFY msgs for refreshes
          per watcher per day.................................0
(S07) Number of 200 OK msgs for NOTIFY msgs for refreshes
          per watcher per day.................................0
(S08) Total number and size of msgs due to SUBSCRIBE refreshes
          Number of msgs for all watchers per day.............0
          Bytes for all watchers per day......................0
(S09) Total number & bytes of steady messages per day
          Number of msgs for all watchers.........9,200,000,000
          Bytes for all watchers..............3,220,000,000,000

** Termination Messages
(T01) Terminating SUBSCRIBE msgs per watcher.................10
(T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........0
(T03) Terminating NOTIFY msgs per watcher.....................0
(T04) Terminating 200 OK msgs (NOTIFY) per watcher............0
(T05) Total number & bytes of Terminating SUBSCRIBE msgs
          Number of msgs for all watchers...........200,000,000
          Bytes for all watchers.................30,000,000,000
(T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs
          Number of msgs for all watchers.....................0
          Bytes for all watchers..............................0
(T07) Total number & bytes of terminating NOTIFY msgs
          Number of msgs for all watchers.....................0
          Bytes for all watchers..............................0
(T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs
          Number of msgs for all watchers.....................0
          Bytes for all watchers..............................0
(T09) Total number & bytes of terminating messages per day
          Number of msgs for all watchers...........200,000,000
          Bytes for all watchers.................30,000,000,000

** Bottom Line
(B01) Total of messages between domains...........9,800,000,000
      Total of bytes between domains (PD=350).3,380,000,000,000
      Total of bytes bet. domains (PD=3000)...3,910,280,000,000
(B02) Total number of messages / second.................340,278
      Total of bytes per second (PD=350)............117,361,111
      Total of bytes per second (PD=3000)...........135,763,889
(B03) Total number of by msgs per user/day..................490
      Total number of bytes per user/day (PD=350).......169,000
      Total number of bytes per user/day (PD=3000)......195,500

Figure 4: Very large networks peering, TCP only SIP+Partial optimizations

TOC

5. Security Considerations

This document discusses scalability requirements for the existing SIP/SIMPLE 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.

TOC

6. IANA Considerations

This document has no IANA actions.

TOC

7. Acknowledgments

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 Jean-Francois Mule, Vijay K. Gurbani and Hisham Khartabil for their a detailed review.

TOC

8. References

TOC

8.1. Normative References

[RFC2119]

Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).

TOC

8.2. Informational References

[I-D.ietf-simple-interdomain-scaling-analysis]	Houri, A., Aoki, E., Parameswar, S., Rang, T., Singh, V., and H. Schulzrinne, “Presence Interdomain Scaling Analysis for SIP/SIMPLE,” draft-ietf-simple-interdomain-scaling-analysis-08 (work in progress), August 2009 (TXT).
[I-D.ietf-simple-intradomain-federation]	Rosenberg, J., Houri, A., Smyth, C., and F. Audet, “Models for Intra-Domain Presence and Instant Messaging (IM) Bridging,” draft-ietf-simple-intradomain-federation-04 (work in progress), July 2009 (TXT).
[I-D.ietf-simple-simple]	Rosenberg, J., “SIMPLE made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence using the Session Initiation Protocol (SIP),” draft-ietf-simple-simple-05 (work in progress), March 2009 (TXT).
[I-D.ietf-simple-view-sharing]	Rosenberg, J., Donovan, S., and K. McMurry, “Optimizing Federated Presence with View Sharing,” draft-ietf-simple-view-sharing-02 (work in progress), November 2008 (TXT).
[RFC3857]	Rosenberg, J., “A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP),” RFC 3857, August 2004 (TXT).
[RFC3858]	Rosenberg, J., “An Extensible Markup Language (XML) Based Format for Watcher Information,” RFC 3858, August 2004 (TXT).
[RFC4662]	Roach, A., Campbell, B., and J. Rosenberg, “A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists,” RFC 4662, August 2006 (TXT).
[RFC4975]	Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” RFC 4975, September 2007 (TXT).
[RFC4976]	Jennings, C., Mahy, R., and A. Roach, “Relay Extensions for the Message Sessions Relay Protocol (MSRP),” RFC 4976, September 2007 (TXT).

TOC

Authors' Addresses

	Avshalom Houri
	IBM
	3 Pekris Street, Science Park
	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
	401 Ellis St.
	Mountain View, CA 94043
	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

	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

TOC

Full Copyright Statement

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.

Scaling Requirements for Presence in SIP/SIMPLEdraft-ietf-sipping-presence-scaling-requirements-02.txt