idnits 2.17.1 draft-ietf-sipping-presence-scaling-requirements-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 27, 2009) is 5567 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3857' is defined on line 323, but no explicit reference was found in the text == Unused Reference: 'RFC3858' is defined on line 327, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-simple-interdomain-scaling-analysis-05 == Outdated reference: A later version (-05) exists of draft-ietf-simple-intradomain-federation-02 == Outdated reference: A later version (-09) exists of draft-ietf-simple-simple-04 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING WG A. Houri 3 Internet-Draft IBM 4 Intended status: Informational S. Parameswar 5 Expires: July 31, 2009 Microsoft Corporation 6 E. Aoki 7 AOL LLC 8 V. Singh 9 H. Schulzrinne 10 Columbia U. 11 January 27, 2009 13 Scaling Requirements for Presence in SIP/SIMPLE 14 draft-ietf-sipping-presence-scaling-requirements-03.txt 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on July 31, 2009. 39 Copyright Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. 51 Abstract 53 The document provides a set of requirements for enabling interdomain 54 scaling in presence for SIP/SIMPLE. 56 Table of Contents 58 1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Backward Compatibility Requirements . . . . . . . . . . . . 4 62 3.2. Policy, Privacy, Permissions Requirements . . . . . . . . . 4 63 3.3. Scalability Requirements . . . . . . . . . . . . . . . . . 4 64 3.4. Topology Requirements . . . . . . . . . . . . . . . . . . . 5 65 4. Considerations for Possible Optimizations . . . . . . . . . . . 5 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 68 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 71 8.2. Informational References . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Requirements notation 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [RFC2119]. 80 2. Introduction 82 The document lists requirements for optimizations of the SIP/SIMPLE 83 protocol. See [I-D.ietf-simple-simple] for the list of RFCs and 84 drafts that are considered as part of the SIP/SIMPLE protocol. These 85 optimizations should reduce the load on the network and the presence 86 servers in interdomain presence subscriptions. The need for the 87 requirements is based on a separate scaling analysis document 88 [I-D.ietf-simple-interdomain-scaling-analysis]. 90 The scaling analysis document have shown that there is much room for 91 optimizations in the SIP/SIMPLE protocol. The need for optimizations 92 is in the number of bytes that are sent between two federating 93 domains, the number of messages that need to be processed and the 94 amount of state that needs to be managed by the presence servers. 96 For example, for two peering networks that have total of 20 million 97 users, we got around 19 billion messages per 8 hours work day that 98 needs to be exchanged between the networks only for supporting the 99 presence service. 101 For very large session peering (150 million subscriptions) we got a 102 state close to a tera byte that needs to be managed by the server in 103 order to manage presence. 105 It may be that when deploying a very large systems big resources need 106 to be allocated but we should take into the considration the 107 following: 109 o The assumptions that have been used in the scaling analysis 110 document are very moderate from the aspect of number of presence 111 status changes per hour and the the size of the presence document 112 that was assumed. 114 o Even when applying all current drafted and/or RFCd optimizations 115 for presence we still got around 10 billion messages per 8 hours 116 work day for a total of 20 million fedearting users. This is good 117 but not enough given the moderate assumptions that we have used 118 and given that when presence will be deployed to a mass market the 119 number of federating users will be much more then 20 million 120 federating users. 122 3. Requirements 124 This section lists requirements for a solution that will optimize the 125 interdomain presence loads. The requirements are based on the 126 presence scaling draft 127 [I-D.ietf-simple-interdomain-scaling-analysis]. 129 3.1. Backward Compatibility Requirements 131 o REQ-001: The solution SHOULD NOT deprecate existing protocol 132 mechanisms defined in SIP/SIMPLE. 134 o REQ-002: Existing SIP/SIMPLE clients SHOULD be able to communicate 135 with clients and servers that implement new presence scaling 136 features. 138 o REQ-003: The solution SHOULD NOT constrain any existing RFC 139 functional requirements for presence. 141 o REQ-004: The solution MUST NOT constrain any existing RFC security 142 requirements for presence. 144 o REQ-005: Systems that are not using the new additions to the 145 protocol SHOULD operate at the same level as they do today. 147 3.2. Policy, Privacy, Permissions Requirements 149 o REQ-006: The solution SHOULD NOT limit the ability for 150 presentities to present different views of presence to different 151 watchers. 153 o REQ-007: The solution SHOULD NOT restrict the ability of a 154 presentity to obtain its list of watchers. 156 o REQ-008: The solution MUST NOT create any new or make worse any 157 existing privacy holes. 159 3.3. Scalability Requirements 161 o REQ-009: Presence systems (intra or inter-domain) SHOULD scale in 162 linear proportion to the number of watchers and presentities in 163 the system. 165 o REQ-010: The solution SHOULD NOT require a significant increase in 166 the size of state to maintain, compared to the current state size 167 required by SIP/SIMPLE. 169 o REQ-011: The solution MUST allow presence systems to scale. Note: 170 we view scalability on the order of tens of millions of users in 171 each peer domain. 173 o REQ-012: There may be various usage patterns when users of one 174 domain subscribe to users from another domain. It may be that 175 only small percentage of users from each domain will subscribe to 176 users from the other domain, it may be that most watchers will be 177 from the other domain while there will be few watchers from the 178 same domain. The solution MUST support high percentage of 179 watcher/presentity intersections between the domains and it MUST 180 support various intersection models. 182 o REQ-013: Protocol changes MUST NOT prohibit optimizations in 183 deployment models where there is a high level of cross 184 subscriptions between the domains. 186 o REQ-014: New functionalities and extensions to the presence 187 protocol SHOULD take into account scalability with respect to the 188 number of messages, state size and management and processing load. 190 3.4. Topology Requirements 192 o REQ-015: The solution SHOULD allow for arbitrary federation 193 topologies including direct and indirect peering. 195 4. Considerations for Possible Optimizations 197 The document provides an initial list of requirements for a solution 198 of scalability of interdomain presence systems using the SIP/SIMPLE 199 protocol. The issue of scalability was shown in a separate document 200 [I-D.ietf-simple-interdomain-scaling-analysis]. 202 The following is a discussion of the various possible paths for 203 optimizations. One of the most important considerations is whether 204 there is a need to adapt SIP that was designed more as an end to end 205 protocol to be much more optimized when presence server interacts 206 directly with another presence server. 208 It is very possible that the issues that are described in this 209 document are inherent to presence systems in general and not specific 210 to the SIP/SIMPLE protocol. Organizations need to be prepared to 211 invest substantial resources in the form of networks and hardware in 212 order to create sizable systems. However, it is apparent that 213 additional protocol optimizations are possible and further work is 214 needed in the IETF in order to provide better scalability of large 215 presence systems. 217 We should remember that SIP was originally designed for end to end 218 session creation and number and size of messages are of secondary 219 importance for an end to end session negotiation protocol. For large 220 scale and especially for very large scale presence the number of 221 messages that are needed and the size of each message are of extreme 222 importance. Adequate care must be taken in addressing scalability as 223 part of the initial protocol design phase; Trying to to shoehorn 224 scalability at a later phase will be doomed to failure. 226 We should also consider whether using the same protocol between 227 clients and servers and between servers is a good choice. It may be 228 that in interdomain or even between servers in the same domain (as 229 between RLSs [RFC4662], and presence servers) there is a need to have 230 a different protocol that will be very optimized for the load and can 231 assume some assumptions about the network (for example do not use 232 unreliable protocol as UDP but only TCP, see the section that 233 calculates the number of bytes and messages for imaginary very 234 optimized SIP). 236 When a presence server connects to another server using the current 237 SIP/SIMPLE protocol, there will be an extreme number of redundant 238 messages due to the overhead in the SIP protocol of supporting both 239 TCP and UDP and due to the need to send multiple presence documents 240 for the same watched user because of privacy issues. A server to 241 server protocol will have to address these issues. Some initial work 242 to address these issues can be found in: 243 [I-D.ietf-simple-view-sharing] and 244 [I-D.ietf-simple-intradomain-federation] and in other (still 245 individual) drafts. 247 Another issue that is more related to protocol design is whether 248 NOTIFY messages should not be considered as media just like audio, 249 video and even text messaging. The SUBSCRIBE method may be extended 250 to negotiate the route and other parameters of the NOTIFY messages, 251 in a similar way that the INVITE method negotiates media parameters. 252 This way the load can be offloaded to a specialized NOTIFY "relays" 253 thus not loading the control path of SIP. One of the possible ideas 254 (Marc Willekens) is to use the SIP protocol for client/server NOTIFY 255 but make use of a more optimized and controllable protocol for the 256 server-to-server interface. Another possibility is to use the MSRP 257 [RFC4975], [RFC4976] protocol for the notifications. 259 5. Security Considerations 261 This document discusses scalability requirements for the existing 262 SIP/SIMPLE protocol and model. Many of the changes to the protocol 263 will have security implications as mentioned in some of the 264 requirements above. 266 One example of possible protocol changes that may have security 267 implications is sending a presence document only once between domains 268 in order to optimize the number of messages and network load. This 269 possible optimization will delegate privacy protection from one 270 domain to another domain and should be addressed when designing 271 protocol optimizations 273 Important part of work on the requirements and optimizations will be 274 to make sure that all the security aspects are covered. 276 6. IANA Considerations 278 This document has no IANA actions. 280 7. Acknowledgments 282 We would like to thank Jonathan Rosenberg, Ben Campbell, Markus 283 Isomaki Piotr Boni, David Viamonte, Aki Niemi, Marc Willekens Gonzalo 284 Camarillo for their ideas and input. Special thanks to Jean-Francois 285 Mule, Vijay K. Gurbani and Hisham Khartabil for their a detailed 286 review. 288 8. References 290 8.1. Normative References 292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 293 Requirement Levels", BCP 14, RFC 2119, March 1997. 295 8.2. Informational References 297 [I-D.ietf-simple-interdomain-scaling-analysis] 298 Houri, A., Aoki, E., Parameswar, S., Rang, T., Singh, V., 299 and H. Schulzrinne, "Presence Interdomain Scaling Analysis 300 for SIP/SIMPLE", 301 draft-ietf-simple-interdomain-scaling-analysis-05 (work in 302 progress), October 2008. 304 [I-D.ietf-simple-intradomain-federation] 305 Rosenberg, J., Houri, A., Smyth, C., and F. Audet, "Models 306 for Intra-Domain Presence and Instant Messaging (IM) 307 Bridging", draft-ietf-simple-intradomain-federation-02 308 (work in progress), November 2008. 310 [I-D.ietf-simple-simple] 311 Rosenberg, J., "SIMPLE made Simple: An Overview of the 312 IETF Specifications for Instant Messaging and Presence 313 using the Session Initiation Protocol (SIP)", 314 draft-ietf-simple-simple-04 (work in progress), 315 October 2008. 317 [I-D.ietf-simple-view-sharing] 318 Rosenberg, J., Donovan, S., and K. McMurry, "Optimizing 319 Federated Presence with View Sharing", 320 draft-ietf-simple-view-sharing-02 (work in progress), 321 November 2008. 323 [RFC3857] Rosenberg, J., "A Watcher Information Event Template- 324 Package for the Session Initiation Protocol (SIP)", 325 RFC 3857, August 2004. 327 [RFC3858] Rosenberg, J., "An Extensible Markup Language (XML) Based 328 Format for Watcher Information", RFC 3858, August 2004. 330 [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session 331 Initiation Protocol (SIP) Event Notification Extension for 332 Resource Lists", RFC 4662, August 2006. 334 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 335 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 337 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 338 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 339 September 2007. 341 Authors' Addresses 343 Avshalom Houri 344 IBM 345 3 Pekris Street, Science Park 346 Rehovot, 347 Israel 349 Email: avshalom@il.ibm.com 350 Sriram Parameswar 351 Microsoft Corporation 352 One Microsoft Way 353 Redmond, WA 98052 354 USA 356 Email: Sriram.Parameswar@microsoft.com 358 Edwin Aoki 359 AOL LLC 360 401 Ellis St. 361 Mountain View, CA 94043 362 USA 364 Email: aoki@aol.net 366 Vishal Singh 367 Columbia University 368 Department of Computer Science 369 450 Computer Science Building 370 New York, NY 10027 371 US 373 Email: vs2140@cs.columbia.edu 374 URI: http://www.cs.columbia.edu/~vs2140 376 Henning Schulzrinne 377 Columbia University 378 Department of Computer Science 379 450 Computer Science Building 380 New York, NY 10027 381 US 383 Phone: +1 212 939 7004 384 Email: hgs+ecrit@cs.columbia.edu 385 URI: http://www.cs.columbia.edu/~hgs