idnits 2.17.1 draft-ietf-simple-interdomain-scaling-analysis-07.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 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 8, 2009) is 5405 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-ietf-sipcore-presence-scaling-requirements-00 == Outdated reference: A later version (-04) exists of draft-ietf-sipcore-subnot-etags-02 == Outdated reference: A later version (-09) exists of draft-ietf-sipcore-event-rate-control-00 == Outdated reference: A later version (-05) exists of draft-ietf-simple-intradomain-federation-03 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE WG A. Houri 3 Internet-Draft IBM 4 Intended status: Informational E. Aoki 5 Expires: January 9, 2010 AOL LLC 6 S. Parameswar 7 T. Rang 8 Microsoft Corporation 9 V. Singh 10 H. Schulzrinne 11 Columbia U. 12 July 8, 2009 14 Presence Interdomain Scaling Analysis for SIP/SIMPLE 15 draft-ietf-simple-interdomain-scaling-analysis-07.txt 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 9, 2010. 40 Copyright Notice 42 Copyright (c) 2009 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents in effect on the date of 47 publication of this document (http://trustee.ietf.org/license-info). 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. 51 Abstract 53 The document analyzes the traffic that is generated by presence 54 subscriptions between domains and shows that the amount of traffic 55 can be extremely large. The document also analyzes the effects of a 56 large presence system on the memory footprint and the CPU load. 57 Approved and in-work optimizations to the Session Initiation Protocol 58 are analyzed with the possible impact on the load. Separate 59 documents contain the requirements for optimizations and suggestions 60 for new optimizations. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Message Load . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.1. Message Load Optimizations Considered . . . . . . . . . . 5 67 2.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.3. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 2.3.1. Constants . . . . . . . . . . . . . . . . . . . . . . 8 70 2.3.2. Initial Messages . . . . . . . . . . . . . . . . . . . 10 71 2.3.3. Steady State Messages . . . . . . . . . . . . . . . . 10 72 2.3.4. Termination Messages . . . . . . . . . . . . . . . . . 11 73 2.3.5. Bottom Line . . . . . . . . . . . . . . . . . . . . . 12 74 2.3.6. Rush Hour Calculations . . . . . . . . . . . . . . . . 12 75 2.4. No optimizations used . . . . . . . . . . . . . . . . . . 13 76 2.5. Dialog optimization used . . . . . . . . . . . . . . . . . 15 77 2.6. NOTIFY optimization used . . . . . . . . . . . . . . . . . 17 78 2.7. Dialog and NOTIFY optimizations used . . . . . . . . . . . 19 79 2.8. Presence Federation Scenarios . . . . . . . . . . . . . . 21 80 2.8.1. Widely distributed inter-domain presence . . . . . . . 21 81 2.8.2. Associated inter-domain presence . . . . . . . . . . . 26 82 2.8.3. Large network peering . . . . . . . . . . . . . . . . 26 83 2.8.4. Intra-domain peering . . . . . . . . . . . . . . . . . 31 84 2.9. Partial Notifications Optimization . . . . . . . . . . . . 35 85 2.10. Extremely Optimized SIP . . . . . . . . . . . . . . . . . 37 86 3. State Management . . . . . . . . . . . . . . . . . . . . . . . 42 87 3.1. State Size Calculations . . . . . . . . . . . . . . . . . 43 88 3.1.1. Tiny System . . . . . . . . . . . . . . . . . . . . . 43 89 3.1.2. Medium System . . . . . . . . . . . . . . . . . . . . 43 90 3.1.3. Large System . . . . . . . . . . . . . . . . . . . . . 44 91 3.1.4. Larger System . . . . . . . . . . . . . . . . . . . . 44 92 4. Processing complexities . . . . . . . . . . . . . . . . . . . 45 93 4.1. Aggregation . . . . . . . . . . . . . . . . . . . . . . . 45 94 4.2. Partial Publish and Notify . . . . . . . . . . . . . . . . 45 95 4.3. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 46 96 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 46 97 4.5. Resource List Service . . . . . . . . . . . . . . . . . . 46 98 5. Current Optimizations . . . . . . . . . . . . . . . . . . . . 47 99 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 100 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 54 101 8. Security Considerations . . . . . . . . . . . . . . . . . . . 55 102 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 103 10. Changes from Previous Versions . . . . . . . . . . . . . . . . 56 104 10.1. Changes in version 07 . . . . . . . . . . . . . . . . . . 56 105 10.2. Changes in version 06 . . . . . . . . . . . . . . . . . . 56 106 10.3. Changes in version 05 . . . . . . . . . . . . . . . . . . 56 107 10.4. Changes in version 04 . . . . . . . . . . . . . . . . . . 56 108 10.5. Changes in version 03 . . . . . . . . . . . . . . . . . . 57 109 10.6. Changes in version 02 . . . . . . . . . . . . . . . . . . 57 110 10.7. Changes in version 01 . . . . . . . . . . . . . . . . . . 57 111 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 57 112 12. Informational References . . . . . . . . . . . . . . . . . . . 58 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59 115 1. Introduction 117 The document analyzes the traffic that is generated by Session 118 Initiation Protocol (SIP) for presence (as defined by the SIMPLE 119 working group) due to presence subscriptions between domains. It 120 shows that the number of messages and the amount of data generated 121 can be extremely large. This document also analyzes the effects of a 122 large presence system on the memory footprint and the CPU load. 123 Approved and in-work optimizations to SIP are analyzed with the 124 possible impact on the load. Another document provides requirements 125 for optimizations [1] while other documents contain suggestions for 126 new optimizations: [2] and [3] 128 This document is intended to drive work on possible solutions that 129 will make the deployment of a SIP-based presence server a less 130 challenging task. Deployment of highly scalable presence systems is 131 challenging by its nature, and protocol developers design their own 132 techniques for optimizing their protocols. Comparing protocols is 133 beyond the scope of this document. 135 The document discusses the following areas, showing the complexity 136 and load that the presence server handles in order to provide its 137 service: 139 o Message load - By computing the number of messages that are 140 required for connecting presence systems, the document shows that 141 the number of messages and the required bandwidth are large, and 142 that it is quite obvious that optimizations are needed. 143 o State management - Due to the nature of the service that the 144 presence server provides, the presence server has to manage a 145 relatively large and complex state, and some computations are 146 provided in the document. 147 o Processing complexities - The presence server maintains many small 148 objects and performs frequent operations on these objects. We 149 show that these operations and the optimizations that are intended 150 to reduce the amount of data sent between watchers and presence 151 servers are not so simple and may create a heavy processing load 152 on the presence server. 153 o Groups - Resource List Servers [4] optimize the number of sessions 154 that are created between the watchers and the presence server. 155 However, this optimization may create an exponential size of 156 subscriptions due to the minimal effort of subscribing to large 157 groups. 159 The terms presence domain or presence system appear in this document 160 frequently. These terms refer to SIP-based presence servers that 161 provide presence subscription and notification services to their 162 users. A presence system can be deployed in a small enterprise or in 163 a large consumer network. 165 2. Message Load 167 Some optimizations are approved or are being defined for the SIP 168 presence protocol, but even with these optimizations, a large number 169 of messages and wide bandwidth are needed in order to establish 170 federation between presence systems of large communities. Further 171 thinking is needed in order to make large deployment of presence 172 systems less resource demanding. 174 Note that even though this document talks about inter-domain traffic, 175 the introduction of resource list servers (RLSs) [4] introduce 176 similar traffic patterns intra-domain and inter-domain. See detailed 177 discussion on resource lists in Section 4.5. 179 2.1. Message Load Optimizations Considered 181 The current optimizations that are approved or are approved as 182 working group items in the SIMPLE working group can be divided into 183 two categories: 185 o Dialogs saving optimization - Here we refer to optimizations such 186 as the resource list RFC [4] or to the URI list subscriptions RFC 187 [5]. These documents define ways to reduce the number of dialogs 188 that are required between the subscriber and the presence system. 190 Note that the terms dialog optimization or RLS usage as used in 191 this document refer to the usage of a URI that represents a 192 list of URI lists between domains and not within the same 193 domain. An example is a user Alice in domain example.org who 194 subscribes to the URI external-reps-list at example.com or uses 195 a URI list to subscribe to her watch list in example.com. Note 196 also that, when calculating the traffic due to the RLS within a 197 domain, the traffic between the RLS and the presence agents 198 should also be considered. However, since we are mostly 199 concerned with inter- domain traffic, we are not taking into 200 account the traffic between the RLS and the presence agents. 201 o 202 Notification optimizations - Here we refer to the optimizations 203 covered in the subnot-etags draft [6], which describes the 204 suppression of unnecessary NOTIFYs when subscriptions are 205 refreshed. There are other drafts that reduce the size of 206 messages by using partial notifications or filtering. This 207 document shows that partial optimizations can reduce the bandwidth 208 but do not reduce the number of messages. 210 One optimation that was not considered is the reception of presence 211 information outside of SIP. An example of this is the ability to 212 download persistent presence information directly from a web site. 213 The calculations assume that all presence data is carried within SIP 214 and not by other means. These out-of-band optimizations may improve 215 the number of messages and number of bytes significantly, but they 216 are out of scope for this document. 218 2.2. Assumptions 220 In this document, several assumptions are used regarding size of 221 messages, rate of presence change and more. It should be noted that 222 these assumptions are not directly based on rigorous statistics from 223 actual SIP-based deployments of presence systems but more from some 224 experience on other types of presence-based systems. 226 The following numbers are given more as examples from real 227 deployments and they are not intended to be complete. 229 In a large consumer network, we have seen the following patterns: 231 o There are approximately 110 users on a watch list on average. 232 o There are approximately 12 billion status changes a day (139k/ 233 second) across the network. When a proprietary binary protocol 234 conveys the status changes, the average message size is about 188 235 bytes. When a SIP NOTIFY is used, the average is about 1228 236 bytes. 237 o The average number of logins/logouts in the system is about 2000 238 logins per second and about 4000 logouts per second. When a 239 promotion, contest, or a network hiccup causes many users to login 240 and logout simultaneously, there are about 20,000 logins per 241 second. 242 o The peak of the instant messages sent is about 50,000 messages per 243 second. 245 In an enterprise deployment, we have seen the following patterns: 247 o Average watch list size was 200 users. 248 o About half of the registered users were online at peak time. 249 o Status change per hour was 2 changes per hour. 250 o The average logins/logouts in the system was about 5 logins per 251 second with additional 15 logins/logouts during start/end of day 252 rush hours. 254 Even though the assumptions in this document are not based on 255 rigorous statistical data, the target here is not to analyze a 256 specific system but to show that even with VERY moderate assumptions 257 (which are even less than the observations mentioned above), the 258 number of messages, the network bandwidth, the required state 259 management, and the CPU load are high. Real-life systems could have 260 much larger scalability challenges. For example, the presence state 261 change that we assumed (one presence state change per hour) is maybe 262 one of the most moderate assumptions that we have taken. Experience 263 from consumer networks shows that the frequency can be much higher, 264 especially with the younger generation using more presence attributes 265 like mood, etc. In an environment where a user may have several 266 devices and other resources for presence information such as 267 geographical location and calendar, the frequency of presence state 268 changes will be much higher. 270 It is hard to measure presence load since it depends heavily on the 271 behavior of users, and the behavior of users differs widely. Some 272 users will have a small number of presentities in their watch list, 273 while others may have hundreds, if not thousands. Some users will 274 change their state frequently and have many sources of presence 275 information, while others may have small number of changes during the 276 day. In addition, the "rush hour" calculations of when the day 277 starts and ends were not included in this document. Rush hour 278 differs between different enterprises and is still different in the 279 consumer presence systems. It is hard if not impossible to take into 280 a static document all the possible combinations. 282 Throughout the calculations, a certain number of users are assumed 283 for the different models. It does not mean that in actual 284 deployments all the users of the domain are actually subscribed to 285 presence documents and/or have published their presence documents. 286 Observing actual deployments shows that, in the consumer market, the 287 number of users that use presence services may be 10 percent or less 288 of the registered users. In the enterprise market, the numbers tend 289 to be around 50 percent of the actual enterprise registered users. 291 The same is correct for the number of watched presentities per 292 watcher. If only some percentage of the domain users are online at a 293 given time, then this number should match that percentage. However, 294 adding this assumption to the calculations will make the calculations 295 more complex since the effect of the watched offline presentities 296 would need to be considered. This means that empty NOTIFYs would be 297 sent for offline presentities when the subscription is created and 298 there are no updates on them. In order to make the computations less 299 complex (they are complex enough as they are), the number of the 300 watched presentities used in the calculations is the number of the 301 federated presentities from the watcher list that are online. 303 2.3. Analysis 305 The basic SIP subscription dialog involves the following message- 306 transfer: 308 o SUBSCRIBE/200 309 o Initial NOTIFY/200 310 o (j) NOTIFY/200 where "j" is the number of presence changes seen by 311 the watcher 312 o (k) SUBSCRIBE/200 where "k" is the number of subscription dialog 313 refresh periods 314 o SUBSCRIBE/200 with Expires = 0 to terminate the dialog 315 o NOTIFY/200 ending the dialog 317 An individual watcher will generate X number of SIP subscription 318 dialogs corresponding to the number of presentities it chooses to 319 watch. The amount of traffic generated is significantly affected by 320 several factors: 322 o Number of watchers connected to the system 323 o Number of presentities connected to the system 324 o Frequency of changes to presence information 326 This document contains several calculations that show the expected 327 message rate and bandwidth between presence domains. The following 328 sections explain the assumptions and methods behind the calculations. 330 2.3.1. Constants 332 The following are the "constants" that we use in the calculations. 333 Some of the constants are used throughout the calculations while 334 other change between use cases. 336 o (C01) Subscription lifetime (hours) - The assumed lifetime of a 337 subscription in hours. We assume 8 hours for all calculations. 338 Note that the term "day" that is used in the document and C01 are 339 synonymous. 340 o (C02) Presence state changes / hour - The average time that a 341 presentity changes his/her status in one hour. We assumed 3 times 342 per hour for most calculations. Note that for some users in 343 consumer messaging systems, the actual number of changes is likely 344 to be much higher. 345 o (C03) Subscription refresh interval / hour - The duration of the 346 SUBSCRIBE session after which it needs to be refreshed. We 347 assumed that the duration is one hour. 348 o (C04) Total federated presentities per watcher - The number of 349 presentities that the watcher is watching. The number here 350 changes in this document according to the type of the specific 351 deployment. 352 o (C05) Number of dialogs to maintain per watcher - The number of 353 the SUBSCRIBE dialogs that are maintained per watcher. If a 354 dialog optimization is not assumed, this number is equal to C04, 355 otherwise it is 1. 356 o (C06) Total number of watchers in the federated presence domains. 357 The number here is the number of all watchers in all the federated 358 domains. 359 o (C07) SUBSCRIBE message size in bytes. We assume 450 bytes in all 360 calculations. The size is based on a typical SUBSCRIBE taken from 361 RFCs. 362 o (C08) 200 OK for SUBSCRIBE message size in bytes. We assume 370 363 bytes in all calculations. The size is based on a typical 200 OK 364 taken from RFCs. 365 o (C09) NOTIFY message size not including the presence document. 366 The size of this message for a single presentity is assumed to be 367 500 bytes for the NOTIFY message itself (based on sizes from 368 examples in RFCs). 369 o (C10) 200 OK for NOTIFY message size in bytes. We assume 370 370 bytes in all calculations. The size is based on a typical 200 OK 371 taken from RFCs. 372 o (C11) Size of an average presence document. Two sizes of average 373 presence doucment are used. One is the minimal size of the PIDF 374 [7] document, assumed to be 350 bytes based on examples from RFCs, 375 and the other is 3000 bytes for a rich presence document [8]. It 376 should be noted that 3000 bytes for a presence document is 377 relatively modest if we take into account multiple devices and 378 location information. 379 o (C12) The size of a NOTIFY when partial notification [9] is used. 380 We have taken this size to be 200 bytes, much smaller than the 381 example given in [9], which assumes multiple changes in the 382 presence document. Here we assume a single change. 384 When dialog optimization [4] is used, an RLMI document, which 385 contains the presence documents for the users on the watch 386 list, is sent. In a previous version of this document, we had 387 omitted the overhead of the RLMI document. This "bug" was 388 found by Victoria Beltran-Martinez and is fixed in this version 389 by adding the following constants C13, C14 and C15 to the 390 calculations: 391 o 392 (C13) Item size per each contact in RLMI document, 160 bytes. 393 o (C14) The size of the multipart boundary in RLMI notifications, 394 144 bytes. 395 o (C15) The size of the XML root node in RLMI document (once per 396 notification), 144 bytes. 398 2.3.2. Initial Messages 400 The following are the calculations for the messages in the initial 401 phase of the establishment of the subscriptions. The calculations 402 contain both the number of messages and the number of bytes. 404 o (I01) Number of initial SUBSCRIBE messages per watcher = C05. 405 o (I02) Number of initial 200 OK messages for SUBSCRIBE messages per 406 watcher = C05. 407 o (I03) Number of initial NOTIFY messages per watcher = C05. 408 o (I04) Number of initial 200 OK messages for NOTIFY messages per 409 watcher = C05. 410 o (I05) Total number and bytes of initial SUBSCRIBE messages for all 411 watchers = Number: I01*C06, Bytes: I01*C06*C07. 412 o (I06) Total number and bytes of initial 200 OK for SUBSCRIBE 413 messages for all watchers = Number: I01*C06, Bytes: I01*C06*C08. 414 o (I07) Total number and bytes of initial NOTIFY messages for all 415 watchers = Number: I01*C06. The calculation for the number of 416 bytes is different depending on the use of dialog optimization. 417 When dialog optimization is not applied, the number of bytes is 418 calculated by (I01*C06*C09)+(I01*C06*C11). When dialog 419 optimization is applied, the number of bytes is calculated by 420 (I01*C06*(C09+C14+C15))+(I01*C06*C04*(C11+C13+C14)). 421 o (I08) Total number and bytes of initial 200 OK for NOTIFY messages 422 for all watchers = Number: I04*C06, Bytes: I04*C06*C10. 423 o (I09) Total number and bytes of initial messages per day = Number: 424 numbers in I05+I06+I07+I08, Size: sizes in I05+I06+I07+I08. 426 2.3.3. Steady State Messages 428 Here we describe the calculations for steady state messages. Steady 429 state is the time between the initial subscription and the teardown 430 of the subscription. It contains the NOTIFYs due to state change and 431 the subscription refreshes. 433 o (S01) NOTIFY messages due to state change per watched presentity 434 per day (less 2 since the NOTIFY for initial and terminating state 435 is calculated in the initial and terminating calculations) = 436 (C02*C01-2). 437 o (S02) 200 messages (for NOTIFYs due to state change) per watched 438 presentity per day (less 2 since the NOTIFY for initial and 439 terminating state is calculated in the initial and terminating 440 calculations) = (C02*C01-2). 441 o (S03) Total number and size of messages due to state change per 442 day = Number: (S01+S02)*C06*C04. The calculation for the number 443 of bytes depends on the use of dialog optimization. When dialog 444 optimization is not applied, the number of bytes is calculated by 445 (C06*C04)*((S01*(C09+C11))+(S02*C10)) and when dialog optimization 446 is applied, the number of bytes is calculated by 447 (C06*C04)*((S01*(C09+C11+C13+C14+C15+C14))+(S02*C10)). This 448 includes the multipart boundary of the resource list. Note that, 449 for dialog optimization, it is assumed that only a single 450 presentity is changed and partial state notification is used. 451 o (S04) Number of SUBSCRIBE messages for refreshes per watcher per 452 day = ((C01/C03)-1)*C05. One is subtracted since the termination 453 is calculated separately. For example, if there are 8 hours in 454 the day and a refresh should occur every hour, there are 7 455 refreshes during the day and not 8. 456 o (S05) Number of 200 OK messages for SUBSCRIBE messages for 457 refreshes per watcher per day = ((C01/C03)-1)*C05. 458 o (S06) Number of NOTIFY messages for refreshes per watcher per day 459 = ((C01/C03)-1)*C05. If NOTIFY optimization is used [6], there is 460 no need to send NOTIFYs for refreshes, and S06 will be zero. 461 o (S07) Number of 200 OK messages for NOTIFY messages for refreshes 462 per watcher per day = ((C01/C03)-1)*C05. If NOTIFY optimization 463 is used [6], there is no need to send NOTIFYs for refreshes, and 464 S07 will be zero. 465 o (S08) Total number and size of messages due to SUBSCRIBE refreshes 466 per day = Number: (S04+S05+S06+S07)*C06. The number of bytes is 467 calculated by adding the SUBSCRIBE bytes (S04*C06*C07), the OK 468 bytes for the SUBSCRIBE (S05*C06*C08), the NOTIFY bytes 469 C06*(S06*(C09+C11)) and the OK bytes for the NOTIFY (S07*C06*C10). 470 Note that the formula for the NOTIFY bytes assumes that dialog 471 optimization is not used. When dialog optimization is used, the 472 formula is: C06*(S06*((C09+C14+C15)+(C04*(C11+C13+C14)))). Note 473 that a full state should be given in SUBSCRIBE refreshes in 474 resource lists. See section 5.2 in [4]. The fact that the full 475 state needs to be returned in a NOTIFY response to refresh makes 476 the NOTIFY optimization more efficient in conjunction with the 477 dialog optimization. 478 o (S09) Total number and bytes of steady messages per day = Number: 479 numbers in S03+S08, Bytes: sizes in S03+S08. 481 2.3.4. Termination Messages 483 The following are the calculations for the messages in the 484 termination phase of the subscriptions. The calculations contain 485 both the number of messages and the number of bytes. 487 o (T01) Number of terminating SUBSCRIBE messages per watcher = C05. 488 o (T02) Number of terminating 200 OK messages for SUBSCRIBE messages 489 per watcher = C05. 490 o (T03) Number of terminating NOTIFY messages per watcher = C05. If 491 NOTIFY optimization is used [6], there is no need to send a NOTIFY 492 for terminations, and T03 will be zero. 494 o (T04) Number of terminating 200 OK messages for NOTIFY messages 495 per watcher = C05. If NOTIFY optimization is used [6], there is 496 no need to send a NOTIFY for terminations, and T04 will be zero. 497 o (T05) Total number and bytes of terminating SUBSCRIBE messages for 498 all watchers = Number: T01*C06, Bytes: T01*C06*C07. 499 o (T06) Total number and bytes of terminating 200 OK for SUBSCRIBE 500 messages for all watchers = Number: T01*C06, Bytes: T01*C06*C08. 501 o (T07) Total number and bytes of terminating NOTIFY messages for 502 all watchers = Number: T01*C06. The number of bytes is calculated 503 to be (T03*C06*(C09+C11) when dialog optimization is not used, and 504 (T03*C06*(C09+C14+C15))+(T03*C06*C04*(C11+C13+C14)) when dialog 505 optimization is used. Note that a full state should be given in 506 SUBSCRIBE refreshes in resource lists. See section 5.2 in [4]. 507 o (T08) Total number and bytes of terminating 200 OK for NOTIFY 508 messages for all watchers = Number: T04*C06, Bytes: T04*C06*C10. 509 o (T09) Total number and bytes of terminating messages per day = 510 Number: numbers in T05+T06+T07+T08, Size: sizes in T05+T06+T07+ 511 T08. 513 2.3.5. Bottom Line 515 The following are the calculations of several totals that are based 516 on the above calculations. 518 o (B01) Total number of messages and bytes during the day = 519 Messages: number of messages in I09+S09+T09, Bytes: number of 520 bytes in I09+S09+T09. 521 o (B02) Total number of messages and bytes per second = Messages: 522 number of messages in B01/(C01*3600), Bytes: number of bytes in 523 B01/(C01*3600). 524 o (B03) Total number of message and bytes per user per day = 525 Messages: number of messages in B01/C06, Bytes: number of bytes in 526 B01/C06. 528 2.3.6. Rush Hour Calculations 530 With the way that the calculations are built, it is relatively easy 531 to see the effect of rush hours at the beginning and the end of the 532 day. For the beginning of the day, we should look at the numbers of 533 "(I09) Total number and bytes of initial messages per day" and for 534 the end of the day we should look at the number of "(T09) Total 535 number and bytes of terminating messages per day". Taking these 536 numbers with some assumed percentage of the number of users logging 537 in at the same hour should give good indication for the rush hour 538 load. 540 2.4. No optimizations used 542 The following table uses some common presence characteristics to 543 demonstrate the effect these factors have on state and message rate 544 within a presence domain using base SIP without any proposed 545 optimizations. In this example, there are two presence domains with 546 a total of 40,000 federating users with an average of 4 contacts in 547 the peer domain. Note that the main calculation is done for a 548 presence document size of 350 bytes, which is the base PIDF [7] 549 document size, but the bottom line calculation is also given for a 550 presence document size for rich presence [8], which is assumed to be 551 3000 bytes based on the examples given in the RFCs. This two-fold 552 calculation is done for every use case in this document. 554 ** Constants 555 (C01) Subscription lifetime (hours)...........................8 556 (C02) Presence state changes / hour...........................3 557 (C03) Subscription refresh interval / hour....................1 558 (C04) Total federated presentities per watcher................4 559 (C05) Number of dialogs to maintain per watcher...............4 560 (C06) Total number of watchers in domains................40,000 561 (C07) SUBSCRIBE message size in bytes.......................450 562 (C08) 200 OK for SUBSCRIBE message size in bytes............370 563 (C09) NOTIFY message size not including presence doc........500 564 (C10) 200 OK for NOTIFY message size in bytes...............370 565 (C11) Size of an average presence document..................350 567 ** Initial Messages 568 (I01) Initial SUBSCRIBE msgs per watcher......................4 569 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............4 570 (I03) Initial NOTIFY msgs per watcher.........................4 571 (I04) Initial 200 OK msgs (NOTIFY) per watcher................4 572 (I05) Total number & bytes of initial SUBSCRIBE msgs 573 Number of msgs for all watchers...............160,000 574 Bytes for all watchers.....................72,000,000 575 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 576 Number of msgs for all watchers...............160,000 577 Bytes for all watchers.....................59,200,000 578 (I07) Total number & bytes of initial NOTIFY msgs 579 Number of msgs for all watchers...............160,000 580 Bytes for all watchers....................136,000,000 581 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 582 Number of msgs for all watchers...............160,000 583 Bytes for all watchers.....................59,200,000 584 (I09) Total number & bytes of initial messages per day 585 Number of msgs for all watchers...............640,000 586 Bytes for all watchers....................326,400,000 588 ** Steady State Messages 589 (S01) NOTIFY msgs due to state change 590 per watched presentity per day.....................22 591 (S02) 200 (for NOTIFY due to state change) msgs 592 per watched presentity per day.....................22 593 (S03) Total number and size of msgs due to state change per day 594 Number of msgs for all watchers.............7,040,000 595 Bytes for all watchers..................4,294,400,000 596 (S04) Number of SUBSCRIBE msgs for refreshes 597 per watcher per day................................28 598 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 599 per watcher per day................................28 600 (S06) Number of NOTIFY msgs for refreshes 601 per watcher per day................................28 602 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 603 per watcher per day................................28 604 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 605 Number of msgs for all watchers per day.....4,480,000 606 Bytes for all watchers per day..........2,284,800,000 607 (S09) Total number & bytes of steady messages per day 608 Number of msgs for all watchers............11,520,000 609 Bytes for all watchers..................6,579,200,000 611 ** Termination Messages 612 (T01) Terminating SUBSCRIBE msgs per watcher..................4 613 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........4 614 (T03) Terminating NOTIFY msgs per watcher.....................4 615 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............4 616 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 617 Number of msgs for all watchers.............. 160,000 618 Bytes for all watchers.....................72,000,000 619 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 620 Number of msgs for all watchers...............160,000 621 Bytes for all watchers.....................59,200,000 622 (T07) Total number & bytes of terminating NOTIFY msgs 623 Number of msgs for all watchers...............160,000 624 Bytes for all watchers....................136,000,000 625 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 626 Number of msgs for all watchers...............160,000 627 Bytes for all watchers.....................59,200,000 628 (T09) Total number & bytes of terminating messages per day 629 Number of msgs for all watchers...............640,000 630 Bytes for all watchers....................326,400,000 632 ** Bottom Line 633 (B01) Total of messages between domains..............12,800,000 634 Total of bytes between domains (PD=350).....7,232,000,000 635 Total of bytes between domains (PD=3000)...20,376,000,000 637 (B02) Total number of messages / second.. ..................444 638 Total of bytes per second (PD=350)................251,111 639 Total of bytes per second (PD=3000)...............707,500 640 (B03) Total number of by msgs per user/day......... ........320 641 Total number of bytes per user/day (PD=350).......180,800 642 Total number of bytes per user/day (PD=3000)......509,400 644 Figure 1: No optimizations used 646 2.5. Dialog optimization used 648 The same analysis provided above is repeated here with the assumption 649 that the dialog optimization is applied. Note that while the sign-in 650 (ramp up) and sign-out messages flows are positively affected, the 651 steady state rates are not. 653 ** Constants 654 (C01) Subscription lifetime (hours)...........................8 655 (C02) Presence state changes / hour...........................3 656 (C03) Subscription refresh interval / hour....................1 657 (C04) Total federated presentities per watcher................4 658 (C05) Number of dialogs to maintain per watcher...............1 659 (C06) Total number of watchers in domains................40,000 660 (C07) SUBSCRIBE message size in bytes.......................450 661 (C08) 200 OK for SUBSCRIBE message size in bytes............370 662 (C09) NOTIFY message size not including presence doc........500 663 (C10) 200 OK for NOTIFY message size in bytes...............370 664 (C11) Size of an average presence document..................350 665 (C13) Additional data per document in RLMI..................160 666 (C14) Multiparty boundary in RLMI document..................144 667 (C15) XML root node in RLMI document........................144 669 ** Initial Messages 670 (I01) Initial SUBSCRIBE msgs per watcher......................1 671 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1 672 (I03) Initial NOTIFY msgs per watcher.........................1 673 (I04) Initial 200 OK msgs (NOTIFY) per watcher................1 674 (I05) Total number & bytes of initial SUBSCRIBE msgs 675 Number of msgs for all watchers................40,000 676 Bytes for all watchers.....................18,000,000 677 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 678 Number of msgs for all watchers................40,000 679 Bytes for all watchers.....................14,800,000 680 (I07) Total number & bytes of initial NOTIFY msgs 681 Number of msgs for all watchers................40,000 682 Bytes for all watchers....................136,160,000 683 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 684 Number of msgs for all watchers................40,000 685 Bytes for all watchers.....................14,800,000 686 (I09) Total number & bytes of initial messages per day 687 Number of msgs for all watchers...............160,000 688 Bytes for all watchers....................183,760,000 690 ** Steady State Messages 691 (S01) NOTIFY msgs due to state change 692 per watched presentity per day.....................22 693 (S02) 200 (for NOTIFY due to state change) msgs 694 per watched presentity per day.....................22 695 (S03) Total number and size of msgs due to state change per day 696 Number of msgs for all watchers.............7,040,000 697 Bytes for all watchers..................6,378,240,000 698 (S04) Number of SUBSCRIBE msgs for refreshes 699 per watcher per day.................................7 700 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 701 per watcher per day.................................7 702 (S06) Number of NOTIFY msgs for refreshes 703 per watcher per day.................................7 704 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 705 per watcher per day.................................7 706 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 707 Number of msgs for all watchers per day.....1,120,000 708 Bytes for all watchers per day..........1,286,320,000 709 (S09) Total number & bytes of steady messages per day 710 Number of msgs for all watchers.............8,160,000 711 Bytes for all watchers..................7,664,560,000 713 ** Termination Messages 714 (T01) Terminating SUBSCRIBE msgs per watcher..................1 715 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1 716 (T03) Terminating NOTIFY msgs per watcher.....................1 717 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............1 718 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 719 Number of msgs for all watchers................40,000 720 Bytes for all watchers.....................18,000,000 721 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 722 Number of msgs for all watchers................40,000 723 Bytes for all watchers.....................14,800,000 724 (T07) Total number & bytes of terminating NOTIFY msgs 725 Number of msgs for all watchers................40,000 726 Bytes for all watchers....................136,160,000 727 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 728 Number of msgs for all watchers................40,000 729 Bytes for all watchers.....................14,800,000 730 (T09) Total number & bytes of terminating messages per day 731 Number of msgs for all watchers...............160,000 732 Bytes for all watchers....................183,760,000 734 ** Bottom Line 735 (B01) Total of messages between domains...............8,480,000 736 Total of bytes between domains (PD=350).....8,032,080,000 737 Total of bytes between domains (PD=3000)...21,176,080,000 738 (B02) Total number of messages / second.....................294 739 Total of bytes per second (PD=350)................278,892 740 Total of bytes per second (PD=3000)...............735,281 741 (B03) Total number of by msgs per user/day..................212 742 Total number of bytes per user/day (PD=350).......200,802 743 Total number of bytes per user/day (PD=3000)......529,042 745 Figure 2: Dialog optimization used 747 2.6. NOTIFY optimization used 749 The analysis provided in Figure 1 is repeated here with the 750 assumption that the notification optimization is applied. The 751 optimization saves the need for NOTIFY upon refreshing a SUBSCRIBE if 752 there was no change since the last NOTIFY. It is assumed here that 753 there are no NOTIFY messages for SUBSCRIBE refreshes and 754 terminations. As expected, this optimization affects the steady and 755 termination state and does not affect the initial state. 757 ** Constants 758 (C01) Subscription lifetime (hours)...........................8 759 (C02) Presence state changes / hour...........................3 760 (C03) Subscription refresh interval / hour....................1 761 (C04) Total federated presentities per watcher................4 762 (C05) Number of dialogs to maintain per watcher...............4 763 (C06) Total number of watchers in domains................40,000 764 (C07) SUBSCRIBE message size in bytes.......................450 765 (C08) 200 OK for SUBSCRIBE message size in bytes............370 766 (C09) NOTIFY message size not including presence doc........500 767 (C10) 200 OK for NOTIFY message size in bytes...............370 768 (C11) Size of an average presence document..................350 770 ** Initial Messages 771 (I01) Initial SUBSCRIBE msgs per watcher......................4 772 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............4 773 (I03) Initial NOTIFY msgs per watcher.........................4 774 (I04) Initial 200 OK msgs (NOTIFY) per watcher................4 775 (I05) Total number & bytes of initial SUBSCRIBE msgs 776 Number of msgs for all watchers...............160,000 777 Bytes for all watchers.....................72,000,000 778 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 779 Number of msgs for all watchers...............160,000 780 Bytes for all watchers.....................59,200,000 781 (I07) Total number & bytes of initial NOTIFY msgs 782 Number of msgs for all watchers...............160,000 783 Bytes for all watchers....................136,000,000 784 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 785 Number of msgs for all watchers...............160,000 786 Bytes for all watchers.....................59,200,000 787 (I09) Total number & bytes of initial messages per day 788 Number of msgs for all watchers...............640,000 789 Bytes for all watchers....................326,400,000 791 ** Steady State Messages 792 (S01) NOTIFY msgs due to state change 793 per watched presentity per day.....................22 794 (S02) 200 (for NOTIFY due to state change) msgs 795 per watched presentity per day.....................22 796 (S03) Total number and size of msgs due to state change per day 797 Number of msgs for all watchers.............7,040,000 798 Bytes for all watchers..................4,294,400,000 799 (S04) Number of SUBSCRIBE msgs for refreshes 800 per watcher per day................................28 801 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 802 per watcher per day................................28 803 (S06) Number of NOTIFY msgs for refreshes 804 per watcher per day.................................0 805 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 806 per watcher per day.................................0 807 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 808 Number of msgs for all watchers per day.....2,240,000 809 Bytes for all watchers per day............918,400,000 810 (S09) Total number & bytes of steady messages per day 811 Number of msgs for all watchers.............9,280,000 812 Bytes for all watchers..................5,212,800,000 814 ** Termination Messages 815 (T01) Terminating SUBSCRIBE msgs per watcher..................4 816 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........4 817 (T03) Terminating NOTIFY msgs per watcher.....................0 818 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............0 819 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 820 Number of msgs for all watchers.............. 160,000 821 Bytes for all watchers.....................72,000,000 822 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 823 Number of msgs for all watchers...............160,000 824 Bytes for all watchers.....................59,200,000 825 (T07) Total number & bytes of terminating NOTIFY msgs 826 Number of msgs for all watchers.....................0 827 Bytes for all watchers..............................0 829 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 830 Number of msgs for all watchers.....................0 831 Bytes for all watchers..............................0 832 (T09) Total number & bytes of terminating messages per day 833 Number of msgs for all watchers...............320,000 834 Bytes for all watchers....................131,200,000 836 ** Bottom Line 837 (B01) Total of messages between domains..............10,240,000 838 Total of bytes between domains (PD=350).....5,670,400,000 839 Total of bytes between domains (PD=3000)...15,422,400,000 840 (B02) Total number of messages / second.....................356 841 Total of bytes per second (PD=350)................196,889 842 Total of bytes per second (PD=3000)...............535,500 843 (B03) Total number of by msgs per user/day..................256 844 Total number of bytes per user/day (PD=350).......141,760 845 Total number of bytes per user/day (PD=3000)......385,560 847 Figure 3: NOTIFY optimization used 849 2.7. Dialog and NOTIFY optimizations used 851 Here both optimizations are combined. In all the subsequent use 852 cases, we will show only the analysis with no optimizations and with 853 both optimizations combined. 855 ** Constants 856 (C01) Subscription lifetime (hours)...........................8 857 (C02) Presence state changes / hour...........................3 858 (C03) Subscription refresh interval / hour....................1 859 (C04) Total federated presentities per watcher................4 860 (C05) Number of dialogs to maintain per watcher...............1 861 (C06) Total number of watchers in domains................40,000 862 (C07) SUBSCRIBE message size in bytes.......................450 863 (C08) 200 OK for SUBSCRIBE message size in bytes............370 864 (C09) NOTIFY message size not including presence doc........500 865 (C10) 200 OK for NOTIFY message size in bytes...............370 866 (C11) Size of an average presence document..................350 867 (C13) Additional data per document in RLMI..................160 868 (C14) Multiparty boundary in RLMI document..................144 869 (C15) XML root node in RLMI document........................144 871 ** Initial Messages 872 (I01) Initial SUBSCRIBE msgs per watcher......................1 873 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1 874 (I03) Initial NOTIFY msgs per watcher.........................1 875 (I04) Initial 200 OK msgs (NOTIFY) per watcher................1 876 (I05) Total number & bytes of initial SUBSCRIBE msgs 877 Number of msgs for all watchers................40,000 878 Bytes for all watchers.....................18,000,000 879 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 880 Number of msgs for all watchers................40,000 881 Bytes for all watchers.....................14,800,000 882 (I07) Total number & bytes of initial NOTIFY msgs 883 Number of msgs for all watchers................40,000 884 Bytes for all watchers....................136,160,000 885 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 886 Number of msgs for all watchers................40,000 887 Bytes for all watchers.....................14,800,000 888 (I09) Total number & bytes of initial messages per day 889 Number of msgs for all watchers...............160,000 890 Bytes for all watchers....................183,760,000 892 ** Steady State Messages 893 (S01) NOTIFY msgs due to state change 894 per watched presentity per day.....................22 895 (S02) 200 (for NOTIFY due to state change) msgs 896 per watched presentity per day.....................22 897 (S03) Total number and size of msgs due to state change per day 898 Number of msgs for all watchers.............7,040,000 899 Bytes for all watchers..................6,378,240,000 900 (S04) Number of SUBSCRIBE msgs for refreshes 901 per watcher per day.................................7 902 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 903 per watcher per day.................................7 904 (S06) Number of NOTIFY msgs for refreshes 905 per watcher per day.................................0 906 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 907 per watcher per day.................................0 908 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 909 Number of msgs for all watchers per day.......560,000 910 Bytes for all watchers per day............229,600,000 911 (S09) Total number & bytes of steady messages per day 912 Number of msgs for all watchers.............7,600,000 913 Bytes for all watchers..................6,607,840,000 915 ** Termination Messages 916 (T01) Terminating SUBSCRIBE msgs per watcher..................1 917 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1 918 (T03) Terminating NOTIFY msgs per watcher.....................0 919 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............0 920 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 921 Number of msgs for all watchers................40,000 922 Bytes for all watchers.....................18,000,000 923 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 924 Number of msgs for all watchers................40,000 925 Bytes for all watchers.....................14,800,000 926 (T07) Total number & bytes of terminating NOTIFY msgs 927 Number of msgs for all watchers.....................0 928 Bytes for all watchers..............................0 929 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 930 Number of msgs for all watchers.....................0 931 Bytes for all watchers..............................0 932 (T09) Total number & bytes of terminating messages per day 933 Number of msgs for all watchers................80,000 934 Bytes for all watchers.....................32,800,000 936 ** Bottom Line 937 (B01) Total of messages between domains...............7,840,000 938 Total of bytes between domains (PD=350).....6,824,400,000 939 Total of bytes between domains (PD=3000)...16,576,400,000 940 (B02) Total number of messages / second.....................272 941 Total of bytes per second (PD=350)................236,958 942 Total of bytes per second (PD=3000)...............575,569 943 (B03) Total number of by msgs per user/day..................196 944 Total number of bytes per user/day (PD=350).......170,610 945 Total number of bytes per user/day (PD=3000)......414,410 947 Figure 4: Dialog and NOTIFY optimizations used 949 2.8. Presence Federation Scenarios 951 While scalability issues exist in any large deployment, certain 952 characteristics make the deployment conducive to the existing 953 optimizations, and others have characteristics that do not. 954 Following is a list of federation scenarios that have varying usage 955 characteristics. For each, a message rate and bandwidth table is 956 provided reflecting typical changes message rates. Those 957 characteristics can alter the overall effectiveness of existing 958 optimizations. 960 Note that the number of users considered is not the total number of 961 users in the domains but the actual logged-in users. As was 962 mentioned before, not all the domain users will use the presence 963 service at the same time. The numbers used for watchers and watched 964 presentities are for online users. 966 2.8.1. Widely distributed inter-domain presence 968 In some environments, presence federation may be common, perhaps even 969 more common than intra-domain presence. An example of this type of 970 environment is a small ISV or public server. Users in that small ISV 971 are not likely to subscribe to the presence of other users in the 972 their server since they do not necessarily have any relationship with 973 each other aside from receiving service from the same provider. They 974 are much more likely to be subscribed to the presence of users in one 975 of the federated domains (whether in consumer domains, academic, 976 other ISVs, etc). Common characteristics of this deployment are: 978 o Federated subscriptions are the majority of subscription traffic. 979 o Individual users are likely to subscribe to multiple users in any 980 one domain. 981 o The intersection of users in the deployment watching the same 982 presentities is quite small (that is, the probability that 983 multiple watchers in the domain are subscribed to the same 984 presentity is low). 986 To account for the extraordinarily high percentage of federation 987 traffic, the number of federated presentities is increased to 20. 988 Although the number of watchers in the domain could also be adjusted 989 to allow for an expected larger community of users being peered with, 990 it is omitted here for simplification. 992 The first table below provides the calculations without 993 optimizations. The second table provides the calculations with 994 optimizations. 996 ** Constants 997 (C01) Subscription lifetime (hours)...........................8 998 (C02) Presence state changes / hour...........................3 999 (C03) Subscription refresh interval / hour....................1 1000 (C04) Total federated presentities per watcher...............20 1001 (C05) Number of dialogs to maintain per watcher..............20 1002 (C06) Total number of watchers in domains................40,000 1003 (C07) SUBSCRIBE message size in bytes.......................450 1004 (C08) 200 OK for SUBSCRIBE message size in bytes............370 1005 (C09) NOTIFY message size not including presence doc........500 1006 (C10) 200 OK for NOTIFY message size in bytes...............370 1007 (C11) Size of an average presence document..................350 1009 ** Initial Messages 1010 (I01) Initial SUBSCRIBE msgs per watcher.....................20 1011 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher............20 1012 (I03) Initial NOTIFY msgs per watcher........................20 1013 (I04) Initial 200 OK msgs (NOTIFY) per watcher...............20 1014 (I05) Total number & bytes of initial SUBSCRIBE msgs 1015 Number of msgs for all watchers...............800,000 1016 Bytes for all watchers....................360,000,000 1017 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 1018 Number of msgs for all watchers...............800,000 1019 Bytes for all watchers....................296,000,000 1020 (I07) Total number & bytes of initial NOTIFY msgs 1021 Number of msgs for all watchers...............800,000 1022 Bytes for all watchers....................680,000,000 1023 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 1024 Number of msgs for all watchers...............800,000 1025 Bytes for all watchers....................296,000,000 1026 (I09) Total number & bytes of initial messages per day 1027 Number of msgs for all watchers.............3,200,000 1028 Bytes for all watchers..................1,632,000,000 1030 ** Steady State Messages 1031 (S01) NOTIFY msgs due to state change 1032 per watched presentity per day.....................22 1033 (S02) 200 (for NOTIFY due to state change) msgs 1034 per watched presentity per day.....................22 1035 (S03) Total number and size of msgs due to state change per day 1036 Number of msgs for all watchers............35,200,000 1037 Bytes for all watchers.................21,472,000,000 1038 (S04) Number of SUBSCRIBE msgs for refreshes 1039 per watcher per day...............................140 1040 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 1041 per watcher per day...............................140 1042 (S06) Number of NOTIFY msgs for refreshes 1043 per watcher per day...............................140 1044 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1045 per watcher per day...............................140 1046 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1047 Number of msgs for all watchers per day....22,400,000 1048 Bytes for all watchers per day.........11,424,000,000 1049 (S09) Total number & bytes of steady messages per day 1050 Number of msgs for all watchers............57,600,000 1051 Bytes for all watchers.................32,896,000,000 1053 ** Termination Messages 1054 (T01) Terminating SUBSCRIBE msgs per watcher.................20 1055 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........20 1056 (T03) Terminating NOTIFY msgs per watcher....................20 1057 (T04) Terminating 200 OK msgs (NOTIFY) per watcher...........20 1058 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1059 Number of msgs for all watchers...............800,000 1060 Bytes for all watchers....................360,000,000 1061 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1062 Number of msgs for all watchers...............800,000 1063 Bytes for all watchers....................296,000,000 1064 (T07) Total number & bytes of terminating NOTIFY msgs 1065 Number of msgs for all watchers...............800,000 1066 Bytes for all watchers....................680,000,000 1067 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 1068 Number of msgs for all watchers...............800,000 1069 Bytes for all watchers....................296,000,000 1070 (T09) Total number & bytes of terminating messages per day 1071 Number of msgs for all watchers.............3,200,000 1072 Bytes for all watchers..................1,632,000,000 1074 ** Bottom Line 1075 (B01) Total of messages between domains..............64,000,000 1076 Total of bytes between domains (PD=350)....36,160,000,000 1077 Total of bytes between domains (PD=3000)..101,880,000,000 1078 (B02) Total number of messages / second...................2,222 1079 Total of bytes per second (PD=350)..............1,255,556 1080 Total of bytes per second (PD=3000).............3,537,500 1081 (B03) Total number of by msgs per user/day................1,600 1082 Total number of bytes per user/day (PD=350).......904,000 1083 Total number of bytes per user/day (PD=3000)....2,547,000 1085 Figure 5: Widely distributed inter-domain with no optimizations 1087 ** Constants 1088 (C01) Subscription lifetime (hours)...........................8 1089 (C02) Presence state changes / hour...........................3 1090 (C03) Subscription refresh interval / hour....................1 1091 (C04) Total federated presentities per watcher...............20 1092 (C05) Number of dialogs to maintain per watcher...............1 1093 (C06) Total number of watchers in domains................40,000 1094 (C07) SUBSCRIBE message size in bytes.......................450 1095 (C08) 200 OK for SUBSCRIBE message size in bytes............370 1096 (C09) NOTIFY message size not including presence doc........500 1097 (C10) 200 OK for NOTIFY message size in bytes...............370 1098 (C11) Size of an average presence document..................350 1099 (C13) Additional data per document in RLMI..................160 1100 (C14) Multiparty boundary in RLMI document..................144 1101 (C15) XML root node in RLMI document........................144 1103 ** Initial Messages 1104 (I01) Initial SUBSCRIBE msgs per watcher......................1 1105 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1 1106 (I03) Initial NOTIFY msgs per watcher.........................1 1107 (I04) Initial 200 OK msgs (NOTIFY) per watcher................1 1108 (I05) Total number & bytes of initial SUBSCRIBE msgs 1109 Number of msgs for all watchers................40,000 1110 Bytes for all watchers.....................18,000,000 1111 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 1112 Number of msgs for all watchers................40,000 1113 Bytes for all watchers.....................14,800,000 1114 (I07) Total number & bytes of initial NOTIFY msgs 1115 Number of msgs for all watchers................40,000 1116 Bytes for all watchers....................554,720,000 1117 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 1118 Number of msgs for all watchers................40,000 1119 Bytes for all watchers.....................14,800,000 1120 (I09) Total number & bytes of initial messages per day 1121 Number of msgs for all watchers...............160,000 1122 Bytes for all watchers....................602,320,000 1124 ** Steady State Messages 1125 (S01) NOTIFY msgs due to state change 1126 per watched presentity per day.....................22 1127 (S02) 200 (for NOTIFY due to state change) msgs 1128 per watched presentity per day.....................22 1129 (S03) Total number and size of msgs due to state change per day 1130 Number of msgs for all watchers............35,200,000 1131 Bytes for all watchers.................31,891,200,000 1132 (S04) Number of SUBSCRIBE msgs for refreshes 1133 per watcher per day.................................7 1134 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 1135 per watcher per day.................................7 1136 (S06) Number of NOTIFY msgs for refreshes 1137 per watcher per day.................................0 1138 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1139 per watcher per day.................................0 1140 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1141 Number of msgs for all watchers per day.......560,000 1142 Bytes for all watchers per day............229,600,000 1143 (S09) Total number & bytes of steady messages per day 1144 Number of msgs for all watchers............35,760,000 1145 Bytes for all watchers.................32,120,800,000 1147 ** Termination Messages 1148 (T01) Terminating SUBSCRIBE msgs per watcher..................1 1149 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1 1150 (T03) Terminating NOTIFY msgs per watcher.....................0 1151 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............0 1152 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1153 Number of msgs for all watchers................40,000 1154 Bytes for all watchers.....................18,000,000 1155 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1156 Number of msgs for all watchers................40,000 1157 Bytes for all watchers.....................14,800,000 1158 (T07) Total number & bytes of terminating NOTIFY msgs 1159 Number of msgs for all watchers.....................0 1160 Bytes for all watchers..............................0 1161 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 1162 Number of msgs for all watchers.....................0 1163 Bytes for all watchers..............................0 1165 (T09) Total number & bytes of terminating messages per day 1166 Number of msgs for all watchers................80,000 1167 Bytes for all watchers.....................32,800,000 1169 ** Bottom Line 1170 (B01) Total of messages between domains..............36,000,000 1171 Total of bytes between domains (PD=350)....32,755,920,000 1172 Total of bytes between domains (PD=3000)...81,515,920,000 1173 (B02) Total number of messages / second...................1,250 1174 Total of bytes per second (PD=350)..............1,137,358 1175 Total of bytes per second (PD=3000).............2,830,414 1176 (B03) Total number of by msgs per user/day..................900 1177 Total number of bytes per user/day (PD=350).......818,898 1178 Total number of bytes per user/day (PD=3000)....2,037,898 1180 Figure 6: Widely distributed inter-domain with optimizations 1182 2.8.2. Associated inter-domain presence 1184 In this type of environment, the domain is a collection of associated 1185 users, such as an enterprise. Here, federation is once again common. 1186 However, there is also a strong association between some users in the 1187 deployment. These associations make it somewhat more likely that 1188 users in that domain are watchers of the same presentity. This can 1189 occur because of business relationships (for example, two co-workers 1190 on a project federating with a partner company). 1192 Common characteristics of this deployment are: 1194 o Federated subscriptions are large minority or small majority of 1195 subscription traffic. 1196 o Individual users are likely to subscribe to multiple users in any 1197 one domain, especially their own. 1198 o The intersection of users in the deployment watching the same 1199 presentities increases. 1201 This federation type has traffic rates similar to the previous 1202 examples but with different levels of association of the users. 1204 2.8.3. Large network peering 1206 In this environment, two or more Large networks create a peering 1207 relationship, allowing their users to subscribe to presence in the 1208 other domains. Whereas the number of users in other deployment types 1209 ranges from hundreds to several hundred thousand, these large 1210 networks host up to hundreds of millions of users. Examples of these 1211 networks are large wireless carriers and consumer instant messaging 1212 networks. 1214 Common characteristics of this deployment are: 1216 o As users become accustomed to network boundaries disappearing, 1217 federated subscriptions become as common as subscriptions within 1218 the same domain. 1219 o Individual users are highly likely to want to see presence of 1220 multiple presentities in the peer network. 1221 o The intersection of users in the deployment watching the same 1222 presentities is high (that is, two or more users in network A are 1223 extremely likely to be watching a same user in network B). 1224 o Status changes increase greatly due to typical observed consumer 1225 behavior. 1227 The first table below provides the calculations without 1228 optimizations; the second table provides the calculations with 1229 optimizations. Even though the optimizations help a lot (almost cut 1230 the number of messages by half), the numbers are still high. Note 1231 also that the bandwidth required is high. 1233 ** Constants 1234 (C01) Subscription lifetime (hours)...........................8 1235 (C02) Presence state changes / hour...........................6 1236 (C03) Subscription refresh interval / hour....................1 1237 (C04) Total federated presentities per watcher...............10 1238 (C05) Number of dialogs to maintain per watcher..............10 1239 (C06) Total number of watchers in domains............20,000,000 1240 (C07) SUBSCRIBE message size in bytes.......................450 1241 (C08) 200 OK for SUBSCRIBE message size in bytes............370 1242 (C09) NOTIFY message size not including presence doc........500 1243 (C10) 200 OK for NOTIFY message size in bytes...............370 1244 (C11) Size of an average presence document..................350 1246 ** Initial Messages 1247 (I01) Initial SUBSCRIBE msgs per watcher.....................10 1248 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher............10 1249 (I03) Initial NOTIFY msgs per watcher........................10 1250 (I04) Initial 200 OK msgs (NOTIFY) per watcher...............10 1251 (I05) Total number & bytes of initial SUBSCRIBE msgs 1252 Number of msgs for all watchers...........200,000,000 1253 Bytes for all watchers.................90,000,000,000 1254 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 1255 Number of msgs for all watchers...........200,000,000 1256 Bytes for all watchers.................74,000,000,000 1257 (I07) Total number & bytes of initial NOTIFY msgs 1258 Number of msgs for all watchers...........200,000,000 1259 Bytes for all watchers................170,000,000,000 1260 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 1261 Number of msgs for all watchers...........200,000,000 1262 Bytes for all watchers.................74,000,000,000 1263 (I09) Total number & bytes of initial messages per day 1264 Number of msgs for all watchers...........800,000,000 1265 Bytes for all watchers................408,000,000,000 1267 ** Steady State Messages 1268 (S01) NOTIFY msgs due to state change 1269 per watched presentity per day.....................46 1270 (S02) 200 (for NOTIFY due to state change) msgs 1271 per watched presentity per day.....................46 1272 (S03) Total number and size of msgs due to state change per day 1273 Number of msgs for all watchers........18,400,000,000 1274 Bytes for all watchers.............11,224,000,000,000 1275 (S04) Number of SUBSCRIBE msgs for refreshes 1276 per watcher per day................................70 1277 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 1278 per watcher per day................................70 1279 (S06) Number of NOTIFY msgs for refreshes 1280 per watcher per day................................70 1281 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1282 per watcher per day................................70 1283 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1284 Number of msgs for all watchers per day.5,600,000,000 1285 Bytes for all watchers per day......2,856,000,000,000 1286 (S09) Total number & bytes of steady messages per day 1287 Number of msgs for all watchers........24,000,000,000 1288 Bytes for all watchers.............14,080,000,000,000 1290 ** Termination Messages 1291 (T01) Terminating SUBSCRIBE msgs per watcher.................10 1292 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........10 1293 (T03) Terminating NOTIFY msgs per watcher....................10 1294 (T04) Terminating 200 OK msgs (NOTIFY) per watcher...........10 1295 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1296 Number of msgs for all watchers...........200,000,000 1297 Bytes for all watchers.................90,000,000,000 1298 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1299 Number of msgs for all watchers...........200,000,000 1300 Bytes for all watchers.................74,000,000,000 1301 (T07) Total number & bytes of terminating NOTIFY msgs 1302 Number of msgs for all watchers...........200,000,000 1303 Bytes for all watchers................170,000,000,000 1304 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 1305 Number of msgs for all watchers...........200,000,000 1306 Bytes for all watchers.................74,000,000,000 1307 (T09) Total number & bytes of terminating messages per day 1308 Number of msgs for all watchers...........800,000,000 1309 Bytes for all watchers................408,000,000,000 1311 ** Bottom Line 1312 (B01) Total of messages between domains..........25,600,000,000 1313 Total of bytes bet. domains (PD=350)...14,896,000,000,000 1314 Total of bytes bet. domains (PD=3000)..44,046,000,000,000 1315 (B02) Total number of messages / second.................888,889 1316 Total of bytes per second (PD=350)............517,222,222 1317 Total of bytes per second (PD=3000).........1,529,375,000 1318 (B03) Total number of by msgs per user/day................1,280 1319 Total number of bytes per user/day (PD=350).......744,800 1320 Total number of bytes per user/day (PD=3000)....2,202,300 1322 Figure 7: Large network peering with no optimizations 1324 ** Constants 1325 (C01) Subscription lifetime (hours)...........................8 1326 (C02) Presence state changes / hour...........................6 1327 (C03) Subscription refresh interval / hour....................1 1328 (C04) Total federated presentities per watcher...............10 1329 (C05) Number of dialogs to maintain per watcher...............1 1330 (C06) Total number of watchers in domains............20,000,000 1331 (C07) SUBSCRIBE message size in bytes.......................450 1332 (C08) 200 OK for SUBSCRIBE message size in bytes............370 1333 (C09) NOTIFY message size not including presence doc........500 1334 (C10) 200 OK for NOTIFY message size in bytes...............370 1335 (C11) Size of an average presence document..................350 1336 (C13) Additional data per document in RLMI..................160 1337 (C14) Multiparty boundary in RLMI document..................144 1338 (C15) XML root node in RLMI document........................144 1340 ** Initial Messages 1341 (I01) Initial SUBSCRIBE msgs per watcher......................1 1342 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1 1343 (I03) Initial NOTIFY msgs per watcher.........................1 1344 (I04) Initial 200 OK msgs (NOTIFY) per watcher................1 1345 (I05) Total number & bytes of initial SUBSCRIBE msgs 1346 Number of msgs for all watchers............20,000,000 1347 Bytes for all watchers..................9,000,000,000 1348 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 1349 Number of msgs for all watchers............20,000,000 1350 Bytes for all watchers..................7,400,000,000 1351 (I07) Total number & bytes of initial NOTIFY msgs 1352 Number of msgs for all watchers............20,000,000 1353 Bytes for all watchers................146,560,000,000 1354 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 1355 Number of msgs for all watchers............20,000,000 1356 Bytes for all watchers..................7,400,000,000 1357 (I09) Total number & bytes of initial messages per day 1358 Number of msgs for all watchers............80,000,000 1359 Bytes for all watchers................170,360,000,000 1361 ** Steady State Messages 1362 (S01) NOTIFY msgs due to state change 1363 per watched presentity per day.....................46 1364 (S02) 200 (for NOTIFY due to state change) msgs 1365 per watched presentity per day.....................46 1366 (S03) Total number and size of msgs due to state change per day 1367 Number of msgs for all watchers........18,400,000,000 1368 Bytes for all watchers.............16,670,400,000,000 1369 (S04) Number of SUBSCRIBE msgs for refreshes 1370 per watcher per day.................................7 1371 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 1372 per watcher per day.................................7 1373 (S06) Number of NOTIFY msgs for refreshes 1374 per watcher per day.................................0 1375 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1376 per watcher per day.................................0 1377 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1378 Number of msgs for all watchers per day...280,000,000 1379 Bytes for all watchers per day........114,800,000,000 1380 (S09) Total number & bytes of steady messages per day 1381 Number of msgs for all watchers........18,680,000,000 1382 Bytes for all watchers.............16,785,200,000,000 1384 ** Termination Messages 1385 (T01) Terminating SUBSCRIBE msgs per watcher..................1 1386 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1 1387 (T03) Terminating NOTIFY msgs per watcher.....................0 1388 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............0 1389 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1390 Number of msgs for all watchers............20,000,000 1391 Bytes for all watchers..................9,000,000,000 1392 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1393 Number of msgs for all watchers............20,000,000 1394 Bytes for all watchers..................7,400,000,000 1395 (T07) Total number & bytes of terminating NOTIFY msgs 1396 Number of msgs for all watchers.....................0 1397 Bytes for all watchers..............................0 1398 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 1399 Number of msgs for all watchers.....................0 1400 Bytes for all watchers..............................0 1401 (T09) Total number & bytes of terminating messages per day 1402 Number of msgs for all watchers............40,000,000 1403 Bytes for all watchers.................16,400,000,000 1405 ** Bottom Line 1406 (B01) Total of messages between domains..........18,800,000,000 1407 Total of bytes bet. domains (PD=350)...16,971,960,000,000 1408 Total of bytes bet. domains (PD=3000)..41,881,960,000,000 1409 (B02) Total number of messages / second.................652,778 1410 Total of bytes per second (PD=350)............589,304,167 1411 Total of bytes per second (PD=3000).........1,454,234,722 1412 (B03) Total number of by msgs per user/day..................940 1413 Total number of bytes per user/day (PD=350).......848,598 1414 Total number of bytes per user/day (PD=3000)....2,094,098 1416 Figure 8: Large network peering with optimizations 1418 2.8.4. Intra-domain peering 1420 Within a particular domain, multiple presence infrastructures are 1421 deployed with users split between them. This scenario is unique in 1422 that federated messages do not pass outside the administrative 1423 domain's network. The two infrastructures peer directly inside the 1424 domain. A common example of this is an enterprise IT system that has 1425 deployed multiple, independent-vendor presence solutions (for 1426 example, a presence solution for desktop messaging deployed alongside 1427 a presence solution for IP telephony). 1429 Common characteristics of this deployment are: 1431 o The difference between subscriptions to presentities in one system 1432 versus the other are completely arbitrary. Any one presentity is 1433 as likely to be homed on one infrastructure as the other. 1434 o Active users are almost guaranteed to subscribe to many users in 1435 the peer infrastructure. 1436 o The level of intersection of presentities is extremely high. 1438 The first table below provides the calculations without 1439 optimizations. The second table provides the calculations with 1440 optimization. Although relatively conservative numbers are used, the 1441 number of messages is still high even though optimization may cut the 1442 traffic by more than half. 1444 ** Constants 1445 (C01) Subscription lifetime (hours)...........................8 1446 (C02) Presence state changes / hour...........................3 1447 (C03) Subscription refresh interval / hour....................1 1448 (C04) Total federated presentities per watcher...............10 1449 (C05) Number of dialogs to maintain per watcher..............10 1450 (C06) Total number of watchers in domains...............120,000 1451 (C07) SUBSCRIBE message size in bytes.......................450 1452 (C08) 200 OK for SUBSCRIBE message size in bytes............370 1453 (C09) NOTIFY message size not including presence doc........500 1454 (C10) 200 OK for NOTIFY message size in bytes...............370 1455 (C11) Size of an average presence document..................350 1457 ** Initial Messages 1458 (I01) Initial SUBSCRIBE msgs per watcher.....................10 1459 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher............10 1460 (I03) Initial NOTIFY msgs per watcher........................10 1461 (I04) Initial 200 OK msgs (NOTIFY) per watcher...............10 1462 (I05) Total number & bytes of initial SUBSCRIBE msgs 1463 Number of msgs for all watchers.............1,200,000 1464 Bytes for all watchers....................540,000,000 1465 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 1466 Number of msgs for all watchers.............1,200,000 1467 Bytes for all watchers....................444,000,000 1468 (I07) Total number & bytes of initial NOTIFY msgs 1469 Number of msgs for all watchers.............1,200,000 1470 Bytes for all watchers..................1,020,000,000 1471 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 1472 Number of msgs for all watchers.............1,200,000 1473 Bytes for all watchers....................444,000,000 1474 (I09) Total number & bytes of initial messages per day 1475 Number of msgs for all watchers.............4,800,000 1476 Bytes for all watchers..................2,448,000,000 1478 ** Steady State Messages 1479 (S01) NOTIFY msgs due to state change 1480 per watched presentity per day.....................22 1481 (S02) 200 (for NOTIFY due to state change) msgs 1482 per watched presentity per day.....................22 1483 (S03) Total number and size of msgs due to state change per day 1484 Number of msgs for all watchers............52,800,000 1485 Bytes for all watchers.................32,208,000,000 1486 (S04) Number of SUBSCRIBE msgs for refreshes 1487 per watcher per day................................70 1488 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 1489 per watcher per day................................70 1490 (S06) Number of NOTIFY msgs for refreshes 1491 per watcher per day................................70 1492 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1493 per watcher per day................................70 1494 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1495 Number of msgs for all watchers per day....33,600,000 1496 Bytes for all watchers per day.........17,136,000,000 1497 (S09) Total number & bytes of steady messages per day 1498 Number of msgs for all watchers............86,400,000 1499 Bytes for all watchers.................49,344,000,000 1501 ** Termination Messages 1502 (T01) Terminating SUBSCRIBE msgs per watcher.................10 1503 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........10 1504 (T03) Terminating NOTIFY msgs per watcher....................10 1505 (T04) Terminating 200 OK msgs (NOTIFY) per watcher...........10 1506 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1507 Number of msgs for all watchers.............1,200,000 1508 Bytes for all watchers....................540,000,000 1509 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1510 Number of msgs for all watchers.............1,200,000 1511 Bytes for all watchers....................444,000,000 1512 (T07) Total number & bytes of terminating NOTIFY msgs 1513 Number of msgs for all watchers.............1,200,000 1514 Bytes for all watchers..................1,020,000,000 1515 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 1516 Number of msgs for all watchers.............1,200,000 1517 Bytes for all watchers....................444,000,000 1518 (T09) Total number & bytes of terminating messages per day 1519 Number of msgs for all watchers.............4,800,000 1520 Bytes for all watchers..................2,448,000,000 1522 ** Bottom Line 1523 (B01) Total of messages between domains..............96,000,000 1524 Total of bytes between domains (PD=350)....54,240,000,000 1525 Total of bytes between domains (PD=3000)..152,820,000,000 1526 (B02) Total number of messages / second...................3,333 1527 Total of bytes per second (PD=350)..............1,883,333 1528 Total of bytes per second (PD=3000).............5,306,250 1529 B(03 )Total number of by msgs per user/day..................800 1530 Total number of bytes per user/day (PD=350).......452,000 1531 Total number of bytes per user/day (PD=3000)....1,273,500 1533 Figure 9: Intra-domain peering with no optimizations 1535 ** Constants 1536 (C01) Subscription lifetime (hours)...........................8 1537 (C02) Presence state changes / hour...........................3 1538 (C03) Subscription refresh interval / hour....................1 1539 (C04) Total federated presentities per watcher...............10 1540 (C05) Number of dialogs to maintain per watcher...............1 1541 (C06) Total number of watchers in domains...............120,000 1542 (C07) SUBSCRIBE message size in bytes.......................450 1543 (C08) 200 OK for SUBSCRIBE message size in bytes............370 1544 (C09) NOTIFY message size not including presence doc........500 1545 (C10) 200 OK for NOTIFY message size in bytes...............370 1546 (C11) Size of an average presence document..................350 1547 (C13) Additional data per document in RLMI..................160 1548 (C14) Multiparty boundary in RLMI document..................144 1549 (C15) XML root node in RLMI document........................144 1551 ** Initial Messages 1552 (I01) Initial SUBSCRIBE msgs per watcher......................1 1553 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1 1554 (I03) Initial NOTIFY msgs per watcher.........................1 1555 (I04) Initial 200 OK msgs (NOTIFY) per watcher................1 1556 (I05) Total number & bytes of initial SUBSCRIBE msgs 1557 Number of msgs for all watchers...............120,000 1558 Bytes for all watchers.....................54,000,000 1559 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 1560 Number of msgs for all watchers...............120,000 1561 Bytes for all watchers.....................44,400,000 1562 (I07) Total number & bytes of initial NOTIFY msgs 1563 Number of msgs for all watchers...............120,000 1564 Bytes for all watchers....................879,360,000 1565 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 1566 Number of msgs for all watchers...............120,000 1567 Bytes for all watchers.....................44,400,000 1568 (I09) Total number & bytes of initial messages per day 1569 Number of msgs for all watchers...............480,000 1570 Bytes for all watchers..................1,022,160,000 1572 ** Steady State Messages 1573 (S01) NOTIFY msgs due to state change 1574 per watched presentity per day.....................22 1575 (S02) 200 (for NOTIFY due to state change) msgs 1576 per watched presentity per day.....................22 1577 (S03) Total number and size of msgs due to state change per day 1578 Number of msgs for all watchers............52,800,000 1579 Bytes for all watchers.................47,836,800,000 1580 (S04) Number of SUBSCRIBE msgs for refreshes 1581 per watcher per day.................................7 1582 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 1583 per watcher per day.................................7 1584 (S06) Number of NOTIFY msgs for refreshes 1585 per watcher per day.................................0 1586 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1587 per watcher per day.................................0 1588 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1589 Number of msgs for all watchers per day.....1,680,000 1590 Bytes for all watchers per day............688,800,000 1591 (S09) Total number & bytes of steady messages per day 1592 Number of msgs for all watchers............54,480,000 1593 Bytes for all watchers.................48,525,600,000 1595 ** Termination Messages 1596 (T01) Terminating SUBSCRIBE msgs per watcher..................1 1597 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1 1598 (T03) Terminating NOTIFY msgs per watcher.....................1 1599 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............1 1600 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1601 Number of msgs for all watchers...............120,000 1602 Bytes for all watchers.....................54,000,000 1603 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1604 Number of msgs for all watchers...............120,000 1605 Bytes for all watchers.....................44,400,000 1606 (T07) Total number & bytes of terminating NOTIFY msgs 1607 Number of msgs for all watchers.....................0 1608 Bytes for all watchers..............................0 1609 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 1610 Number of msgs for all watchers...............120,000 1611 Bytes for all watchers.....................44,400,000 1612 (T09) Total number & bytes of terminating messages per day 1613 Number of msgs for all watchers...............240,000 1614 Bytes for all watchers.....................98.400,000 1616 ** Bottom Line 1617 (B01) Total of messages between domains..............55,200,000 1618 Total of bytes between domains (PD=350)....49,646,160,000 1619 Total of bytes between domains (PD=3000)..122,796,160,000 1620 (B02) Total number of messages / second...................1,917 1621 Total of bytes per second (PD=350)..............1,723,825 1622 Total of bytes per second (PD=3000).............4,263,408 1623 (B03) Total number of by msgs per user/day..................460 1624 Total number of bytes per user/day (PD=350).......413,718 1625 Total number of bytes per user/day (PD=3000)....1,023,218 1627 Figure 10: Intra-domain peering with optimizations 1629 2.9. Partial Notifications Optimization 1631 RFC 5263 [9] defines a way for the watcher to request getting only 1632 what was changed in the presence document. The following calculation 1633 shows the bandwidth saved in the large peering network case when we 1634 add partial notification to the dialog and NOTIFY optimizations. It 1635 is assumed that, except for the initial NOTIFY, all other NOTIFY 1636 messages will be partial. It is also assumed that only a single 1637 attribute in the presence document will be changed each time, thus 1638 the size of the partial presence document is assumed to be 200 bytes. 1640 ** Constants 1641 (C01) Subscription lifetime (hours)...........................8 1642 (C02) Presence state changes / hour...........................6 1643 (C03) Subscription refresh interval / hour....................1 1644 (C04) Total federated presentities per watcher...............10 1645 (C05) Number of dialogs to maintain per watcher..............10 1646 (C06) Total number of watchers in domains............20,000,000 1647 (C07) SUBSCRIBE message size in bytes.......................450 1648 (C08) 200 OK for SUBSCRIBE message size in bytes............370 1649 (C09) NOTIFY message size not including presence doc........500 1650 (C10) 200 OK for NOTIFY message size in bytes...............370 1651 (C11) Size of an average presence document..................350 1652 (C12) Size of an average partial presence document..........200 1654 ** Initial Messages 1655 (I01) Initial SUBSCRIBE msgs per watcher.....................10 1656 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher............10 1657 (I03) Initial NOTIFY msgs per watcher........................10 1658 (I04) Initial 200 OK msgs (NOTIFY) per watcher...............10 1659 (I05) Total number & bytes of initial SUBSCRIBE msgs 1660 Number of msgs for all watchers...........200,000,000 1661 Bytes for all watchers.................90,000,000,000 1662 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 1663 Number of msgs for all watchers...........200,000,000 1664 Bytes for all watchers..................74,00,000,000 1665 (I07) Total number & bytes of initial NOTIFY msgs 1666 Number of msgs for all watchers...........200,000,000 1667 Bytes for all watchers................170,000,000,000 1668 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 1669 Number of msgs for all watchers...........200,000,000 1670 Bytes for all watchers..................74,000,000,000 1671 (I09) Total number & bytes of initial messages per day 1672 Number of msgs for all watchers...........800,000,000 1673 Bytes for all watchers................408,000,000,000 1675 ** Steady State Messages 1676 (S01) NOTIFY msgs due to state change 1677 per watched presentity per day.....................46 1678 (S02) 200 (for NOTIFY due to state change) msgs 1679 per watched presentity per day.....................46 1680 (S03) Total number and size of msgs due to state change per day 1681 Number of msgs for all watchers........18,400,000,000 1682 Bytes for all watchers..............9,844,000,000,000 1683 (S04) Number of SUBSCRIBE msgs for refreshes 1684 per watcher per day................................70 1685 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 1686 per watcher per day................................70 1687 (S06) Number of NOTIFY msgs for refreshes 1688 per watcher per day.................................0 1689 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1690 per watcher per day.................................0 1691 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1692 Number of msgs for all watchers per day.2,800,000,000 1693 Bytes for all watchers per day......1,148,000,000,000 1694 (S09) Total number & bytes of steady messages per day 1695 Number of msgs for all watchers........21,200,000,000 1696 Bytes for all watchers.............10,992,000,000,000 1698 ** Termination Messages 1699 (T01) Terminating SUBSCRIBE msgs per watcher.................10 1700 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........10 1701 (T03) Terminating NOTIFY msgs per watcher.....................0 1702 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............0 1703 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1704 Number of msgs for all watchers...........200,000,000 1705 Bytes for all watchers.................90,000,000,000 1706 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1707 Number of msgs for all watchers...........200,000,000 1708 Bytes for all watchers.................74,000,000,000 1709 (T07) Total number & bytes of terminating NOTIFY msgs 1710 Number of msgs for all watchers.....................0 1711 Bytes for all watchers..............................0 1712 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 1713 Number of msgs for all watchers.....................0 1714 Bytes for all watchers..............................0 1715 (T09) Total number & bytes of terminating messages per day 1716 Number of msgs for all watchers...........400,000,000 1717 Bytes for all watchers................164.000,000,000 1719 ** Bottom Line 1720 (B01) Total of messages between domains..........22,400,000,000 1721 Total of bytes bet. domains (PD=350)...11,564,000,000,000 1722 Total of bytes bet. domains (PD=3000)..12,094,000,000,000 1723 (B02) Total number of messages / second.................777,778 1724 Total of bytes per second (PD=350)............401,527,778 1725 Total of bytes per second (PD=3000)...........419,930,556 1726 (B03) Total number of by msgs per user/day................1,120 1727 Total number of bytes per user/day (PD=350).......578,200 1728 Total number of bytes per user/day (PD=3000)......604,700 1730 Figure 11: Large networks peering with NOTIFY and partial 1731 optimizations 1733 2.10. Extremely Optimized SIP 1735 SIP is a network-agnostic protocol, therefore, the protocol carries 1736 additional messages like 200 OK that would be redundant in a protocol 1737 that is TCP based only. 1739 The following calculation assumes an imaginary TCP-only version of 1740 SIP that optimizes the following: 1742 o There is no 200 OK for each message. Since only TCP would be 1743 supported, there is no need to compensate for network issues. 1744 o There is no refresh for subscriptions. 1745 o There is no NOTIFY upon termination of the subscription. 1746 o The size of each message is smaller since there is no need for the 1747 various header fields that SIP uses for routing, etc. So we need 1748 to assume smaller message sizes while keeping the size of the 1749 presence document the same. 1751 As noted above, the calculations in this document do not assume 1752 offline means of receiving presence information. Therefore, in 1753 addition to the above optimizations, the other optimizations that 1754 were assumed in the document are assumed here also. These includes 1755 partial notifications and the dialog optimizations. The NOTIFY 1756 optimization is not relevant here since there are no refreshes of 1757 subscriptions. 1759 The following is a calculation for the large network peering scenario 1760 assuming an imaginary TCP-only SIP. It is interesting to note that 1761 the dialog optimization does not reduce the number of bytes when 1762 partial notification optimization is applied (on the contrary) due to 1763 the RLMI overhead. 1765 ** Constants 1766 (C01) Subscription lifetime (hours)...........................8 1767 (C02) Presence state changes / hour...........................6 1768 (C03) Subscription refresh interval / hour....................0 1769 (C04) Total federated presentities per watcher...............10 1770 (C05) Number of dialogs to maintain per watcher...............1 1771 (C06) Total number of watchers in domains............20,000,000 1772 (C07) SUBSCRIBE message size in bytes.......................150 1773 (C08) 200 OK for SUBSCRIBE message size in bytes..............0 1774 (C09) NOTIFY message size not including presence doc........150 1775 (C10) 200 OK for NOTIFY message size in bytes.................0 1776 (C11) Size of an average presence document..................350 1777 (C12) Size of an average partial presence document..........200 1779 ** Initial Messages 1780 (I01) Initial SUBSCRIBE msgs per watcher......................1 1781 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............0 1782 (I03) Initial NOTIFY msgs per watcher.........................1 1783 (I04) Initial 200 OK msgs (NOTIFY) per watcher................0 1784 (I05) Total number & bytes of initial SUBSCRIBE msgs 1785 Number of msgs for all watchers............20,000,000 1786 Bytes for all watchers..................3,000,000,000 1787 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 1788 Number of msgs for all watchers.....................0 1789 Bytes for all watchers..............................0 1790 (I07) Total number & bytes of initial NOTIFY msgs 1791 Number of msgs for all watchers............20,000,000 1792 Bytes for all watchers................136,680,000,000 1793 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 1794 Number of msgs for all watchers.....................0 1795 Bytes for all watchers..............................0 1796 (I09) Total number & bytes of initial messages per day 1797 Number of msgs for all watchers............40,000,000 1798 Bytes for all watchers................139,680,000,000 1800 ** Steady State Messages 1801 (S01) NOTIFY msgs due to state change 1802 per watched presentity per day.....................46 1803 (S02) 200 (for NOTIFY due to state change) msgs 1804 per watched presentity per day......................0 1805 (S03) Total number and size of msgs due to state change per day 1806 Number of msgs for all watchers.........9,200,000,000 1807 Bytes for all watchers..............8,666,400,000,000 1808 (S04) Number of SUBSCRIBE msgs for refreshes 1809 per watcher per day.................................0 1810 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 1811 per watcher per day.................................0 1812 (S06) Number of NOTIFY msgs for refreshes 1813 per watcher per day.................................0 1814 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1815 per watcher per day.................................0 1816 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1817 Number of msgs for all watchers per day.............0 1818 Bytes for all watchers per day......................0 1819 (S09) Total number & bytes of steady messages per day 1820 Number of msgs for all watchers.........9,200,000,000 1821 Bytes for all watchers..............8,666,400,000,000 1823 ** Termination Messages 1824 (T01) Terminating SUBSCRIBE msgs per watcher..................1 1825 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........0 1826 (T03) Terminating NOTIFY msgs per watcher.....................0 1827 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............0 1828 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1829 Number of msgs for all watchers............20,000,000 1830 Bytes for all watchers..................3,000,000,000 1831 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1832 Number of msgs for all watchers.....................0 1833 Bytes for all watchers..............................0 1834 (T07) Total number & bytes of terminating NOTIFY msgs 1835 Number of msgs for all watchers.....................0 1836 Bytes for all watchers..............................0 1837 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 1838 Number of msgs for all watchers.....................0 1839 Bytes for all watchers..............................0 1840 (T09) Total number & bytes of terminating messages per day 1841 Number of msgs for all watchers............20,000,000 1842 Bytes for all watchers..................3,000,000,000 1844 ** Bottom Line 1845 (B01) Total of messages between domains...........9,260,000,000 1846 Total of bytes between domains (PD=350).8,809,080,000,000 1847 Total of bytes bet. domains (PD=3000)...9,339,080,000,000 1848 (B02) Total number of messages / second.................321,528 1849 Total of bytes per second (PD=350)............305,870,833 1850 Total of bytes per second (PD=3000)...........324,273,611 1851 (B03) Total number of by msgs per user/day..................463 1852 Total number of bytes per user/day (PD=350).......440,454 1853 Total number of bytes per user/day (PD=3000)......466,954 1855 Figure 12: Large networks peering, TCP only SIP+Partial+Dialog 1856 optimizations 1858 ** Constants 1859 (C01) Subscription lifetime (hours)...........................8 1860 (C02) Presence state changes / hour...........................6 1861 (C03) Subscription refresh interval / hour....................0 1862 (C04) Total federated presentities per watcher...............10 1863 (C05) Number of dialogs to maintain per watcher..............10 1864 (C06) Total number of watchers in domains............20,000,000 1865 (C07) SUBSCRIBE message size in bytes.......................150 1866 (C08) 200 OK for SUBSCRIBE message size in bytes..............0 1867 (C09) NOTIFY message size not including presence doc........150 1868 (C10) 200 OK for NOTIFY message size in bytes.................0 1869 (C11) Size of an average presence document..................350 1870 (C12) Size of an average partial presence document..........200 1872 ** Initial Messages 1873 (I01) Initial SUBSCRIBE msgs per watcher.....................10 1874 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............0 1875 (I03) Initial NOTIFY msgs per watcher........................10 1876 (I04) Initial 200 OK msgs (NOTIFY) per watcher................0 1877 (I05) Total number & bytes of initial SUBSCRIBE msgs 1878 Number of msgs for all watchers...........200,000,000 1879 Bytes for all watchers.................30,000,000,000 1880 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 1881 Number of msgs for all watchers.....................0 1882 Bytes for all watchers..............................0 1884 (I07) Total number & bytes of initial NOTIFY msgs 1885 Number of msgs for all watchers...........200,000,000 1886 Bytes for all watchers................100,000,000,000 1887 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 1888 Number of msgs for all watchers.....................0 1889 Bytes for all watchers..............................0 1890 (I09) Total number & bytes of initial messages per day 1891 Number of msgs for all watchers...........400,000,000 1892 Bytes for all watchers................130,000,000,000 1894 ** Steady State Messages 1895 (S01) NOTIFY msgs due to state change 1896 per watched presentity per day.....................46 1897 (S02) 200 (for NOTIFY due to state change) msgs 1898 per watched presentity per day......................0 1899 (S03) Total number and size of msgs due to state change per day 1900 Number of msgs for all watchers.........9,200,000,000 1901 Bytes for all watchers..............3,220,000,000,000 1902 (S04) Number of SUBSCRIBE msgs for refreshes 1903 per watcher per day.................................0 1904 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 1905 per watcher per day.................................0 1906 (S06) Number of NOTIFY msgs for refreshes 1907 per watcher per day.................................0 1908 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1909 per watcher per day.................................0 1910 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1911 Number of msgs for all watchers per day.............0 1912 Bytes for all watchers per day......................0 1913 (S09) Total number & bytes of steady messages per day 1914 Number of msgs for all watchers.........9,200,000,000 1915 Bytes for all watchers..............3,220,000,000,000 1917 ** Termination Messages 1918 (T01) Terminating SUBSCRIBE msgs per watcher.................10 1919 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........0 1920 (T03) Terminating NOTIFY msgs per watcher.....................0 1921 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............0 1922 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1923 Number of msgs for all watchers...........200,000,000 1924 Bytes for all watchers.................30,000,000,000 1925 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1926 Number of msgs for all watchers.....................0 1927 Bytes for all watchers..............................0 1928 (T07) Total number & bytes of terminating NOTIFY msgs 1929 Number of msgs for all watchers.....................0 1930 Bytes for all watchers..............................0 1931 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 1932 Number of msgs for all watchers.....................0 1933 Bytes for all watchers..............................0 1934 (T09) Total number & bytes of terminating messages per day 1935 Number of msgs for all watchers...........200,000,000 1936 Bytes for all watchers.................30,000,000,000 1938 ** Bottom Line 1939 (B01) Total of messages between domains...........9,800,000,000 1940 Total of bytes between domains (PD=350).3,380,000,000,000 1941 Total of bytes bet. domains (PD=3000)...3,910,280,000,000 1942 (B02) Total number of messages / second.................340,278 1943 Total of bytes per second (PD=350)............117,361,111 1944 Total of bytes per second (PD=3000)...........135,763,889 1945 (B03) Total number of by msgs per user/day..................490 1946 Total number of bytes per user/day (PD=350).......169,000 1947 Total number of bytes per user/day (PD=3000)......195,500 1949 Figure 13: Large networks peering, TCP only SIP+Partial optimizations 1951 3. State Management 1953 In previous sections, we discussed the large number of messages that 1954 need to be sent to/from a presence server. In this section, we will 1955 analyze the state that needs to be maintained by a presence server 1956 and will show it to be far from trivial. 1958 The presence server has two parallel tasks: 1960 1. Maintain the state of the presentities to which watchers 1961 subscribe. 1962 2. Maintain the state of the subscriptions of watchers and provide 1963 timely updates to the watchers. 1965 For a single subscription from a single watcher on a presentity, the 1966 presence server has to maintain the following state: 1968 o Subscription state including all the parameters that are needed to 1969 maintain the subscription as timers. 1970 o Optional filtering information that was requested by the watcher, 1971 which includes information needed for filtering. If partial 1972 notification is supported for the subscription, additional 1973 information has to be maintained. 1974 o Optional rate management information as throttling. 1975 o Watcher information [10], [11] that is the result of the 1976 subscription in order to enable watched presentities to know who 1977 is watching them. 1979 For each presentity with subscriptions in the presence server, the 1980 presence server has to maintain the following state: 1982 o A list of the subscriptions for the presentity. Note that the 1983 size calculation is already handled by the subscription state 1984 above. 1985 o Authorization information for the presentity. 1987 For each presentity that has published a state other than a default 1988 value, the presence server has to maintain the current value of the 1989 presentity's state. 1991 3.1. State Size Calculations 1993 Lets assume the following sizes: 1995 o Subscription size - 2K bytes. This includes watcher information 1996 that the presence server creates for each subscription. This is 1997 for every subscription created by a watcher to each presentity 1998 that the watcher is watching. So, if we have 10K watchers, we 1999 should have 10K of these. 2000 o Subscribed to resource - 1K bytes for privacy information and 2001 other management information. This is for each watched presentity 2002 regardless of the number of its watchers. The subscriptions 2003 themselves are already calculated in the previous bullet. 2004 o Resource with a state - 6K bytes. This is a moderate assumption 2005 if we consider the amount of data, including calendar and 2006 geographical information, placed in a presence document by 2007 multiple devices. This is for each presentity, watched or not, 2008 that has state other than the default empty state. 2010 3.1.1. Tiny System 2012 o 10K subscriptions = 19M bytes. 2013 o 5K subscribed to presentities = 5M bytes. 2014 o 10K presentities with state = 58M bytes. 2016 Total is 82M bytes. 2018 3.1.2. Medium System 2020 o 100K subscriptions = 195M bytes. 2021 o 50K subscribed to presentities = 49M bytes. 2022 o 100K presentities with state = 586M bytes. 2024 Total is 830M bytes. 2026 3.1.3. Large System 2028 o 6M subscriptions = 11,718M bytes. 2029 o 3M subscribed to presentities = 2,929M bytes. 2030 o 4M presentities with state = 23,437M bytes. 2032 Total is 38G bytes. 2034 3.1.4. Larger System 2036 o 150M subscriptions = 292,969M bytes. 2037 o 75M subscribed to presentities = 73,242M bytes. 2038 o 100M presentities with state = 585,937M bytes. 2040 Total is 952G bytes, which is a large number for dynamic storage as 2041 needed by the presence server. 2043 Although the numbers above may seem moderate enough for the sizes 2044 that the presence server is handling, we should consider the 2045 following: 2047 o Dynamic state - Although the state may not seem so large for 2048 databases even for the larger system, we need to remember that 2049 this state is dynamic. Subscriptions come and go all the time, 2050 the statuses of presentities are being updated, and so forth. 2051 This means that the presence server has to manage its state in a 2052 dynamic medium, and for such large sizes, this task is not 2053 trivial. 2054 o Interlinked state - The subscriptions and the subscribed-to 2055 presentities are dependent on each other. There needs to be a 2056 link from the presentity to the subscriptions and vice versa. See 2057 Section 4.5 about the interlinkage that is created due to resource 2058 lists. 2059 o Moderate assumptions - The size assumptions that were made above 2060 are quite moderate. Presence is becoming more a core middleware 2061 functionality that holds much of the user's data. In real life, 2062 the numbers above may be even higher, and the presence server can 2063 have additional overhead such as managing the SIP sessions, 2064 networking, and more. 2066 Although the above calculations do not show that there is a real 2067 issue with state management of presence in medium systems or even in 2068 large systems since state could be divided among different machines, 2069 the state size is still large. A bigger issue with the state 2070 involves resource lists, which create an interlinked state between 2071 many servers. In that case, the division of large state to multiple 2072 servers becomes less trivial. 2074 4. Processing complexities 2076 The basic presence paradigm comprises a watcher and a presentity to 2077 which the watcher watches. It sounds simple enough, but the presence 2078 server has to manage many additions and extensions, which makes 2079 processing complex. 2081 In this section, we show that, in addition to the large number of 2082 messages and the large state that the presence server has to handle, 2083 it also has to handle quite intensive processing for aggregation, 2084 partial notification and publish, filtering, and privacy. This adds 2085 complexity to the presence server on the CPU front in addition to the 2086 network and memory fronts that were described before. 2088 4.1. Aggregation 2090 A presence document may contain multiple resources. These resources 2091 can be devices of the presentity, information from external providers 2092 of presence information such as geographical location, calendars, and 2093 more. 2095 The presence server needs to receive the updates from all the 2096 resources and to aggregate them correctly into a single presence 2097 document. Although this is just a "XML processing" task, the number 2098 of updates that the presence server may receive, the need to keep the 2099 presence document aligned with its schema, and the need to notify the 2100 users as soon as possible create a significant processing burden on 2101 the presence server. 2103 4.2. Partial Publish and Notify 2105 Partial notification [9] and partial publish [12] define a way for 2106 the watcher to request notification only on what was changed in the 2107 presence document and for the publisher of presence information to 2108 publish only what was changed in the presence document since the last 2109 publish. Although these optimizations help reduce the amount of the 2110 data that is sent from/to the presence server, these optimizations 2111 create additional processing burden on the presence server. 2113 When a partial publish arrives at the presence server, the presence 2114 server has to be able to process the partial publish, and change only 2115 what is indicated in the partial publish while keeping the presence 2116 document well-formed according to the schema. 2118 In partial notification, the processing is even more complex since 2119 each watcher needs to get the partial update based on the last update 2120 that was received by that watcher. Therefore, [9] specifies a 2121 versioning mechanism that enables the watcher to get the updates 2122 based on the previous state that it has seen. This versioning 2123 mechanism has to be maintained by the presence server for each 2124 watcher that is subscribed to a presentity and requires partial 2125 notification. 2127 4.3. Filtering 2129 Filtering as defined in RFCs [13], [14] enables a watcher to request 2130 to be notified only when the presence document fulfills certain 2131 conditions. Although this is a convenient feature for watchers, the 2132 burden put on the presence server is quite large. For each change in 2133 the presence document, the presence server needs to compute the 2134 filtering expressions, which can be complex, and to decide whether 2135 and what to send to the watcher that has requested filtering. 2137 4.4. Authorization 2139 RFC [15] defines presence authorization rules that allow presentities 2140 to specify what each watcher can see in their presence documents. 2141 The processing that the presence server performs here is similar to 2142 filtering. When a presence document with defined authorization rules 2143 changes, the presence server creates different notifications for 2144 different watchers according to those rules. 2146 4.5. Resource List Service 2148 RFC [4] defines a way to subscribe to a single URI that represents a 2149 list of resources that are subscribed to by a single subscription. 2150 Although this quite useful mechanism significantly reduces the number 2151 of sessions between the watcher and the presence server (as we show 2152 in the calculations of messages), this feature has the potential to 2153 complicate the scaling of presence systems. 2155 The reasons that resource lists may make the scaling of the presence 2156 server even more complex are: 2158 o Subscriptions and state - The resource list may contain references 2159 to many other presence servers in many other domains. This 2160 requires the RLS to create subscriptions to other presence servers 2161 and buffer the state of all presentities so that it can provide 2162 the full state of the presentities in the list when needed. So in 2163 the overall system, the number of subscriptions reduced between 2164 the watcher and the presence server is moved to the backend system 2165 while state is duplicated between the various presence servers 2166 that serve the various presentities and the RLSs. This issue 2167 could have been mitigated if there was a way for the RLS to 2168 retrieve the presence information for many watchers while adhering 2169 to privacy when sending the actual notifications to the watchers. 2171 o Interlinkage - The resource list subscription will reach one RLS 2172 that will open it and send it to many presence servers and to 2173 other RLSs (if there is a subgroup inside the list). This creates 2174 a complex linkage between the state of many components. This 2175 linkage makes state management and other maintenance of a presence 2176 systems quite complex. 2177 o Big lists are easy - There are two types of groups that may be 2178 used with this feature: private groups that are defined by/for 2179 each watcher, and public groups that are defined in the system and 2180 can be used by any watcher. Although we should expect IT 2181 administrators to be cautious when creating public groups, this 2182 may be not the case in real life. The connection between the size 2183 of the public group and the load on the presence system may not be 2184 apparent to everyone. Furthermore, many public groups may have 2185 been created for other purposes, such as email systems (where the 2186 size of the lists is not as important), and are now used in the 2187 presence systems. For example, a public group including all the 2188 users in the enterprise is used by many users in the enterprise, 2189 thus overwhelming the presence server. Note that this is not a 2190 protocol or design issue, but more a usage issue that may have a 2191 real impact on the presence system. 2192 o Stopping notifications - A watcher may accidentally subscribe to 2193 an extensive list and be overwhelmed by the number of NOTIFYs that 2194 it receives from the presence server. There is no current way to 2195 stop this stream of NOTIFYs, and even canceling the subscription 2196 may take time before being effective. 2198 These issues show how an optimization can help in one part of the 2199 system but create even bigger problems in the overall system. There 2200 is a need to think about the problems listed above, but, more than 2201 that, there is a need to make sure that introducing an optimization 2202 does not create issues in other places. 2204 5. Current Optimizations 2206 This section highlights several optimizations that are either already 2207 part of SIP or they have been suggested in various drafts. Several 2208 other optimizations that have been suggested but have not been 2209 discussed in any working group yet are summarized in [2] and in [3]. 2210 Note that trials with batched NOTIFYs optimization, described in [2], 2211 showed an improvement of 117% in the whole throughput of presence 2212 traffic. 2214 o Subnot-etags - Draft [6]. This draft suggests ways to suppress 2215 the sending of unnecessary NOTIFYs when, for example, a 2216 subscription is refreshed. This suggestion seems to be an 2217 efficient optimization since it both reduces the number of 2218 messages sent and the processing time of the presence server. 2219 o Resource List Service - [4] enables creating a single subscription 2220 session between the watcher and the presence server for 2221 subscribing to a list of users. This reduces the number of 2222 sessions that are created between watchers and presence servers. 2223 However, this mechanism enables creating large numbers of 2224 subscriptions in the presence server/RLS system, thus enabling the 2225 creation of a large number of subscriptions between presence 2226 servers and RLSs with relatively few clients especially if large 2227 public groups are used. It seems that, in order to really 2228 optimize in this area, the usage of large public groups should not 2229 be considered as BCP, and there should be a way for an RLS to 2230 create a single subscription for multiple occurrences of the same 2231 resource in resource lists. See consolidated subscriptions below. 2232 o Partial notify/publish - RFCs [9] and [12] define a way for the 2233 subscriber to request getting only what was changed in the 2234 presence document and for the publisher of presence information to 2235 publish only what was changed in the presence document since the 2236 last publish. Although these optimizations reduce the amount of 2237 actual data sent from/to the presence server, these optimizations 2238 create additional processing burden on the presence server as was 2239 discussed above. 2240 o Filtering as defined in RFCs [13], [14] enables a watcher to 2241 request to be notified only when the presence document fulfills 2242 certain conditions. Although this optimization reduces the number 2243 of messages that are sent from the presence server to the watcher, 2244 this optimization burdens the processing time of the presence 2245 server as was discussed above. 2246 o Throttling [16] defines a mechanism by which a watcher requests 2247 updates only at certain intervals. Although this mechanism may 2248 add some extra load on the presence server, that load is 2249 negligible and the reduction of the number of messages sent from 2250 the presence server to the watchers is significant. This 2251 optimization is even more important with resource lists, which can 2252 contain many resources, since the watcher may receive a large 2253 number of notifications if the traffic caused by updates on 2254 resource list is not regulated. 2255 o Presence specific SigComp dictionary [17] defines a SigComp [18] 2256 dictionary for presence. This optimization reduces the number of 2257 bytes that are transferred in presence systems by compressing the 2258 textual SIP messages. By using the specialized presence 2259 dictionary, the compression may be more significant than just 2260 using SigComp as-is. Note that number of actual messages will 2261 remain the same, and a calculation of the number of bytes that 2262 will be saved may be useful here. 2263 o Content Indirection [19] enables the sending of only the URI of 2264 the presence document to the watcher, thus relieving the presence 2265 server from sending the presence document to the watcher. This 2266 optimization may be useful in some cases, especially when a large 2267 number of users receive the same presence document. 2269 6. Summary 2271 The following summary of the various calculations is provided here to 2272 help support the conclusions listed below. 2274 The following table summarizes the constants that are used in ALL 2275 calculations: 2277 (C01) Subscription lifetime (hours)...........................8 2278 (C03) Subscription refresh interval / hour....................1 2279 (C05) Number of dialogs to maintain per watcher = Number of 2280 federated presentities when dialog optimization is 2281 not used and to 1 when dialog optimization is used. 2282 (C07) SUBSCRIBE message size in bytes.......................450 2283 (C08) 200 OK for SUBSCRIBE message size in bytes............370 2284 (C09) NOTIFY message size not including presence doc........500 2285 (C10) 200 OK for NOTIFY message size in bytes...............370 2286 (C11) Size of an average presence document..........350 or 3000 2287 Calculations are done for both sizes 2288 (C12) Size of an average partial presence document..........200 2289 (C13) Additional data per document in RLMI..................160 2290 (C14) Multiparty boundary in RLMI document..................144 2291 (C15) XML root node in RLMI document........................144 2293 Figure 14: Constants in ALL calculations 2295 The following table summarizes the results of various optimization 2296 factors for the basic use case. 2298 C02 Presence state changes / hour.............................3 2299 C04 Total federated presentities per watcher..................4 2300 C06 Total # of watchers in the federated domains.........40,000 2302 No optimizations are applied 2304 (B01) Total of messages between domains..............12,800,000 2305 Total of bytes between domains (PD=350).....7,232,000,000 2306 Total of bytes between domains (PD=3000)...20,376,000,000 2307 (B02) Total number of messages / second.. ..................444 2308 Total of bytes per second (PD=350)................251,111 2309 Total of bytes per second (PD=3000)...............707,500 2310 (B03) Total number of by msgs per user/day......... ........320 2311 Total number of bytes per user/day (PD=350).......180,800 2312 Total number of bytes per user/day (PD=3000)......509,400 2314 Dialog optimization is applied 2316 (B01) Total of messages between domains...............8,480,000 2317 Total of bytes between domains (PD=350).....8,032,080,000 2318 Total of bytes between domains (PD=3000)...21,176,080,000 2319 (B02) Total number of messages / second.....................294 2320 Total of bytes per second (PD=350)................278,892 2321 Total of bytes per second (PD=3000)...............735,281 2322 (B03) Total number of by msgs per user/day..................212 2323 Total number of bytes per user/day (PD=350).......200,802 2324 Total number of bytes per user/day (PD=3000)......529,042 2326 Notify optimization is applied 2328 (B01) Total of messages between domains..............10,240,000 2329 Total of bytes between domains (PD=350).....5,670,400,000 2330 Total of bytes between domains (PD=3000)...15,422,400,000 2331 (B02) Total number of messages / second.....................356 2332 Total of bytes per second (PD=350)................196,889 2333 Total of bytes per second (PD=3000)...............535,500 2334 (B03) Total number of by msgs per user/day..................256 2335 Total number of bytes per user/day (PD=350).......141,760 2336 Total number of bytes per user/day (PD=3000)......385,560 2338 Dialog and notify optimizations are applied 2340 (B01) Total of messages between domains...............7,840,000 2341 Total of bytes between domains (PD=350).....6,824,400,000 2342 Total of bytes between domains (PD=3000)...16,576,400,000 2343 (B02) Total number of messages / second.....................272 2344 Total of bytes per second (PD=350)................236,958 2345 Total of bytes per second (PD=3000)...............575,569 2346 (B03) Total number of by msgs per user/day..................196 2347 Total number of bytes per user/day (PD=350).......170,610 2348 Total number of bytes per user/day (PD=3000)......414,410 2350 Figure 15: Basic use case 2352 The following table summarizes the results of various optimization 2353 factors for the widely distributed inter-domain use case. 2355 C02 Presence state changes / hour.............................3 2356 C04 Total federated presentities per watcher.................20 2357 C06 Total # of watchers in the federated domains.........40,000 2359 No optimizations are applied 2361 (B01) Total of messages between domains..............64,000,000 2362 Total of bytes between domains (PD=350)....36,160,000,000 2363 Total of bytes between domains (PD=3000)..101,880,000,000 2364 (B02) Total number of messages / second...................2,222 2365 Total of bytes per second (PD=350)..............1,255,556 2366 Total of bytes per second (PD=3000).............3,537,500 2367 (B03) Total number of by msgs per user/day................1,600 2368 Total number of bytes per user/day (PD=350).......904,000 2369 Total number of bytes per user/day (PD=3000).....,547,000 2371 Dialog and notify optimizations are applied 2373 (B01) Total of messages between domains..............36,000,000 2374 Total of bytes between domains (PD=350)....32,755,920,000 2375 Total of bytes between domains (PD=3000)...81,515,920,000 2376 (B02) Total number of messages / second...................1,250 2377 Total of bytes per second (PD=350)..............1,137,358 2378 Total of bytes per second (PD=3000).............2,830,414 2379 (B03) Total number of by msgs per user/day..................900 2380 Total number of bytes per user/day (PD=350).......818,898 2381 Total number of bytes per user/day (PD=3000)....2,037,898 2383 Figure 16: Widely distributed inter-domain 2385 The following table summarizes the results of various optimization 2386 factors for the intra-domain peering use case. 2388 C02 Presence state changes / hour.............................3 2389 C04 Total federated presentities per watcher.................10 2390 C06 Total # of watchers in the federated domains........120,000 2392 No optimizations are applied 2394 B01 Total of messages between domains................96,000,000 2395 Total of bytes between domains (PD=350)........54,240,000,000 2396 Total of bytes between domains (PD=3000)......152,820,000,000 2397 B02 Total number of messages / second.....................3,333 2398 Total of bytes per second (PD=350)..................1,883,333 2399 Total of bytes per second (PD=3000).................5,306,250 2400 B03 Total number of by msgs per user/day....................800 2401 Total number of bytes per user/day (PD=350)...........452,000 2402 Total number of bytes per user/day (PD=3000)........1,273,500 2404 Dialog and notify optimizations are applied 2406 (B01) Total of messages between domains..............55,200,000 2407 Total of bytes between domains (PD=350)....49,646,160,000 2408 Total of bytes between domains (PD=3000)..122,796,160,000 2409 (B02) Total number of messages / second...................1,917 2410 Total of bytes per second (PD=350)..............1,723,825 2411 Total of bytes per second (PD=3000).............4,263,408 2412 (B03) Total number of by msgs per user/day..................460 2413 Total number of bytes per user/day (PD=350).......413,718 2414 Total number of bytes per user/day (PD=3000)....1,023,218 2416 Figure 17: Inter-domain peering 2418 The following table summarizes the results of various optimization 2419 factors for the large-scale peering networks use case. 2421 C02 Presence state changes / hour.............................6 2422 C04 Total federated presentities per watcher.................10 2423 C06 Total # of watchers in the federated domains.....20,000,000 2425 No optimizations are applied 2427 (B01) Total of messages between domains..........25,600,000,000 2428 Total of bytes bet. domains (PD=350)...14,896,000,000,000 2429 Total of bytes bet. domains (PD=3000)..44,046,000,000,000 2430 (B02) Total number of messages / second.................888,889 2431 Total of bytes per second (PD=350)............517,222,222 2432 Total of bytes per second (PD=3000).........1,529,375,000 2433 (B03) Total number of by msgs per user/day................1,280 2434 Total number of bytes per user/day (PD=350).......744,800 2435 Total number of bytes per user/day (PD=3000)....2,202,300 2437 Dialog and notify optimizations are applied 2439 (B01) Total of messages between domains..........18,800,000,000 2440 Total of bytes bet. domains (PD=350)...16,971,960,000,000 2441 Total of bytes bet. domains (PD=3000)..41,881,960,000,000 2442 (B02) Total number of messages / second.................652,778 2443 Total of bytes per second (PD=350)............589,304,167 2444 Total of bytes per second (PD=3000).........1,454,234,722 2445 (B03) Total number of by msgs per user/day..................940 2446 Total number of bytes per user/day (PD=350).......848,598 2447 Total number of bytes per user/day (PD=3000)....2,094,098 2449 Partial and notify optimizations are applied 2451 (B01) Total of messages between domains..........22,400,000,000 2452 Total of bytes bet. domains (PD=350)...11,564,000,000,000 2453 Total of bytes bet. domains (PD=3000)..12,094,000,000,000 2454 (B02) Total number of messages / second.................777,778 2455 Total of bytes per second (PD=350)............401,527,778 2456 Total of bytes per second (PD=3000)...........419,930,556 2457 (B03) Total number of by msgs per user/day................1,120 2458 Total number of bytes per user/day (PD=350).......578,200 2459 Total number of bytes per user/day (PD=3000)......604,700 2461 TCP only SIP+Partial+Dialog optimizations 2463 (B01) Total of messages between domains...........9,260,000,000 2464 Total of bytes between domains (PD=350).8,809,080,000,000 2465 Total of bytes bet. domains (PD=3000)...9,339,080,000,000 2466 (B02) Total number of messages / second.................321,528 2467 Total of bytes per second (PD=350)............305,870,833 2468 Total of bytes per second (PD=3000)...........324,273,611 2469 (B03) Total number of by msgs per user/day..................463 2470 Total number of bytes per user/day (PD=350).......440,454 2471 Total number of bytes per user/day (PD=3000)......466,954 2473 TCP only SIP+Partial optimizations 2475 (B01) Total of messages between domains...........9,800,000,000 2476 Total of bytes between domains (PD=350).3,380,000,000,000 2477 Total of bytes bet. domains (PD=3000)...3,910,280,000,000 2478 (B02) Total number of messages / second.................340,278 2479 Total of bytes per second (PD=350)............117,361,111 2480 Total of bytes per second (PD=3000)...........135,763,889 2481 (B03) Total number of by msgs per user/day..................490 2482 Total number of bytes per user/day (PD=350).......169,000 2483 Total number of bytes per user/day (PD=3000)......195,500 2484 Figure 18: Large scale peering networks 2486 7. Conclusions 2488 The following conclusions can be drawn from the above numbers: 2490 o Due to the overhead of RLMI, the dialog optimization does not help 2491 reduce the number of bytes nor the number of the messages. It 2492 seems to be more important from the point of view of the user 2493 since it enables convenient management of his/her watch list on, 2494 for example, a web page. 2495 o The notify optimization optimizes both the number of messages and 2496 the number of bytes. 2497 o Partial notification saves a large number of bytes especially when 2498 the presence document is a rich presence document, which is 2499 relatively large. 2500 o Extremely optimized SIP (imaginary TCP-only SIP) cuts the number 2501 of messages by about a half. The number of bytes is also reduced 2502 by about a half. 2503 o From the perspective of the number of bytes that a user "consumes" 2504 per day, the numbers may not look so large. Nevertheless, we 2505 should remember that the overall effect on the network may be 2506 quite large since the network will have to convey dozens of 2507 gigabytes of presence traffic per day for the modest use cases 2508 that are described in this document. Recalling that presence is 2509 only an enabler for other media, these numbers are not so easy to 2510 handle. 2512 The document analyzes the scalability of presence systems in general 2513 and of SIP-based presence systems in particular. It is apparent that 2514 the scalability of these systems is far from being trivial from 2515 several perspectives: number of messages, network bandwidth, state 2516 management, and CPU load. 2518 As part of the analysis, we assessed several optimizations and showed 2519 the effect of these optimizations on the number of messages and the 2520 number of bytes that are sent between the federating domains. 2522 We have also computed the number of messages and bytes for a large- 2523 scale peering network while assuming a protocol that has much less 2524 overhead than SIP. Even with that protocol, we calculated relatively 2525 high numbers. 2527 It is possible that the issues described in this document are 2528 inherent to presence systems in general and not specific to the 2529 SIMPLE protocol. Organizations need to be prepared to invest a lot 2530 in network and hardware in order to create real large systems. 2532 However, it is apparent that not all the possible optimizations were 2533 done yet and further work is needed in the IETF in order to provide 2534 better scalability. 2536 Nevertheless, we should remember that SIP was originally designed for 2537 end-to-end session creation, and that the number and size of messages 2538 are of secondary importance for end-to-end session negotiation. For 2539 large scale and especially for large scale presence, the number of 2540 messages that are needed and the size of each message are of extreme 2541 importance. It seems that we need to think about the problem in a 2542 different way. We need to think about scalability as part of the 2543 protocol design. The IETF tends not to think about actual 2544 deployments when designing a protocol, but in this case it seems that 2545 if we do not think about scalability with the protocol design, it 2546 will be hard to scale. 2548 We should also consider whether using the same protocol between 2549 clients and servers and between servers is a good choice with this 2550 problem. It may be that in interdomain or even between servers in 2551 the same domain (as between RLSs and presence servers) there is a 2552 need to have a different protocol that will be extremely optimized 2553 for the load and that can make some assumptions about the network 2554 (for example, use only TCP, and not an unreliable protocol such as 2555 UDP). 2557 When a server connects to another server using the current protocol, 2558 there will be an extreme number of redundant messages due to the 2559 overhead of supporting UDP and the need to send multiple presence 2560 documents for the same watched user due to privacy issues. A server- 2561 to-server protocol will have to address these issues. Some initial 2562 work to address these issues can be found in [2], [3] and [20] 2564 Another issue that concerns protocol design is whether NOTIFY 2565 messages should not be considered as media like audio, video and even 2566 text messaging are considered. The SUBSCRIBE method can be extended 2567 to create a three-way handshake similar to INVITE and negotiate where 2568 the NOTIFY messages should go, rate, and other parameters. This way, 2569 the load can be shifted to specialized NOTIFY "relays", and taken off 2570 the control path of SIP. One of the possible ideas (Marc Willekens) 2571 is to use the SIP stack for the client/server NOTIFY but make use of 2572 a more optimized and controllable protocol for the server-to-server 2573 interface. Another possibility is to use the MSRP [21], [22]protocol 2574 for the NOTIFYs. 2576 8. Security Considerations 2578 This document discusses scalability issues with the existing SIP/ 2579 SIMPLE presence protocol and model. Therefore, there are no security 2580 considerations to be considered for this document. However, many of 2581 the possible optimizations that should emerge as a result of this 2582 document will have security implications that will need to be solved. 2584 9. IANA Considerations 2586 This document has no actions for IANA. 2588 10. Changes from Previous Versions 2590 10.1. Changes in version 07 2592 Added clarifications, fixed typos and language usage issues raised 2593 during the IETF last call. 2595 10.2. Changes in version 06 2597 Updated to conform with new IETF IPR boilerplate and updated 2598 references. 2600 10.3. Changes in version 05 2602 o Fixed mistakes in calculations that were found by Victoria 2603 Beltran-Martinez, both relate to dialog optimizations. One 2604 mistake was not including the multipart boundary of the resource 2605 list itself in S03 when dialog optimizations were used. The other 2606 one was assuming in T07 that only a single presentity is returned 2607 in termination in T07 calculation. 2608 o Fixed nits that were referred to me by Robert Sparks 2610 10.4. Changes in version 04 2612 o Fixed mistake in the formula of I07 and S08 (RLMI was not 2613 included). Effect on total number of bytes was infitesimile. 2614 o Fixed mistake in the text of the calculation of number of bytes 2615 for S08 for non dialog optimization. No actual change in number 2616 of bytes since the excel file calculations were done correctly. 2617 o Removed general references throughout the text to "other 2618 protocols". This was done in order to avoid the impression that 2619 the document tries to compare SIP protocol with any other presence 2620 base protocol. 2621 o Several other editorial and clarification changes 2623 10.5. Changes in version 03 2625 o Added some input from real life deployments and input on a test 2626 with batched notifies. 2627 o Added Calculations of messages and bytes per user. 2628 o Calculations are now done both for minimal size of presence 2629 document and for an average size of rich presence document. 2630 o Comparison with other protocol is now done using small, tiny and 2631 rich presence document sizes. 2632 o Removed dialog optimization with partial notification since it is 2633 not relevant 2634 o Fixed a few issues in calculations that were found by Victoria 2635 Beltran-Martinez. 2636 * Added overhead for RLMI for dialog optimizations (list 2637 subscription). This calculation fix actually shows that dialog 2638 optimization is not a real optimization from the point of view 2639 of bytes and number of messages. 2640 * When NOTIFY optimizations are applied no need for final NOTIFY 2641 * The usage of RLS between domains was clarified. 2642 o Significantly enhanced the conclusions section 2643 o Several typo fixes 2645 10.6. Changes in version 02 2647 o Fixed a bug in the calculations. Thanks to Marc Willekens for 2648 finding the bug. 2650 10.7. Changes in version 01 2652 o Clarifications and corrections of the computation model and the 2653 computations. 2654 o Added several more computations to show the influence of different 2655 optimizations. 2656 o The requirements were moved to [1] 2657 o The new suggestions for optimizations were moved to [2] 2659 11. Acknowledgments 2661 We would like to thank Jonathan Rosenberg, Ben Campbell, Robert 2662 Sparks, Markus Isomaki Piotr Boni, David Viamonte, Aki Niemi and 2663 Peter-Saint Andre for ideas and input. Special thanks to Marc 2664 Willekens and Victoria Beltran- Martinez for finding several issues 2665 in the calculations. Additional special thanks to A. Jean Mahoney 2666 and Joel M. Helpern for their dedicated review as part of the IETF 2667 last call. 2669 12. Informational References 2671 [1] Houri, A., Parameswar, S., Aoki, E., Singh, V., and H. 2672 Schulzrinne, "Scaling Requirements for Presence in SIP/SIMPLE", 2673 draft-ietf-sipcore-presence-scaling-requirements-00 (work in 2674 progress), April 2009. 2676 [2] Houri, A., "Scaling Optimizations for Presence in SIP/SIMPLE", 2677 draft-houri-simple-interdomain-scaling-optimizations-00 (work 2678 in progress), July 2007. 2680 [3] Rosenberg, J., Donovan, S., and K. McMurry, "Optimizing 2681 Federated Presence with View Sharing", 2682 draft-ietf-simple-view-sharing-02 (work in progress), 2683 November 2008. 2685 [4] Roach, A., Campbell, B., and J. Rosenberg, "A Session 2686 Initiation Protocol (SIP) Event Notification Extension for 2687 Resource Lists", RFC 4662, August 2006. 2689 [5] Camarillo, G., Roach, A., and O. Levin, "Subscriptions to 2690 Request-Contained Resource Lists in the Session Initiation 2691 Protocol (SIP)", RFC 5367, October 2008. 2693 [6] Niemi, A., "An Extension to Session Initiation Protocol (SIP) 2694 Events for Conditional Event Notification", 2695 draft-ietf-sipcore-subnot-etags-02 (work in progress), 2696 April 2009. 2698 [7] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and 2699 J. Peterson, "Presence Information Data Format (PIDF)", 2700 RFC 3863, August 2004. 2702 [8] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, 2703 "RPID: Rich Presence Extensions to the Presence Information 2704 Data Format (PIDF)", RFC 4480, July 2006. 2706 [9] Lonnfors, M., Costa-Requena, J., Leppanen, E., and H. 2707 Khartabil, "Session Initiation Protocol (SIP) Extension for 2708 Partial Notification of Presence Information", RFC 5263, 2709 September 2008. 2711 [10] Rosenberg, J., "A Watcher Information Event Template-Package 2712 for the Session Initiation Protocol (SIP)", RFC 3857, 2713 August 2004. 2715 [11] Rosenberg, J., "An Extensible Markup Language (XML) Based 2716 Format for Watcher Information", RFC 3858, August 2004. 2718 [12] Niemi, A., Lonnfors, M., and E. Leppanen, "Publication of 2719 Partial Presence Information", RFC 5264, September 2008. 2721 [13] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 2722 Requena, "Functional Description of Event Notification 2723 Filtering", RFC 4660, September 2006. 2725 [14] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 2726 Requena, "An Extensible Markup Language (XML)-Based Format for 2727 Event Notification Filtering", RFC 4661, September 2006. 2729 [15] Rosenberg, J., "Presence Authorization Rules", RFC 5025, 2730 December 2007. 2732 [16] Niemi, A., Kiss, K., and S. Loreto, "Session Initiation 2733 Protocol (SIP) Event Notification Extension for Notification 2734 Rate Control", draft-ietf-sipcore-event-rate-control-00 (work 2735 in progress), May 2009. 2737 [17] Garcia-Martin, M., "The Presence-Specific Static Dictionary for 2738 Signaling Compression (Sigcomp)", RFC 5112, January 2008. 2740 [18] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, 2741 Z., and J. Rosenberg, "Signaling Compression (SigComp)", 2742 RFC 3320, January 2003. 2744 [19] Burger, E., "A Mechanism for Content Indirection in Session 2745 Initiation Protocol (SIP) Messages", RFC 4483, May 2006. 2747 [20] Rosenberg, J., Houri, A., Smyth, C., and F. Audet, "Models for 2748 Intra-Domain Presence and Instant Messaging (IM) Bridging", 2749 draft-ietf-simple-intradomain-federation-03 (work in progress), 2750 March 2009. 2752 [21] Campbell, B., Mahy, R., and C. Jennings, "The Message Session 2753 Relay Protocol (MSRP)", RFC 4975, September 2007. 2755 [22] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the 2756 Message Sessions Relay Protocol (MSRP)", RFC 4976, 2757 September 2007. 2759 Authors' Addresses 2761 Avshalom Houri 2762 IBM 2763 Science Park 2764 Rehovot, 2765 Israel 2767 Email: avshalom@il.ibm.com 2769 Edwin Aoki 2770 AOL LLC 2771 401 Ellis St. 2772 Mountain View, CA 94043 2773 USA 2775 Email: aoki@aol.net 2777 Sriram Parameswar 2778 Microsoft Corporation 2779 One Microsoft Way 2780 Redmond, WA 98052 2781 USA 2783 Email: Sriram.Parameswar@microsoft.com 2785 Tim Rang 2786 Microsoft Corporation 2787 One Microsoft Way 2788 Redmond, WA 98052 2789 USA 2791 Email: timrang@microsoft.com 2793 Vishal Singh 2794 Columbia University 2795 Department of Computer Science 2796 450 Computer Science Building 2797 New York, NY 10027 2798 US 2800 Email: vs2140@cs.columbia.edu 2801 URI: http://www.cs.columbia.edu/~vs2140 2802 Henning Schulzrinne 2803 Columbia University 2804 Department of Computer Science 2805 450 Computer Science Building 2806 New York, NY 10027 2807 US 2809 Phone: +1 212 939 7004 2810 Email: hgs+ecrit@cs.columbia.edu 2811 URI: http://www.cs.columbia.edu/~hgs