One document matched: draft-ietf-sipcore-presence-scaling-requirements-00.xml

<?xml version="1.0" encoding="UTF-8"?>


<rfc category="info" ipr="trust200811" docName="draft-ietf-sipcore-presence-scaling-requirements-00.txt">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>

<front> <title abbrev='Scaling Requirements for Presence'>Scaling Requirements for Presence in SIP/SIMPLE</title>

    <author initials="A." surname="Houri" fullname="Avshalom Houri"> 
<organization>IBM</organization> <address> <postal> <street>3 Pekris Street, Science Park 
</street> <city>Rehovot</city> <region></region> <code></code> 
<country>Israel</country> </postal> <email>avshalom@il.ibm.com</email> 
</address> </author>

    <author initials="S." surname="Parameswar" fullname="Sriram Parameswar"> 
<organization>Microsoft Corporation</organization> <address> <postal> 
<street>One Microsoft Way</street> <city>Redmond</city> <region>WA</region> 
<code>98052</code> <country>USA</country> </postal> 
<email>Sriram.Parameswar@microsoft.com</email> </address> </author>

 <author initials="E." surname="Aoki" fullname="Edwin Aoki">
<organization>AOL  LLC</organization>
<address> <postal> <street>401 Ellis St.</street> 
<city>Mountain View</city> <region>CA</region> <code>94043</code> 
<country>USA</country> </postal> <email>aoki@aol.net</email> </address> 
 </author>

    <author initials="V." surname="Singh" fullname="Vishal Singh"> 
<organization abbrev="Columbia U.">Columbia University</organization> <address> 
<postal> <street>Department of Computer Science</street> <street>450 Computer 
Science Building</street> <city>New York</city> <region>NY</region> 
<code>10027</code> <country>US</country> </postal> 
<email>vs2140@cs.columbia.edu</email> 
<uri>http://www.cs.columbia.edu/~vs2140</uri> </address> </author>

    <author initials="H." surname="Schulzrinne" fullname="Henning Schulzrinne"> 
<organization abbrev="Columbia U.">Columbia University</organization> <address> 
<postal> <street>Department of Computer Science</street> <street>450 Computer 
Science Building</street> <city>New York</city> <region>NY</region> 
<code>10027</code> <country>US</country> </postal> <phone>+1 212 939 
7004</phone> <email>hgs+ecrit@cs.columbia.edu</email> 
<uri>http://www.cs.columbia.edu/~hgs</uri> </address> </author>


    <date month="April" year="2009"/> <area>Real Time</area> 
<workgroup>SIPPING WG</workgroup> <keyword>I-D</keyword> <keyword>Internet-
Draft</keyword> <keyword>SIMPLE</keyword> <keyword>problem statement</keyword>

<abstract>

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

</abstract>

</front>

<middle>

<section title="Requirements notation">

<t>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 <xref target="RFC2119"/>.</t>

</section>

<section title="Introduction">

<t>The document lists requirements for optimizations of the SIP/SIMPLE protocol. 
See <xref target="I-D.ietf-simple-simple"/> 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 need for the requirements is based on a separate scaling analysis 
document <xref target="I-D.ietf-simple-interdomain-scaling-analysis" />.</t>

<t>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 bytes 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.</t>

<t>For example, for two peering networks that have total of 20 million users,
we got around 19 billion messages per 8 hours work day that needs to be exchanged
between the networks only for supporting the presence service.</t>

<t>For very large session peering (150 million subscriptions) we got a state 
close to a tera byte that needs to be managed by the server in order to manage 
presence.</t>

<t>It may be that when deploying a very large systems big resources need to be 
allocated but we should take into the considration the following:</t>

<t><list style="symbols">

<t>The assumptions that have been used in the scaling analysis document are 
very moderate from the aspect of number of presence status changes per hour and the
the size of the presence document that was assumed.<vspace blankLines='1' /></t>

<t>Even when applying all current drafted and/or RFCd optimizations for presence 
we still got around 10 billion messages per 8 hours work day for a total of 20 
million fedearting users. This is good but not enough given the moderate 
assumptions that we have used and given that when presence will be deployed to a 
mass market the number of federating users will be much more then 20 million 
federating users.</t>

</list></t>

</section>

<section title="Requirements">

<t>This section lists requirements for a solution that will optimize the 
interdomain presence loads. The requirements are based on the presence scaling 
draft <xref target="I-D.ietf-simple-interdomain-scaling-analysis" />.</t>

