idnits 2.17.1 draft-ietf-sipping-presence-scaling-requirements-00.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 305. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 316. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 323. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 329. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (February 9, 2008) is 5920 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-03 Summary: 2 errors (**), 0 flaws (~~), 2 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: August 12, 2008 Microsoft Corporation 6 E. Aoki 7 AOL LLC 8 V. Singh 9 H. Schulzrinne 10 Columbia U. 11 February 9, 2008 13 Scaling Requirements for Presence in SIP/SIMPLE 14 draft-ietf-sipping-presence-scaling-requirements-00.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 August 12, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2008). 45 Abstract 47 The document provides a set of requirements for enabling interdomain 48 scaling in presence for SIP/SIMPLE. The requirements are based on a 49 separate scaling analysis document. 51 Table of Contents 53 1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Suggested Requirements . . . . . . . . . . . . . . . . . . . . 3 56 3.1. Backward Compatibility Requirements . . . . . . . . . . . . 3 57 3.2. Policy, Privacy, Permissions Requirements . . . . . . . . . 3 58 3.3. Scalability Requirements . . . . . . . . . . . . . . . . . 3 59 3.4. Topology Requirements . . . . . . . . . . . . . . . . . . . 4 60 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 62 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 65 7.2. Informational References . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 67 Intellectual Property and Copyright Statements . . . . . . . . . . 8 69 1. Requirements notation 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in [1]. 75 2. Introduction 77 The document lists requirements for optimizations of the SIP/SIMPLE 78 protocol. These optimizations should reduce the traffic in 79 interdomain presence subscriptions. The requirements are based on a 80 separate scaling analysis document [4]. 82 3. Suggested Requirements 84 In the presence scaling draft [4], several areas where the deployment 85 of a presence system is far from being trivial are described, these 86 include network load, memory load and CPU load. In this section 87 lists an initial set of requirements for a solution that will 88 optimize the interdomain presence traffic. 90 3.1. Backward Compatibility Requirements 92 o REQ-001: The solution should not hinder the ability of existing 93 SIMPLE clients and/or servers from peering with a domain or client 94 implementing the solution. No changes may be required of existing 95 servers to interoperate. 96 o REQ-002: It does NOT constrain any existing RFC functional or 97 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 does not limit the ability for presentities 104 to present different views of presence to different watchers. 105 o REQ-005: The solution does not restrict the ability of a 106 presentity to obtain its list of watchers. 107 o REQ-006: The solution MUST NOT create any new or make worse any 108 existing privacy holes. 110 3.3. Scalability Requirements 112 o REQ-007: It is highly desirable for any presence system (intra or 113 inter-domain) to scale linearly as number of watchers and 114 presentities increase linearly. 116 o REQ-008: The solution SHOULD NOT require significantly more state 117 in order to implement the solution. 118 o REQ-009: It MUST be able to scale to tens of millions of 119 concurrent users in each domain and in each peer domain. 120 o REQ-010: It MUST support a very high level of watcher/presentity 121 intersections in various intersection models. 122 o REQ-011: Protocol changes MUST NOT prohibit optimizations in 123 different deployment models esp. where there is a high level of 124 cross subscriptions between the domains. 125 o REQ-012: New functionalities and extensions to the presence 126 protocol SHOULD take into account scalability with respect to the 127 number of messages, state size and management and processing load. 129 3.4. Topology Requirements 131 o REQ-013: The solution SHOULD allow for arbitrary federation 132 topologies including direct peering and intermediary routing. 134 4. Conclusions 136 The document provides an initial list of requirements for a solution 137 of scalability of interdomain presence systems using the SIP/SIMPLE 138 protocol. The issue of scalability was shown in a separate document 139 [4]. 141 It is very possible that the issues that are described in this 142 document are inherent to presence systems in general and not specific 143 to the SIMPLE protocol. Organizations need to be prepared to invest 144 a lot in network and hardware in order to create real big systems. 145 However, it is apparent that not all the possible optimizations were 146 done yet and further work is needed in the IETF in order to provide 147 better scalability 149 Nevertheless, we should remember that SIP was originally designed for 150 end to end session creation and number and size of messages are of 151 secondary importance for end to end session negotiation. For large 152 scale and especially for very large scale presence the number of 153 messages that are needed and the size of each message are of extreme 154 importance. It seems that we need to think about the problem in a 155 different way. We need to think about scalability as part of the 156 protocol design. The IETF tends not to think about actual 157 deployments when designing a protocol but in this case it seems that 158 if we do not think about scalability with the protocol design it will 159 be very hard to scale. 161 We should also consider whether using the same protocol between 162 clients and servers and between servers is a good choice. It may be 163 that in interdomain or even between servers in the same domain (as 164 between RLSs and presence servers) there is a need to have a 165 different protocol that will be very optimized for the load and can 166 assume some assumptions about the network (e.g. do not use unreliable 167 protocol as UDP but only TCP). 169 When servers is connecting to another server using current protocol, 170 there will be an extreme number of redundant messages due to the 171 overhead of supporting UDP and to the need to send multiple presence 172 documents for the same watched user due to privacy issue. A server 173 to server protocol will have to address these issues. Some initial 174 work to address these issues can be found in: [5], [6] and [7] 176 Another issue that is more concerning protocol design is whether 177 NOTIFY messages should not be considered as media as audio, video and 178 even text messaging. The SUBSCRIBE can be extended to do similar 179 three way handshake as INVITE and negotiate where the notify messages 180 should go, rate and other parameters. This way the load can be 181 offloaded to a specialized NOTIFY "relays" thus not loading the 182 control path of SIP. One of the possible ideas (Marc Willekens) is 183 to use the SIP stack for the client/server NOTIFY but make use of a 184 more optimized and controllable protocol for the server-to-server 185 interface. Another possibility is to use the MSRP [2], [3]protocol 186 for the notifies. 188 5. Security Considerations 190 This document discusses scalability requirements for the existing 191 SIP/SIMPLE presence protocol and model. Many of the changes to the 192 protocol will have security implications as mentioned in some of the 193 requirements above. 195 One example of possible protocol changes that may have security 196 implications is sending a presence document only once between domains 197 in order to optimize the number of messages and network load. This 198 possible optimization will delagate privacy protection from one 199 domain to another domain and should be addressed when designing 200 protocol optimizations 202 Important part of work on the requirements and optimizations will be 203 to make sure that all the security aspects are covered. 205 6. Acknowledgments 207 We would like to thank Jonathan Rosenberg, Ben Campbell, Markus 208 Isomaki Piotr Boni, David Viamonte, Aki Niemi and Marc Willekens for 209 their ideas and input. 211 7. References 213 7.1. Normative References 215 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 216 Levels", BCP 14, RFC 2119, March 1997. 218 7.2. Informational References 220 [2] Campbell, B., Mahy, R., and C. Jennings, "The Message Session 221 Relay Protocol (MSRP)", RFC 4975, September 2007. 223 [3] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the 224 Message Sessions Relay Protocol (MSRP)", RFC 4976, 225 September 2007. 227 [4] Houri, A., Aoki, E., Parameswar, S., Rang, T., Singh, V., and H. 228 Schulzrinne, "Presence Interdomain Scaling Analysis for SIP/ 229 SIMPLE", draft-ietf-simple-interdomain-scaling-analysis-03 (work 230 in progress), November 2007. 232 [5] Houri, A., "Scaling Optimizations for Presence in SIP/SIMPLE", 233 draft-houri-simple-interdomain-scaling-optimizations-00 (work in 234 progress), July 2007. 236 [6] Rosenberg, J., Donovan, S., and K. McMurry, "Optimizing 237 Federated Presence with View Sharing", 238 draft-rosenberg-simple-view-sharing-00 (work in progress), 239 November 2007. 241 [7] Rosenberg, J., "Models for Intra-Domain Presence Federation", 242 draft-rosenberg-simple-intradomain-federation-00 (work in 243 progress), November 2007. 245 Authors' Addresses 247 Avshalom Houri 248 IBM 249 Science Park Building 18/D 250 Rehovot, 251 Israel 253 Email: avshalom@il.ibm.com 254 Sriram Parameswar 255 Microsoft Corporation 256 One Microsoft Way 257 Redmond, WA 98052 258 USA 260 Email: Sriram.Parameswar@microsoft.com 262 Edwin Aoki 263 AOL LLC 264 360 W. Caribbean Drive 265 Sunnyvale, CA 94089 266 USA 268 Email: aoki@aol.net 270 Vishal Singh 271 Columbia University 272 Department of Computer Science 273 450 Computer Science Building 274 New York, NY 10027 275 US 277 Email: vs2140@cs.columbia.edu 278 URI: http://www.cs.columbia.edu/~vs2140 280 Henning Schulzrinne 281 Columbia University 282 Department of Computer Science 283 450 Computer Science Building 284 New York, NY 10027 285 US 287 Phone: +1 212 939 7004 288 Email: hgs+ecrit@cs.columbia.edu 289 URI: http://www.cs.columbia.edu/~hgs 291 Full Copyright Statement 293 Copyright (C) The IETF Trust (2008). 295 This document is subject to the rights, licenses and restrictions 296 contained in BCP 78, and except as set forth therein, the authors 297 retain all their rights. 299 This document and the information contained herein are provided on an 300 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 301 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 302 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 303 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 304 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 305 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 307 Intellectual Property 309 The IETF takes no position regarding the validity or scope of any 310 Intellectual Property Rights or other rights that might be claimed to 311 pertain to the implementation or use of the technology described in 312 this document or the extent to which any license under such rights 313 might or might not be available; nor does it represent that it has 314 made any independent effort to identify any such rights. Information 315 on the procedures with respect to rights in RFC documents can be 316 found in BCP 78 and BCP 79. 318 Copies of IPR disclosures made to the IETF Secretariat and any 319 assurances of licenses to be made available, or the result of an 320 attempt made to obtain a general license or permission for the use of 321 such proprietary rights by implementers or users of this 322 specification can be obtained from the IETF on-line IPR repository at 323 http://www.ietf.org/ipr. 325 The IETF invites any interested party to bring to its attention any 326 copyrights, patents or patent applications, or other proprietary 327 rights that may cover technology that may be required to implement 328 this standard. Please address the information to the IETF at 329 ietf-ipr@ietf.org. 331 Acknowledgment 333 Funding for the RFC Editor function is provided by the IETF 334 Administrative Support Activity (IASA).