idnits 2.17.1 draft-ietf-sipcore-presence-scaling-requirements-00.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? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 date (April 20, 2009) is 5484 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3857' is defined on line 322, but no explicit reference was found in the text == Unused Reference: 'RFC3858' is defined on line 326, 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-03 == Outdated reference: A later version (-09) exists of draft-ietf-simple-simple-05 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). 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: October 22, 2009 Microsoft Corporation 6 E. Aoki 7 AOL LLC 8 V. Singh 9 H. Schulzrinne 10 Columbia U. 11 April 20, 2009 13 Scaling Requirements for Presence in SIP/SIMPLE 14 draft-ietf-sipcore-presence-scaling-requirements-00.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 October 22, 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 in effect on the date of 46 publication of this document (http://trustee.ietf.org/license-info). 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. 50 Abstract 52 The document provides a set of requirements for enabling interdomain 53 scaling in presence for SIP/SIMPLE. 55 Table of Contents 57 1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Backward Compatibility Requirements . . . . . . . . . . . . 4 61 3.2. Policy, Privacy, Permissions Requirements . . . . . . . . . 4 62 3.3. Scalability Requirements . . . . . . . . . . . . . . . . . 4 63 3.4. Topology Requirements . . . . . . . . . . . . . . . . . . . 5 64 4. Considerations for Possible Optimizations . . . . . . . . . . . 5 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 67 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 70 8.2. Informational References . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Requirements notation 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 2. Introduction 81 The document lists requirements for optimizations of the SIP/SIMPLE 82 protocol. See [I-D.ietf-simple-simple] for the list of RFCs and 83 drafts that are considered as part of the SIP/SIMPLE protocol. These 84 optimizations should reduce the load on the network and the presence 85 servers in interdomain presence subscriptions. The need for the 86 requirements is based on a separate scaling analysis document 87 [I-D.ietf-simple-interdomain-scaling-analysis]. 89 The scaling analysis document have shown that there is much room for 90 optimizations in the SIP/SIMPLE protocol. The need for optimizations 91 is in the number of bytes that are sent between two federating 92 domains, the number of messages that need to be processed and the 93 amount of state that needs to be managed by the presence servers. 95 For example, for two peering networks that have total of 20 million 96 users, we got around 19 billion messages per 8 hours work day that 97 needs to be exchanged between the networks only for supporting the 98 presence service. 100 For very large session peering (150 million subscriptions) we got a 101 state close to a tera byte that needs to be managed by the server in 102 order to manage presence. 104 It may be that when deploying a very large systems big resources need 105 to be allocated but we should take into the considration the 106 following: 108 o The assumptions that have been used in the scaling analysis 109 document are very moderate from the aspect of number of presence 110 status changes per hour and the the size of the presence document 111 that was assumed. 113 o Even when applying all current drafted and/or RFCd optimizations 114 for presence we still got around 10 billion messages per 8 hours 115 work day for a total of 20 million fedearting users. This is good 116 but not enough given the moderate assumptions that we have used 117 and given that when presence will be deployed to a mass market the 118 number of federating users will be much more then 20 million 119 federating users. 121 3. Requirements 123 This section lists requirements for a solution that will optimize the 124 interdomain presence loads. The requirements are based on the 125 presence scaling draft 126 [I-D.ietf-simple-interdomain-scaling-analysis]. 128 3.1. Backward Compatibility Requirements 130 o REQ-001: The solution SHOULD NOT deprecate existing protocol 131 mechanisms defined in SIP/SIMPLE. 133 o REQ-002: Existing SIP/SIMPLE clients SHOULD be able to communicate 134 with clients and servers that implement new presence scaling 135 features. 137 o REQ-003: The solution SHOULD NOT constrain any existing RFC 138 functional requirements for presence. 140 o REQ-004: The solution MUST NOT constrain any existing RFC security 141 requirements for presence. 143 o REQ-005: Systems that are not using the new additions to the 144 protocol SHOULD operate at the same level as they do today. 146 3.2. Policy, Privacy, Permissions Requirements 148 o REQ-006: The solution SHOULD NOT limit the ability for 149 presentities to present different views of presence to different 150 watchers. 152 o REQ-007: The solution SHOULD NOT restrict the ability of a 153 presentity to obtain its list of watchers. 155 o REQ-008: The solution MUST NOT create any new or make worse any 156 existing privacy holes. 158 3.3. Scalability Requirements 160 o REQ-009: Presence systems (intra or inter-domain) SHOULD scale in 161 linear proportion to the number of watchers and presentities in 162 the system. 164 o REQ-010: The solution SHOULD NOT require a significant increase in 165 the size of state to maintain, compared to the current state size 166 required by SIP/SIMPLE. 168 o REQ-011: The solution MUST allow presence systems to scale. Note: 169 we view scalability on the order of tens of millions of users in 170 each peer domain. 172 o REQ-012: There may be various usage patterns when users of one 173 domain subscribe to users from another domain. It may be that 174 only small percentage of users from each domain will subscribe to 175 users from the other domain, it may be that most watchers will be 176 from the other domain while there will be few watchers from the 177 same domain. The solution MUST support high percentage of 178 watcher/presentity intersections between the domains and it MUST 179 support various intersection models. 181 o REQ-013: Protocol changes MUST NOT prohibit optimizations in 182 deployment models where there is a high level of cross 183 subscriptions between the domains. 185 o REQ-014: New functionalities and extensions to the presence 186 protocol SHOULD take into account scalability with respect to the 187 number of messages, state size and management and processing load. 189 3.4. Topology Requirements 191 o REQ-015: The solution SHOULD allow for arbitrary federation 192 topologies including direct and indirect peering. 194 4. Considerations for Possible Optimizations 196 The document provides an initial list of requirements for a solution 197 of scalability of interdomain presence systems using the SIP/SIMPLE 198 protocol. The issue of scalability was shown in a separate document 199 [I-D.ietf-simple-interdomain-scaling-analysis]. 201 The following is a discussion of the various possible paths for 202 optimizations. One of the most important considerations is whether 203 there is a need to adapt SIP that was designed more as an end to end 204 protocol to be much more optimized when presence server interacts 205 directly with another presence server. 207 It is very possible that the issues that are described in this 208 document are inherent to presence systems in general and not specific 209 to the SIP/SIMPLE protocol. Organizations need to be prepared to 210 invest substantial resources in the form of networks and hardware in 211 order to create sizable systems. However, it is apparent that 212 additional protocol optimizations are possible and further work is 213 needed in the IETF in order to provide better scalability of large 214 presence systems. 216 We should remember that SIP was originally designed for end to end 217 session creation and number and size of messages are of secondary 218 importance for an end to end session negotiation protocol. For large 219 scale and especially for very large scale presence the number of 220 messages that are needed and the size of each message are of extreme 221 importance. Adequate care must be taken in addressing scalability as 222 part of the initial protocol design phase; Trying to to shoehorn 223 scalability at a later phase will be doomed to failure. 225 We should also consider whether using the same protocol between 226 clients and servers and between servers is a good choice. It may be 227 that in interdomain or even between servers in the same domain (as 228 between RLSs [RFC4662], and presence servers) there is a need to have 229 a different protocol that will be very optimized for the load and can 230 assume some assumptions about the network (for example do not use 231 unreliable protocol as UDP but only TCP, see the section that 232 calculates the number of bytes and messages for imaginary very 233 optimized SIP). 235 When a presence server connects to another server using the current 236 SIP/SIMPLE protocol, there will be an extreme number of redundant 237 messages due to the overhead in the SIP protocol of supporting both 238 TCP and UDP and due to the need to send multiple presence documents 239 for the same watched user because of privacy issues. A server to 240 server protocol will have to address these issues. Some initial work 241 to address these issues can be found in: 242 [I-D.ietf-simple-view-sharing] and 243 [I-D.ietf-simple-intradomain-federation] and in other (still 244 individual) drafts. 246 Another issue that is more related to protocol design is whether 247 NOTIFY messages should not be considered as media just like audio, 248 video and even text messaging. The SUBSCRIBE method may be extended 249 to negotiate the route and other parameters of the NOTIFY messages, 250 in a similar way that the INVITE method negotiates media parameters. 251 This way the load can be offloaded to a specialized NOTIFY "relays" 252 thus not loading the control path of SIP. One of the possible ideas 253 (Marc Willekens) is to use the SIP protocol for client/server NOTIFY 254 but make use of a more optimized and controllable protocol for the 255 server-to-server interface. Another possibility is to use the MSRP 256 [RFC4975], [RFC4976] protocol for the notifications. 258 5. Security Considerations 260 This document discusses scalability requirements for the existing 261 SIP/SIMPLE protocol and model. Many of the changes to the protocol 262 will have security implications as mentioned in some of the 263 requirements above. 265 One example of possible protocol changes that may have security 266 implications is sending a presence document only once between domains 267 in order to optimize the number of messages and network load. This 268 possible optimization will delegate privacy protection from one 269 domain to another domain and should be addressed when designing 270 protocol optimizations 272 Important part of work on the requirements and optimizations will be 273 to make sure that all the security aspects are covered. 275 6. IANA Considerations 277 This document has no IANA actions. 279 7. Acknowledgments 281 We would like to thank Jonathan Rosenberg, Ben Campbell, Markus 282 Isomaki Piotr Boni, David Viamonte, Aki Niemi, Marc Willekens Gonzalo 283 Camarillo for their ideas and input. Special thanks to Jean-Francois 284 Mule, Vijay K. Gurbani and Hisham Khartabil for their a detailed 285 review. 287 8. References 289 8.1. Normative References 291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 292 Requirement Levels", BCP 14, RFC 2119, March 1997. 294 8.2. Informational References 296 [I-D.ietf-simple-interdomain-scaling-analysis] 297 Houri, A., Aoki, E., Parameswar, S., Rang, T., Singh, V., 298 and H. Schulzrinne, "Presence Interdomain Scaling Analysis 299 for SIP/SIMPLE", 300 draft-ietf-simple-interdomain-scaling-analysis-05 (work in 301 progress), October 2008. 303 [I-D.ietf-simple-intradomain-federation] 304 Rosenberg, J., Houri, A., Smyth, C., and F. Audet, "Models 305 for Intra-Domain Presence and Instant Messaging (IM) 306 Bridging", draft-ietf-simple-intradomain-federation-03 307 (work in progress), March 2009. 309 [I-D.ietf-simple-simple] 310 Rosenberg, J., "SIMPLE made Simple: An Overview of the 311 IETF Specifications for Instant Messaging and Presence 312 using the Session Initiation Protocol (SIP)", 313 draft-ietf-simple-simple-05 (work in progress), 314 March 2009. 316 [I-D.ietf-simple-view-sharing] 317 Rosenberg, J., Donovan, S., and K. McMurry, "Optimizing 318 Federated Presence with View Sharing", 319 draft-ietf-simple-view-sharing-02 (work in progress), 320 November 2008. 322 [RFC3857] Rosenberg, J., "A Watcher Information Event Template- 323 Package for the Session Initiation Protocol (SIP)", 324 RFC 3857, August 2004. 326 [RFC3858] Rosenberg, J., "An Extensible Markup Language (XML) Based 327 Format for Watcher Information", RFC 3858, August 2004. 329 [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session 330 Initiation Protocol (SIP) Event Notification Extension for 331 Resource Lists", RFC 4662, August 2006. 333 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 334 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 336 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 337 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 338 September 2007. 340 Authors' Addresses 342 Avshalom Houri 343 IBM 344 3 Pekris Street, Science Park 345 Rehovot, 346 Israel 348 Email: avshalom@il.ibm.com 349 Sriram Parameswar 350 Microsoft Corporation 351 One Microsoft Way 352 Redmond, WA 98052 353 USA 355 Email: Sriram.Parameswar@microsoft.com 357 Edwin Aoki 358 AOL LLC 359 401 Ellis St. 360 Mountain View, CA 94043 361 USA 363 Email: aoki@aol.net 365 Vishal Singh 366 Columbia University 367 Department of Computer Science 368 450 Computer Science Building 369 New York, NY 10027 370 US 372 Email: vs2140@cs.columbia.edu 373 URI: http://www.cs.columbia.edu/~vs2140 375 Henning Schulzrinne 376 Columbia University 377 Department of Computer Science 378 450 Computer Science Building 379 New York, NY 10027 380 US 382 Phone: +1 212 939 7004 383 Email: hgs+ecrit@cs.columbia.edu 384 URI: http://www.cs.columbia.edu/~hgs