<section title="Backward Compatibility Requirements">

<t><list style="symbols">

<t>REQ-001: The solution SHOULD NOT deprecate existing protocol mechanisms 
defined in SIP/SIMPLE.<vspace blankLines='1' /></t>

<t>REQ-002: Existing SIP/SIMPLE clients SHOULD be able to communicate with 
clients and servers that implement new presence scaling features. 
<vspace blankLines='1' /></t>

<t>REQ-003: The solution SHOULD NOT constrain any existing RFC functional 
requirements for presence.<vspace blankLines='1' /></t>

<t>REQ-004: The solution MUST NOT constrain any existing RFC security 
requirements for presence.<vspace blankLines='1' /></t>

<t>REQ-005: Systems that are not using the new additions to the protocol SHOULD 
operate at the same level as they do today.<vspace blankLines='1' /></t>
</list></t>

</section>

<section title="Policy, Privacy, Permissions Requirements">

<t><list style="symbols">

<t>REQ-006: The solution SHOULD NOT limit the ability for presentities to present 
    different views of presence to different watchers.<vspace blankLines='1' /></t>

<t>REQ-007: The solution SHOULD NOT restrict the ability of a presentity to obtain 
    its list of watchers.<vspace blankLines='1' /></t>

<t>REQ-008: The solution MUST NOT create any new or make worse any existing 
privacy holes.<vspace blankLines='1' /></t>

</list></t>

</section>


<section title="Scalability Requirements">

<t><list style="symbols">

    <t>REQ-009: Presence systems (intra or inter-domain) SHOULD scale in linear 
    proportion to the number of watchers and presentities in the system.<vspace 
    blankLines='1' /></t>

    <t>REQ-010: The solution SHOULD NOT require a significant increase in the 
    size of state to maintain, compared to the current state size required by 
    SIP/SIMPLE.<vspace blankLines='1' /></t>

    <t>REQ-011: The solution MUST allow presence systems to scale. Note: we view 
    scalability on the order of tens of millions of users in each peer 
    domain.<vspace blankLines='1' /></t>

    <t>REQ-012: 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.<vspace blankLines='1' /></t>

    <t>REQ-013: Protocol changes MUST NOT prohibit optimizations in deployment 
    models where there is a high level of cross subscriptions between the 
    domains.<vspace blankLines='1' /></t>

    <t>REQ-014: 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.<vspace blankLines='1' /></t>

    </list></t>
    
</section>

<section title="Topology Requirements">

    <t><list style="symbols">

    <t>REQ-015: The solution SHOULD allow for arbitrary federation topologies 
    including direct and indirect peering.<vspace blankLines='1' /></t>


    </list></t>
    
</section>

</section>


<section title="Considerations for Possible Optimizations ">

<t>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 <xref target="I-D.ietf-simple-interdomain-scaling-analysis" />.
</t>

<t>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.</t>

<t>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.</t>

<t>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.</t>

<t>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  <xref target="RFC4662" 
/>, 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).</t>

<t>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: <xref target="I-D.ietf-simple-view-sharing"/>
and <xref target="I-D.ietf-simple-intradomain-federation"/>
and in other (still individual) drafts.</t>

<t>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 <xref 
target="RFC4975"/>, <xref target="RFC4976"/> protocol for the notifications.</t> 

</section>


    <section title="Security Considerations">

    <t>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.</t>

    <t>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</t>

    <t>Important part of work on the requirements and optimizations will be to make 
    sure that all the security aspects are covered.</t>

   </section>

	<section title="IANA Considerations">
		<t>This document has no IANA actions.</t>
	</section>
	
    <section title="Acknowledgments">

    <t>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.</t>

   </section>


   </middle>

    <back>
			<references title="Normative References">
				<?rfc include="reference.RFC.2119" ?>
			</references>
    	<references title="Informational References">
        <?rfc include="reference.RFC.3857" ?>
        <?rfc include="reference.RFC.3858" ?>
        <?rfc include="reference.RFC.4662" ?>
        <?rfc include="reference.RFC.4975" ?>
        <?rfc include="reference.RFC.4976" ?>
     		<?rfc include="reference.I-D.ietf-simple-simple" ?>
    		<?rfc include="reference.I-D.ietf-simple-interdomain-scaling-analysis" ?>
        <?rfc include="reference.I-D.ietf-simple-view-sharing" ?>
        <?rfc include="reference.I-D.ietf-simple-intradomain-federation" ?>
			</references>
    </back>
</rfc>