draft-ietf-sipping-presence-scaling-requirements-01.txt   draft-ietf-sipping-presence-scaling-requirements-02.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: January 4, 2009 Microsoft Corporation Expires: May 6, 2009 Microsoft Corporation
E. Aoki E. Aoki
AOL LLC AOL LLC
V. Singh V. Singh
H. Schulzrinne H. Schulzrinne
Columbia U. Columbia U.
July 3, 2008 November 2, 2008
Scaling Requirements for Presence in SIP/SIMPLE Scaling Requirements for Presence in SIP/SIMPLE
draft-ietf-sipping-presence-scaling-requirements-01.txt draft-ietf-sipping-presence-scaling-requirements-02.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 January 4, 2009. This Internet-Draft will expire on May 6, 2009.
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. scaling in presence for SIP/SIMPLE.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Suggested Requirements . . . . . . . . . . . . . . . . . . . . 3 2.1. Very large network peering . . . . . . . . . . . . . . . . 3
3.1. Backward Compatibility Requirements . . . . . . . . . . . . 3 2.2. State Management . . . . . . . . . . . . . . . . . . . . . 8
3.2. Policy, Privacy, Permissions Requirements . . . . . . . . . 3 2.2.1. State Size Calculations . . . . . . . . . . . . . . . 8
3.3. Scalability Requirements . . . . . . . . . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4. Topology Requirements . . . . . . . . . . . . . . . . . . . 4 3.1. Backward Compatibility Requirements . . . . . . . . . . . 10
4. Considerations for Possible Optimizations . . . . . . . . . . . 4 3.2. Policy, Privacy, Permissions Requirements . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 3.3. Scalability Requirements . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Topology Requirements . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Considerations for Possible Optimizations . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Very Optimized SIP . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8.2. Informational References . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
8.2. Informational References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 22
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 [RFC2119]. 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. See [I-D.ietf-simple-simple] for the list of RFCs and
interdomain presence subscriptions. The requirements are based on a drafts that are considered as part of the SIP/SIMPLE protocol. These
separate scaling analysis document 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]. [I-D.ietf-simple-interdomain-scaling-analysis].
3. Suggested Requirements 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.
In the presence scaling draft 2.1. Very large network peering
[I-D.ietf-simple-interdomain-scaling-analysis], several areas where
the deployment of a presence system is far from being trivial are In this environment, two or more very large networks create a peering
described, these include network load, memory load and CPU load. In relationship allowing their users to subscribe to presence in the
this section lists an initial set of requirements for a solution that other domains. Where as the number of users in other deployment
will optimize the interdomain presence traffic. 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:
o As users become accustomed to network boundaries disappearing,
federated subscriptions become as common as subscriptions within
the same domain
o Individual users are highly likely to want to see presence of
multiple presentities in the peer network
o 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)
o 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
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.
1. Maintain the state of the presentities to which watchers
subscribe.
2. 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:
o Subscription state including all the parameters that are needed in
order to maintain the subscription as timers.
o 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
o Optional rate management information as throttling
o Watcher information [RFC3857], [RFC3858] 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:
o 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.
o 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.
2.2.1. State Size Calculations
Assuming the following sizes, the state size is calculated for
various systems:
o 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.
o 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.
o 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:
o 10K subscriptions = 19M bytes.
o 5K subscribed to presentities = 5M bytes.
o 10K presentities with state = 58M bytes.
The total for tiny system is 82M bytes.
Medium System:
o 100K subscriptions = 195M bytes.
o 50K subscribed to presentities = 49M bytes.
o 100K presentities with state = 586M bytes.
The total for medium system is 830M bytes.
Large System:
o 6M subscriptions = 11,718M bytes.
o 3M subscribed to presentities = 2,929M bytes.
o 4M presentities with state = 23437M bytes.
The total for large system is 38G bytes.
Very Large System:
o 150M subscriptions = 292,969M bytes.
o 75M subscribed to presentities = 73,242M bytes.
o 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:
o 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.
o 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]) and the various presence servers that hold the
presence data. See section 4.5 in the presence scaling document
for more details.
o 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...
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].
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 deprecate existing protocol
SIMPLE clients and/or servers from peering with a domain or client mechanisms defined in SIP/SIMPLE. The ability of existing SIP/
implementing the solution. No changes may be required of existing SIMPLE clients and/or servers from peering with a domain or a
servers to interoperate. client implementing the solution SHOULD be retained with no
changes required of existing servers to interoperate.
o REQ-002: The solution SHOULD NOT constrain any existing RFC o REQ-002-A: The solution SHOULD NOT constrain any existing RFC
functional or security requirements for presence. functional requirements for presence.
o REQ-002-B: The solution MUST NOT constrain any existing RFC
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 SHOULD NOT limit the ability for o REQ-004: The solution SHOULD NOT limit the ability for
presentities to present different views of presence to different presentities to present different views of presence to different
watchers. watchers.
skipping to change at page 4, line 15 skipping to change at page 11, line 35
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: Presence systems (intra or inter-domain) SHOULD scale in o REQ-007: Presence systems (intra or inter-domain) SHOULD scale in
linear proportion to the number of watchers and presentities in linear proportion to the number of watchers and presentities in
the system. 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. then solutions based on current protocol in order to implement the
optimizations.
o REQ-009: It MUST be able to scale to tens of millions of o REQ-009: The solution MUST allow presence systems to scale. Note:
concurrent users in each domain and in each peer domain. we view scalability on the order of tens of millions of users in
each peer domain.
o REQ-010: There may be various usage patterns when users of one o REQ-010: There may be various usage patterns when users of one
domain subscribe to users from another domain. It may be that domain subscribe to users from another domain. It may be that
only small percentage of users from each domain will subscribe to only small percentage of users from each domain will subscribe to
users from the other domain, it may be that most watchers will be 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 from the other domain while there will be few watchers from the
other domain. The solution MUST support high percentage of same domain. The solution MUST support high percentage of
watcher/presentity intersections between the domains and it MUST watcher/presentity intersections between the domains and it MUST
support various intersection models. 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 especially where there is a high level
cross subscriptions between the domains. of 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 and indirect peering.
4. Considerations for Possible Optimizations 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
[I-D.ietf-simple-interdomain-scaling-analysis]. [I-D.ietf-simple-interdomain-scaling-analysis].
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 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 SIP/SIMPLE protocol. Organizations need to be prepared to
substantial resources in the form of networks and hardware in order invest substantial resources in the form of networks and hardware in
to create sizable systems. However, it is apparent that not all the order to create sizable systems. However, it is apparent that
possible optimizations were done yet and further work is needed in additional protocol optimizations are possible and further work is
the IETF in order to provide better scalability needed in the IETF in order to provide better scalability of large
presence systems.
Nevertheless, we should remember that SIP was originally designed for We should remember that SIP was originally designed for end to end
end to end session creation and number and size of messages are of session creation and number and size of messages are of secondary
secondary importance for end to end session negotiation. For large importance for an end to end session negotiation protocol. 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. Adequate care must be taken in addressing scalability as
different way. We need to think about scalability as part of the part of the initial protocol design phase; Trying to to shoehorn
protocol design. The IETF sometimes does not give the right priority scalability at a later phase will be doomed to failure.
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 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 (Resource List Servers [RFC4662]) and presence servers) between RLSs [RFC4662], and presence servers) there is a need to have
there is a need to have a different protocol that will be very a different protocol that will be very optimized for the load and can
optimized for the load and can assume some assumptions about the assume some assumptions about the network (for example do not use
network (e.g. do not use unreliable protocol as UDP but only TCP). 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 server is connecting to another server using current protocol, When a presence server connects to another server using the current
there will be an extreme number of redundant messages due to the SIP/SIMPLE protocol, there will be an extreme number of redundant
overhead in the SIP protocol of supporting both TCP and UDP and due messages due to the overhead in the SIP protocol of supporting both
to the need to send multiple presence documents for the same watched TCP and UDP and due to the need to send multiple presence documents
user because of privacy issues. A server to server protocol will for the same watched user because of privacy issues. A server to
have to address these issues. Some initial work to address these server protocol will have to address these issues. Some initial work
issues can be found in: 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-view-sharing] and
[I-D.ietf-simple-intradomain-federation] [I-D.ietf-simple-intradomain-federation] and in other (still
individual) drafts.
Another issue that is more concerning protocol design is whether Another issue that is more related to protocol design is whether
NOTIFY messages should not be considered as media just like audio, NOTIFY messages should not be considered as media just like audio,
video and even text messaging. The SUBSCRIBE method may be extended video and even text messaging. The SUBSCRIBE method may be extended
to negotiate the route and other parameters of the NOTIFY messages, to negotiate the route and other parameters of the NOTIFY messages,
in a similar way that the INVITE method is negotiating media in a similar way that the INVITE method negotiates media parameters.
parameters. This way the load can be offloaded to a specialized This way the load can be offloaded to a specialized NOTIFY "relays"
NOTIFY "relays" thus not loading the control path of SIP. One of the thus not loading the control path of SIP. One of the possible ideas
possible ideas (Marc Willekens) is to use the SIP protocol for (Marc Willekens) is to use the SIP protocol for client/server NOTIFY
client/server NOTIFY but make use of a more optimized and but make use of a more optimized and controllable protocol for the
controllable protocol for the server-to-server interface. Another server-to-server interface. Another possibility is to use the MSRP
possibility is to use the MSRP [RFC4975], [RFC4976]protocol for the [RFC4975], [RFC4976] protocol for the notifications.
notifies.
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:
o There is no 200 OK for each message. Since only TCP has to be
supported, there is not need to compensate for network issues.
o There is no refresh for subscriptions.
o There is no NOTIFY upon termination of SUBSCRIPTION
o 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
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 protocol and model. Many of the changes to the protocol
protocol will have security implications as mentioned in some of the 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 delegate 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. IANA Considerations 6. IANA Considerations
None. This document has no IANA actions.
7. Acknowledgments 7. Acknowledgments
We would like to thank Jonathan Rosenberg, Ben Campbell, Markus We would like to thank Jonathan Rosenberg, Ben Campbell, Markus
Isomaki Piotr Boni, David Viamonte, Aki Niemi, Marc Willekens Gonzalo Isomaki Piotr Boni, David Viamonte, Aki Niemi, Marc Willekens Gonzalo
Camarillo for their ideas and input. Special thanks to Vijay K. Camarillo for their ideas and input. Special thanks to Jean-Francois
Gurbani for the a detailed review. Mule, Vijay K. Gurbani and Hisham Khartabil for their a detailed
review.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informational References 8.2. Informational References
[I-D.houri-simple-interdomain-scaling-optimizations]
Houri, A., "Scaling Optimizations for Presence in SIP/
SIMPLE",
(work in progress), July 2007.
[I-D.ietf-simple-interdomain-scaling-analysis] [I-D.ietf-simple-interdomain-scaling-analysis]
Houri, A., Aoki, E., Parameswar, S., Rang, T., Singh, V., Houri, A., Aoki, E., Parameswar, S., Rang, T., Singh, V.,
and H. Schulzrinne, "Presence Interdomain Scaling Analysis and H. Schulzrinne, "Presence Interdomain Scaling Analysis
for SIP/SIMPLE", for SIP/SIMPLE",
draft-ietf-simple-interdomain-scaling-analysis-04 (work in draft-ietf-simple-interdomain-scaling-analysis-05 (work in
progress), February 2008. progress), October 2008.
[I-D.ietf-simple-intradomain-federation] [I-D.ietf-simple-intradomain-federation]
Rosenberg, J. and A. Houri, "Models for Intra-Domain Rosenberg, J., Houri, A., and C. Smyth, "Models for Intra-
Presence Federation", Domain Presence and Instant Messaging (IM) Federation",
draft-ietf-simple-intradomain-federation-00 (work in draft-ietf-simple-intradomain-federation-01 (work in
progress), February 2008. progress), July 2008.
[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-04 (work in progress),
October 2008.
[I-D.ietf-simple-view-sharing] [I-D.ietf-simple-view-sharing]
Rosenberg, J., Donovan, S., and K. McMurry, "Optimizing Rosenberg, J., Donovan, S., and K. McMurry, "Optimizing
Federated Presence with View Sharing", Federated Presence with View Sharing",
draft-ietf-simple-view-sharing-00 (work in progress), draft-ietf-simple-view-sharing-01 (work in progress),
February 2008. July 2008.
[RFC3857] Rosenberg, J., "A Watcher Information Event Template-
Package for the Session Initiation Protocol (SIP)",
RFC 3857, August 2004.
[RFC3858] Rosenberg, J., "An Extensible Markup Language (XML) Based
Format for Watcher Information", RFC 3858, August 2004.
[RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session
Initiation Protocol (SIP) Event Notification Extension for Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", RFC 4662, August 2006. Resource Lists", RFC 4662, August 2006.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007. Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions
for the Message Sessions Relay Protocol (MSRP)", RFC 4976, for the Message Sessions Relay Protocol (MSRP)", RFC 4976,
skipping to change at page 8, line 14 skipping to change at page 20, line 27
Sriram Parameswar Sriram Parameswar
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
Email: Sriram.Parameswar@microsoft.com Email: Sriram.Parameswar@microsoft.com
Edwin Aoki Edwin Aoki
AOL LLC AOL LLC
360 W. Caribbean Drive 401 Ellis St.
Sunnyvale, CA 94089 Mountain View, CA 94043
USA USA
Email: aoki@aol.net Email: aoki@aol.net
Vishal Singh Vishal Singh
Columbia University Columbia University
Department of Computer Science Department of Computer Science
450 Computer Science Building 450 Computer Science Building
New York, NY 10027 New York, NY 10027
US US
 End of changes. 33 change blocks. 
99 lines changed or deleted 695 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/