One document matched: draft-ietf-sipping-presence-scaling-requirements-01.xml

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


<rfc category="info" ipr="full3978" docName="draft-ietf-sipping-presence-scaling-requirements-01.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>360 W. Caribbean 
Drive</street> <city>Sunnyvale</city> <region>CA</region> <code>94089</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="July" year="2008"/> <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. 
These optimizations should  reduce the traffic in interdomain presence 
subscriptions. The requirements are based on a separate scaling analysis 
document <xref target="I-D.ietf-simple-interdomain-scaling-analysis" />.</t>


</section>

<section title="Suggested Requirements">

<t>In the presence scaling draft  <xref target="I-D.ietf-simple-interdomain-scaling-analysis" />,
several areas where the deployment of a presence system is far 
from being trivial are described, these include network load, memory load and 
CPU load. In this section lists an initial set of requirements for a solution that will optimize
the interdomain presence traffic.</t>

<section title="Backward Compatibility Requirements">

<t><list style="symbols">

<t>REQ-001: The solution SHOULD NOT hinder the ability of existing SIMPLE 
clients and/or servers from peering with a domain or client implementing the 
solution.  No changes may be required of existing servers to interoperate.<vspace blankLines='1' /></t>

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

<t>REQ-003: 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-004: The solution SHOULD NOT limit the ability for presentities to present 
    different views of presence to different watchers.<vspace blankLines='1' /></t>

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

<t>REQ-006: 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-007: 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-008: The solution SHOULD NOT require significantly more state in order to 
    implement the solution.<vspace blankLines='1' /></t>

    <t>REQ-009: It MUST be able to scale to tens of millions of concurrent users in 
    each domain and in each peer domain.<vspace blankLines='1' /></t>

    <t>REQ-010: There may be various usage patterns when users of one domain 
    subscribe to users from another domain. It may be that only small 
    percentage of users from each domain will subscribe to users from the other 
    domain, it may be that most watchers will be coming from one domain while 
    there will be few watchers form the other domain. The solution MUST support 
    high percentage of watcher/presentity intersections between the domains and 
    it MUST support various intersection models.<vspace blankLines='1' /></t>

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

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

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

<section title="Topology Requirements">

    <t><list style="symbols">

    <t>REQ-013: The solution SHOULD allow for arbitrary federation topologies 
    including direct peering and intermediary routing.<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>It is very possible that the issues that are described in this document are 
inherent to presence systems in general and not specific to the SIMPLE protocol. 
Organizations need to be prepared to invest substantial resources in the form of 
networks and hardware in order to create sizable systems. However, it is 
apparent that not all the possible optimizations were done yet and further work 
is needed in the IETF in order to provide better scalability</t>

<t> Nevertheless, we should remember that SIP was originally designed for end to 
end session creation and number and size of messages are of secondary importance 
for end to end session negotiation. For large scale and especially for very 
large scale presence the number of messages that are needed and the size of each 
message are of extreme importance. It seems that we need to think about the 
problem in a different way. We need to think about scalability as part of the 
protocol design. The IETF sometimes does not give the right priority to actual 
deployments when designing a protocol but in this case it seems that if we do 
not think about scalability with the protocol design it will be very hard to 
scale.</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 (Resource List Servers 
<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 (e.g. 
do not use unreliable protocol as UDP but only TCP).</t>

<t>When a server is connecting to another server using current protocol, there 
will be an extreme number of redundant messages due to the overhead in the SIP protocol of 
supporting both TCP and UDP and due to the need to send multiple presence documents for the same 
watched user because of privacy issues. A server to server protocol will have to 
address these issues. Some initial work to address these issues can be found in: 
<xref target="I-D.houri-simple-interdomain-scaling-optimizations" />, <xref 
target="I-D.ietf-simple-view-sharing"/> and <xref target="I-D.ietf-simple-intradomain-federation"/></t>

<t>Another issue that is more concerning protocol design is whether NOTIFY 
messages should not be considered as media just like audio, video and even text 
messaging. The SUBSCRIBE method may be extended to negotiate the route and other 
parameters of the NOTIFY messages, in a similar way that the INVITE method is 
negotiating media parameters. This way the load can be offloaded to a 
specialized NOTIFY "relays" thus not loading the control path of SIP. One of the 
possible ideas (Marc Willekens) is to use the SIP protocol for client/server 
NOTIFY but make use of a more optimized and controllable protocol for the 
server-to-server interface. Another possibility is to use the MSRP <xref 
target="RFC4975"/>, <xref target="RFC4976"/>protocol for the notifies.</t> 
</section>


    <section title="Security Considerations">

    <t>This document discusses scalability requirements for the existing 
    SIP/SIMPLE presence protocol and model. Many of the changes to the protocol 
    will have security implications as mentioned in some of the requirements 
    above.</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>None.</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 Vijay K. Gurbani for the 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.4662" ?>
        <?rfc include="reference.RFC.4975" ?>
        <?rfc include="reference.RFC.4976" ?>
    		<?rfc include="reference.I-D.ietf-simple-interdomain-scaling-analysis" ?>
        <?rfc include="reference.I-D.houri-simple-interdomain-scaling-optimizations" ?>
        <?rfc include="reference.I-D.ietf-simple-view-sharing" ?>
        <?rfc include="reference.I-D.ietf-simple-intradomain-federation" ?>
			</references>
    </back>
</rfc>