idnits 2.17.1 draft-ietf-sipping-presence-scaling-requirements-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 338. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 349. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 356. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 362. 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 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 (July 3, 2008) is 5776 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-simple-interdomain-scaling-analysis-04 == Outdated reference: A later version (-05) exists of draft-ietf-simple-intradomain-federation-00 == Outdated reference: A later version (-02) exists of draft-ietf-simple-view-sharing-00 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 7 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: January 4, 2009 Microsoft Corporation 6 E. Aoki 7 AOL LLC 8 V. Singh 9 H. Schulzrinne 10 Columbia U. 11 July 3, 2008 13 Scaling Requirements for Presence in SIP/SIMPLE 14 draft-ietf-sipping-presence-scaling-requirements-01.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on January 4, 2009. 41 Abstract 43 The document provides a set of requirements for enabling interdomain 44 scaling in presence for SIP/SIMPLE. 46 Table of Contents 48 1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 49 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Suggested Requirements . . . . . . . . . . . . . . . . . . . . 3 51 3.1. Backward Compatibility Requirements . . . . . . . . . . . . 3 52 3.2. Policy, Privacy, Permissions Requirements . . . . . . . . . 3 53 3.3. Scalability Requirements . . . . . . . . . . . . . . . . . 4 54 3.4. Topology Requirements . . . . . . . . . . . . . . . . . . . 4 55 4. Considerations for Possible Optimizations . . . . . . . . . . . 4 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 58 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 61 8.2. Informational References . . . . . . . . . . . . . . . . . 6 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 63 Intellectual Property and Copyright Statements . . . . . . . . . . 9 65 1. Requirements notation 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in [RFC2119]. 71 2. Introduction 73 The document lists requirements for optimizations of the SIP/SIMPLE 74 protocol. These optimizations should reduce the traffic in 75 interdomain presence subscriptions. The requirements are based on a 76 separate scaling analysis document 77 [I-D.ietf-simple-interdomain-scaling-analysis]. 79 3. Suggested Requirements 81 In the presence scaling draft 82 [I-D.ietf-simple-interdomain-scaling-analysis], several areas where 83 the deployment of a presence system is far from being trivial are 84 described, these include network load, memory load and CPU load. In 85 this section lists an initial set of requirements for a solution that 86 will optimize the interdomain presence traffic. 88 3.1. Backward Compatibility Requirements 90 o REQ-001: The solution SHOULD NOT hinder the ability of existing 91 SIMPLE clients and/or servers from peering with a domain or client 92 implementing the solution. No changes may be required of existing 93 servers to interoperate. 95 o REQ-002: The solution SHOULD NOT constrain any existing RFC 96 functional or security requirements for presence. 98 o REQ-003: Systems that are not using the new additions to the 99 protocol SHOULD operate at the same level as they do today. 101 3.2. Policy, Privacy, Permissions Requirements 103 o REQ-004: The solution SHOULD NOT limit the ability for 104 presentities to present different views of presence to different 105 watchers. 107 o REQ-005: The solution SHOULD NOT restrict the ability of a 108 presentity to obtain its list of watchers. 110 o REQ-006: The solution MUST NOT create any new or make worse any 111 existing privacy holes. 113 3.3. Scalability Requirements 115 o REQ-007: Presence systems (intra or inter-domain) SHOULD scale in 116 linear proportion to the number of watchers and presentities in 117 the system. 119 o REQ-008: The solution SHOULD NOT require significantly more state 120 in order to implement the solution. 122 o REQ-009: It MUST be able to scale to tens of millions of 123 concurrent users in each domain and in each peer domain. 125 o REQ-010: There may be various usage patterns when users of one 126 domain subscribe to users from another domain. It may be that 127 only small percentage of users from each domain will subscribe to 128 users from the other domain, it may be that most watchers will be 129 coming from one domain while there will be few watchers form the 130 other domain. The solution MUST support high percentage of 131 watcher/presentity intersections between the domains and it MUST 132 support various intersection models. 134 o REQ-011: Protocol changes MUST NOT prohibit optimizations in 135 different deployment models esp. where there is a high level of 136 cross subscriptions between the domains. 138 o REQ-012: New functionalities and extensions to the presence 139 protocol SHOULD take into account scalability with respect to the 140 number of messages, state size and management and processing load. 142 3.4. Topology Requirements 144 o REQ-013: The solution SHOULD allow for arbitrary federation 145 topologies including direct peering and intermediary routing. 147 4. Considerations for Possible Optimizations 149 The document provides an initial list of requirements for a solution 150 of scalability of interdomain presence systems using the SIP/SIMPLE 151 protocol. The issue of scalability was shown in a separate document 152 [I-D.ietf-simple-interdomain-scaling-analysis]. 154 It is very possible that the issues that are described in this 155 document are inherent to presence systems in general and not specific 156 to the SIMPLE protocol. Organizations need to be prepared to invest 157 substantial resources in the form of networks and hardware in order 158 to create sizable systems. However, it is apparent that not all the 159 possible optimizations were done yet and further work is needed in 160 the IETF in order to provide better scalability 162 Nevertheless, we should remember that SIP was originally designed for 163 end to end session creation and number and size of messages are of 164 secondary importance for end to end session negotiation. For large 165 scale and especially for very large scale presence the number of 166 messages that are needed and the size of each message are of extreme 167 importance. It seems that we need to think about the problem in a 168 different way. We need to think about scalability as part of the 169 protocol design. The IETF sometimes does not give the right priority 170 to actual deployments when designing a protocol but in this case it 171 seems that if we do not think about scalability with the protocol 172 design it will be very hard to scale. 174 We should also consider whether using the same protocol between 175 clients and servers and between servers is a good choice. It may be 176 that in interdomain or even between servers in the same domain (as 177 between RLSs (Resource List Servers [RFC4662]) and presence servers) 178 there is a need to have a different protocol that will be very 179 optimized for the load and can assume some assumptions about the 180 network (e.g. do not use unreliable protocol as UDP but only TCP). 182 When a server is connecting to another server using current protocol, 183 there will be an extreme number of redundant messages due to the 184 overhead in the SIP protocol of supporting both TCP and UDP and due 185 to the need to send multiple presence documents for the same watched 186 user because of privacy issues. A server to server protocol will 187 have to address these issues. Some initial work to address these 188 issues can be found in: 189 [I-D.houri-simple-interdomain-scaling-optimizations], 190 [I-D.ietf-simple-view-sharing] and 191 [I-D.ietf-simple-intradomain-federation] 193 Another issue that is more concerning protocol design is whether 194 NOTIFY messages should not be considered as media just like audio, 195 video and even text messaging. The SUBSCRIBE method may be extended 196 to negotiate the route and other parameters of the NOTIFY messages, 197 in a similar way that the INVITE method is negotiating media 198 parameters. This way the load can be offloaded to a specialized 199 NOTIFY "relays" thus not loading the control path of SIP. One of the 200 possible ideas (Marc Willekens) is to use the SIP protocol for 201 client/server NOTIFY but make use of a more optimized and 202 controllable protocol for the server-to-server interface. Another 203 possibility is to use the MSRP [RFC4975], [RFC4976]protocol for the 204 notifies. 206 5. Security Considerations 208 This document discusses scalability requirements for the existing 209 SIP/SIMPLE presence protocol and model. Many of the changes to the 210 protocol will have security implications as mentioned in some of the 211 requirements above. 213 One example of possible protocol changes that may have security 214 implications is sending a presence document only once between domains 215 in order to optimize the number of messages and network load. This 216 possible optimization will delegate privacy protection from one 217 domain to another domain and should be addressed when designing 218 protocol optimizations 220 Important part of work on the requirements and optimizations will be 221 to make sure that all the security aspects are covered. 223 6. IANA Considerations 225 None. 227 7. Acknowledgments 229 We would like to thank Jonathan Rosenberg, Ben Campbell, Markus 230 Isomaki Piotr Boni, David Viamonte, Aki Niemi, Marc Willekens Gonzalo 231 Camarillo for their ideas and input. Special thanks to Vijay K. 232 Gurbani for the a detailed review. 234 8. References 236 8.1. Normative References 238 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 239 Requirement Levels", BCP 14, RFC 2119, March 1997. 241 8.2. Informational References 243 [I-D.houri-simple-interdomain-scaling-optimizations] 244 Houri, A., "Scaling Optimizations for Presence in SIP/ 245 SIMPLE", 246 (work in progress), July 2007. 248 [I-D.ietf-simple-interdomain-scaling-analysis] 249 Houri, A., Aoki, E., Parameswar, S., Rang, T., Singh, V., 250 and H. Schulzrinne, "Presence Interdomain Scaling Analysis 251 for SIP/SIMPLE", 252 draft-ietf-simple-interdomain-scaling-analysis-04 (work in 253 progress), February 2008. 255 [I-D.ietf-simple-intradomain-federation] 256 Rosenberg, J. and A. Houri, "Models for Intra-Domain 257 Presence Federation", 258 draft-ietf-simple-intradomain-federation-00 (work in 259 progress), February 2008. 261 [I-D.ietf-simple-view-sharing] 262 Rosenberg, J., Donovan, S., and K. McMurry, "Optimizing 263 Federated Presence with View Sharing", 264 draft-ietf-simple-view-sharing-00 (work in progress), 265 February 2008. 267 [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session 268 Initiation Protocol (SIP) Event Notification Extension for 269 Resource Lists", RFC 4662, August 2006. 271 [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message 272 Session Relay Protocol (MSRP)", RFC 4975, September 2007. 274 [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions 275 for the Message Sessions Relay Protocol (MSRP)", RFC 4976, 276 September 2007. 278 Authors' Addresses 280 Avshalom Houri 281 IBM 282 3 Pekris Street, Science Park 283 Rehovot, 284 Israel 286 Email: avshalom@il.ibm.com 287 Sriram Parameswar 288 Microsoft Corporation 289 One Microsoft Way 290 Redmond, WA 98052 291 USA 293 Email: Sriram.Parameswar@microsoft.com 295 Edwin Aoki 296 AOL LLC 297 360 W. Caribbean Drive 298 Sunnyvale, CA 94089 299 USA 301 Email: aoki@aol.net 303 Vishal Singh 304 Columbia University 305 Department of Computer Science 306 450 Computer Science Building 307 New York, NY 10027 308 US 310 Email: vs2140@cs.columbia.edu 311 URI: http://www.cs.columbia.edu/~vs2140 313 Henning Schulzrinne 314 Columbia University 315 Department of Computer Science 316 450 Computer Science Building 317 New York, NY 10027 318 US 320 Phone: +1 212 939 7004 321 Email: hgs+ecrit@cs.columbia.edu 322 URI: http://www.cs.columbia.edu/~hgs 324 Full Copyright Statement 326 Copyright (C) The IETF Trust (2008). 328 This document is subject to the rights, licenses and restrictions 329 contained in BCP 78, and except as set forth therein, the authors 330 retain all their rights. 332 This document and the information contained herein are provided on an 333 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 334 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 335 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 336 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 337 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 338 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 340 Intellectual Property 342 The IETF takes no position regarding the validity or scope of any 343 Intellectual Property Rights or other rights that might be claimed to 344 pertain to the implementation or use of the technology described in 345 this document or the extent to which any license under such rights 346 might or might not be available; nor does it represent that it has 347 made any independent effort to identify any such rights. Information 348 on the procedures with respect to rights in RFC documents can be 349 found in BCP 78 and BCP 79. 351 Copies of IPR disclosures made to the IETF Secretariat and any 352 assurances of licenses to be made available, or the result of an 353 attempt made to obtain a general license or permission for the use of 354 such proprietary rights by implementers or users of this 355 specification can be obtained from the IETF on-line IPR repository at 356 http://www.ietf.org/ipr. 358 The IETF invites any interested party to bring to its attention any 359 copyrights, patents or patent applications, or other proprietary 360 rights that may cover technology that may be required to implement 361 this standard. Please address the information to the IETF at 362 ietf-ipr@ietf.org.