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