idnits 2.17.1 draft-ietf-simple-interdomain-scaling-analysis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2832. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2843. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2850. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2856. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 22, 2008) is 5664 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-ietf-sipping-presence-scaling-requirements-01 == Outdated reference: A later version (-08) exists of draft-niemi-sipping-event-throttle-07 == Outdated reference: A later version (-02) exists of draft-ietf-simple-view-sharing-01 == Outdated reference: A later version (-05) exists of draft-ietf-simple-intradomain-federation-01 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 7 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: April 25, 2009 AOL LLC 6 S. Parameswar 7 T. Rang 8 Microsoft Corporation 9 V. Singh 10 H. Schulzrinne 11 Columbia U. 12 October 22, 2008 14 Presence Interdomain Scaling Analysis for SIP/SIMPLE 15 draft-ietf-simple-interdomain-scaling-analysis-05.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on April 25, 2009. 42 Abstract 44 The document analyzes the traffic that is generated due to presence 45 subscriptions between domains. It is shown that the amount of 46 traffic can be extremely big. In addition to the very large traffic 47 the document also analyzes the affects of a large presence system on 48 the memory footprint and the CPU load. Current approved and in work 49 optimizations to the SIP protocol are analyzed with the possible 50 impact on the load. Separate documents contain the requirements for 51 optimizations and suggestions for new optimizations. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Message Load . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.1. Known Optimizations . . . . . . . . . . . . . . . . . . . 5 58 2.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 59 2.3. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 2.3.1. Constants . . . . . . . . . . . . . . . . . . . . . . 8 61 2.3.2. Initial Messages . . . . . . . . . . . . . . . . . . . 10 62 2.3.3. Steady State Messages . . . . . . . . . . . . . . . . 10 63 2.3.4. Termination Messages . . . . . . . . . . . . . . . . . 12 64 2.3.5. Bottom Line . . . . . . . . . . . . . . . . . . . . . 12 65 2.3.6. Rush Hour Calculations . . . . . . . . . . . . . . . . 13 66 2.4. No optimizations used . . . . . . . . . . . . . . . . . . 13 67 2.5. Dialog optimization used . . . . . . . . . . . . . . . . . 15 68 2.6. NOTIFY optimization used . . . . . . . . . . . . . . . . . 17 69 2.7. Dialog & NOTIFY optimizations used . . . . . . . . . . . . 19 70 2.8. Presence Federation Scenarios . . . . . . . . . . . . . . 21 71 2.8.1. Widely distributed inter-domain presence . . . . . . . 22 72 2.8.2. Associated inter-domain presence . . . . . . . . . . . 26 73 2.8.3. Very large network peering . . . . . . . . . . . . . . 27 74 2.8.4. Intra-domain peering . . . . . . . . . . . . . . . . . 31 75 2.9. Partial Notifications Optimization . . . . . . . . . . . . 36 76 2.10. Very Optimized SIP . . . . . . . . . . . . . . . . . . . . 38 77 3. State Management . . . . . . . . . . . . . . . . . . . . . . . 42 78 3.1. State Size Calculations . . . . . . . . . . . . . . . . . 43 79 3.1.1. Tiny System . . . . . . . . . . . . . . . . . . . . . 44 80 3.1.2. Medium System . . . . . . . . . . . . . . . . . . . . 44 81 3.1.3. Large System . . . . . . . . . . . . . . . . . . . . . 44 82 3.1.4. Very Large System . . . . . . . . . . . . . . . . . . 44 83 4. Processing complexities . . . . . . . . . . . . . . . . . . . 45 84 4.1. Aggregation . . . . . . . . . . . . . . . . . . . . . . . 45 85 4.2. Partial Publish and Notify . . . . . . . . . . . . . . . . 46 86 4.3. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 46 87 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 46 88 4.5. Resource List Service . . . . . . . . . . . . . . . . . . 47 89 5. Current Optimizations . . . . . . . . . . . . . . . . . . . . 48 90 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 91 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 55 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 56 93 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 94 10. Changes from Previous Versions . . . . . . . . . . . . . . . . 57 95 10.1. Changes in version 05 . . . . . . . . . . . . . . . . . . 57 96 10.2. Changes in version 04 . . . . . . . . . . . . . . . . . . 57 97 10.3. Changes in version 03 . . . . . . . . . . . . . . . . . . 57 98 10.4. Changes in version 02 . . . . . . . . . . . . . . . . . . 58 99 10.5. Changes in version 01 . . . . . . . . . . . . . . . . . . 58 100 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58 101 12. Informational References . . . . . . . . . . . . . . . . . . . 58 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60 103 Intellectual Property and Copyright Statements . . . . . . . . . . 62 105 1. Introduction 107 The document analyzes the SIP protocol for presence (AKA SIMPLE but 108 SIMPLE is not a different protocol then SIP but the name of the 109 working group). It analyses the traffic that is generated due to 110 presence subscriptions between domains. It is shown that the number 111 of messages and the amount of data can be extremely big. In addition 112 to the very large traffic the document also analysis the affects of a 113 large presence system on the memory footprint and the CPU load. 114 Current approved and in work optimizations to the SIP protocol are 115 analyzed with the possible impact on the load. Another document 116 provides requirements for optimizations [18] while other documents 117 contain suggestions for new optimizations: [19]. [21] 119 This document is intended to be drive work on possible solutions that 120 will make the deployment of a SIP based presence server less 121 challenging task. Deployment of highly scalable presence systems is 122 challenging by its nature and each protocol developers design their 123 own technique for optimizing their protocol. This document does not 124 try to compare between protocols and it is behind the scope of this 125 document. 127 The document discusses the following areas. In each area we try to 128 show the complexity and the load that the presence server has to 129 handle in order to provide its service. 131 o Messages load - By computing the number of messages that are 132 required for connecting presence systems the document shows that 133 the number of messages is very big and it is quite obvious that 134 some optimizations are needed. In addition we also show that the 135 bandwidth required is also very big. 136 o State management - Due to the nature of the service that the 137 presence server provides, the presence server has to manage a 138 relatively big and complex state and some computations are 139 provided in the document. 140 o Processing complexities - The presence server maintains many small 141 objects and has to do frequent operations on these objects. We 142 show that these operations and especially the optimizations that 143 are intended to save on the amount of data that is being sent 144 between watchers and presence servers, are not so simple and may 145 create a very heavy processing load on the presence server. 146 o Groups - Resource List Servers [9] optimize the number of sessions 147 that are created between the watchers and the presence server. On 148 the other hand, this optimization may create an exponential size 149 of subscription due to the unbearable ease of subscribing to large 150 groups. 152 The term presence domain or presence system appears in the document 153 several time. By this term we refer to a SIP based presence server 154 that provides presence subscription and notification services to its 155 users. The system can be a system that is deployed in a small 156 enterprise or in a very large consumer network. 158 2. Message Load 160 Some optimizations are approved or are being defined for the SIP 161 presence protocol, but even with these optimizations a very large 162 number of messages & large bandwidth are needed in order to establish 163 federation between presence systems of large communities. Further 164 thinking is needed in order to make large deployment of presence 165 systems less resource demanding. 167 Note that even though this document talks about inter domain traffic, 168 the introduction of resource list servers (RLSs) [9] introduce very 169 similar traffic pattern in intra-domain and in inter-domain. See 170 detailed discussion on resource lists in Section 4.5. 172 2.1. Known Optimizations 174 The current optimizations that are approved or are approved as 175 working group items in the SIMPLE working group can be divided into 176 two categories: 178 o Dialogs saving optimization - Here we refer to optimizations as 179 the resource list RFC [9] or to the URI list subscriptions draft 180 [16]. These documents define ways to reduce the number of dialogs 181 that are required between the subscriber and the presence system. 183 Note that dialog optimization or RLS usage as it is used in 184 this document refers to the usage of a URI that represents a 185 list of a URI list between domains and not within the same 186 domain. An example is a user Alice in domain example.org that 187 subsides to URI of e.g. external-reps-list at example.com or 188 uses a URI list to subscribe at on her watch list in 189 example.com. Note also that when calculating the traffic that 190 is due to RLS within a domain the traffic between the RLS and 191 the presence agents should also be taken into account. 192 However, since in this document we are mostly dealing with 193 inter- domain traffic, the traffic between the RLS and the 194 presence agents was not taken into account. 195 o 196 Notification optimizations - Here we refer to the optimizations 197 that are suggested in the subnot-etags draft [17]. This draft 198 suggests ways to suppress the sending of unnecessary notifies when 199 for example a subscription is refreshed. There are other drafts 200 that reduce the size of messages as partial notifications or 201 filtering but in this document we mostly care about the amount of 202 messages & bandwidth so the partial optimizations can help a bit 203 in the bandwidth but will not help in the number of messages. 205 In addition to the above optimizations another optimization could 206 have been considered but it is not taken into account in the 207 computations in this document. This optimization is the ability to 208 have some of the presence information received not by the SIP 209 protocol but by offline means as downloading some persistent presence 210 information directly from a web site or by some other offline means. 211 The calculations here are based on the assumption that all data is 212 carried in-bound of the protocol and no optimizations that enable 213 getting the presence information via out bound means are taken into 214 account. These optimizations may improve the number of messages and 215 number of bytes significantly but they are out of scope for this 216 document 218 2.2. Assumptions 220 In the document several assumptions are used regarding size of 221 messages, rate of presence change and more. It should be noted that 222 these assumptions are not directly based on rigorous statistics that 223 was done on actual SIP based deployments of presence systems but more 224 from some experience on other types of presence based systems. 226 The following numbers are given more as examples from real 227 deployments and they are not intended to be complete 229 In a large consumer network we have seen the following patterns: 231 o Approximately 110 users in the watch list in average. 232 o There are approximately 12 billion status changes a day (139k/ 233 second) across the network. Of these, when a proprietary binary 234 protocol is used to convey the status changes the average of the 235 message is about 188 bytes. When SIP NOTIFY is used the average 236 is about 1228 bytes for the message. 237 o The average of logins/logouts in the system is about 2000 logins 238 per second and about 4000 logouts per second. When something 239 happens - either a promotion, contest, or a network hiccup that 240 causes many users to login and logout simultaneously, there are 241 about 20,000 logins per second. 242 o The peak of the instant messages sent is about 50,000 messages per 243 second. 245 In a deployment in enterprises we have seen the following patterns: 247 o Averages watch list size was 200 users. 248 o About half of the registered users were online at peak time 249 o Status change per hour was 2 changes per hour. 250 o The average logins/logouts in the system was about 5 logins per 251 second with additional 15 logins/logouts during start/end of day 252 rush hours. 254 Even though the assumptions in this document are not based on 255 rigorous statistical data the target here is not to analyze specific 256 system but show that even with VERY moderate assumptions (which are 257 even less then the observations mentioned above), the number of 258 messages, the network bandwidth, the required state management and 259 the load on the CPU are very high. Real life systems should have a 260 much bigger scalability challenges. for example the presence state 261 change that we assumed (one presence state change per hour) is maybe 262 one of the most moderate assumptions that we have taken. Experience 263 from consumer networks show that the frequency here is much bigger 264 and especially with the younger generation that use more presence 265 attributes like mood etc.. In an environment where a user may have 266 several devices and other resources for presence information as 267 geographical location and calendar the frequency of presence state 268 changes will be much higher. 270 It is very hard to measure presence load since it is very much 271 dependent on the behavior of users and behavior of users differs a 272 lot. Some users will have a very small number of presentities in 273 their watch list while others may have hundreds if not thousands. 274 Some users will change their state a lot and have many sources of 275 presence information while others may have very small number of 276 changes during the day. In addition the "rush hour" calculations of 277 when the day starts and ends were not included yet in this document. 278 Rush hour differs between different enterprises and is still 279 different in the consumer presence systems. It is very hard if not 280 impossible to take into a static document all the possible 281 combinations. 283 Throughout the calculations certain number of users are assumed for 284 the different models. It does not mean that in actual deployments 285 all the users of the domain actually subscribed to presence documents 286 and/or publish their presence document. Observing actual deployments 287 shows that in the consumer market the number of users that use 288 presence services may be 10 percent or less of the registered users. 289 In the enterprise market numbers tend to be around 50 percent of the 290 actual enterprise registered users. 292 The same is correct for the number for of watched presentities per 293 watcher. if only some percent of the domain users are online at a 294 given time then this number should have been that percentage. 296 However, trying to add this assumption to the calculations will make 297 the calculations more complex then they are since the affect of the 298 watched presentities that are not online will need to be taken into 299 account. This means that empty notify should be sent for those when 300 the subscription is created and there is no updates on them. In 301 order to make the computations less complex (they are complex enough 302 as they are), the number of the watched presentities that is used in 303 the calculations is the number of the federated presentities from the 304 watcher list that are online. 306 2.3. Analysis 308 The basic SIP subscription dialog involves the following message- 309 transfer: 311 o SUBSCRIBE/200 312 o Initial NOTIFY/200 313 o (j) NOTIFY/200 where 'j' is the number of presence changes seen by 314 the watcher 315 o (k) SUBSCRIBE/200 where 'k' is the number of subscription dialog 316 refresh periods 317 o SUBSCRIBE/200 with Expires = 0 to terminate the dialog 318 o NOTIFY/200 ending the dialog 320 An individual watcher will generate X number of SIP subscription 321 dialogs corresponding to the number of presentities it chooses to 322 watch. The amount of traffic generated is significantly affected by 323 several factors: 325 o Number of watchers connected to the system 326 o Number of presentities connected to the system 327 o Frequency of changes to presence information 329 This document contains several calculations that show the expected 330 message rate and bandwidth between presence domains. The following 331 sections explain the assumptions and methods behind the calculations. 333 2.3.1. Constants 335 The following are number of "constants" that we use in the 336 calculations. Some of the constants are used throughout the 337 calculation while other change between use cases 339 o (C01) Subscription lifetime (hours)- The assumed lifetime of a 340 subscription in hours. We assume 8 hours for all calculations. 341 o (C02) Presence state changes / hour - The average time that a 342 presentity changes his/hers status in one hour. We assumed 3 343 times per hour for most calculations. Note that for some users in 344 consumer messaging systems, the actual number of changes is likely 345 to be much higher. 346 o (C03) Subscription refresh interval / hour - The duration of the 347 SUBSCRIBE session after which it needs to be refreshed. We 348 assumed that the duration is one hour. 349 o (C04) Total federated presentities per watcher - The number of 350 presentities that the watcher is watching. The number here 351 changes in this document according to the type of the specific 352 deployment. 353 o (C05) Number of dialogs to maintain per watcher - The number of 354 the SUBSCRIBE dialogs that are maintained per watcher. if a dialog 355 optimization is not assumed this number is equal to A04, otherwise 356 it is 1. 357 o (C06) Total number of watchers in the federated presence domains. 358 The number here is the number of all watchers in all the federated 359 domains. 360 o (C07) SUBSCRIBE message size in bytes. We assume 450 bytes in all 361 calculations. The size is based on a typical SUBSCIRBE taken from 362 RFCs. 363 o (C08) 200 OK for SUBSCRIBE message size in bytes. We assume 370 364 bytes in all calculations. The size is based on a typical 200 OK 365 taken from RFCs. 366 o (C09) NOTIFY message size not including the presence document. 367 The size of this message for a single presentity is assumed to be 368 500 bytes for the NOTIFY message itself (based on sizes from 369 examples in RFCs). 370 o (C10) 200 OK for NOTIFY message size in bytes. We assume 370 371 bytes in all calculations. The size is based on a typical 200 OK 372 taken from RFCs. 373 o (C11) Size of an average presence document. In the previous 374 version of this document we have used only the size of 3000 bytes 375 for a presence document. This number was calculated based on 376 examples of rich presence document in RFCs. Due to discussion in 377 the SIMPLE list where it was claimed that it may be too big and 378 due to the fact that we are talking here about federation between 379 communities where the rich presence document may be of less use, 380 we have done all the calculations with two sizes of presence 381 document. One size is the minimal size of the PIDF [4] document 382 which was taken to be 350 bytes based on examples from RFCs and 383 the other size is the 3000 bytes for rich presence document [5]. 384 It should be noted that assuming 3000 bytes for presence document 385 is relatively modest if we take into account multiple devices and 386 location information. 387 o (C12) The size of NOTIFY when partial [12] notification is being 388 done. We have taken this size to be 200 bytes. The size is much 389 smaller then the example that is given in [12] but the example 390 given there assumes multiple changes in the presence document and 391 here we assume a single change. 393 When dialog optimization [9] is used, an RLMI document is being 394 sent and that document contains the presence documents for the 395 users that are in the watch list. In previous version of this 396 document we have omitted the overhead of the RLMI document. 397 This "bug" was found by Victoria Beltran-Martinez and is being 398 fixed in this document by adding the constants C13, C14 and C15 399 to the calculations 400 o 401 (C13) Item size per each contact in RLMI document, 160 bytes. 402 o (C14) The size of the multipart boundary in RLMI notifications, 403 144 bytes. 404 o (C15) The size of the XML root node in RLMI document (once per 405 notification), 144 bytes. 407 2.3.2. Initial Messages 409 The following are the calculations for the messages in the initial 410 phase of the establishment of the subscriptions. The calculations 411 contain both number of messages and the number of bytes. 413 o (I01) Number of initial SUBSCRIBE messages per watcher = C05. 414 o (I02) Number of initial 200 OK messages for SUBSCRIBE messages per 415 watcher = C05. 416 o (I03) Number of initial NOTIFY messages per watcher = C05. 417 o (I04) Number of initial 200 OK messages for NOTIFY messages per 418 watcher = C05. 419 o (I05) Total number and bytes of initial SUBSCRIBE messages for all 420 watchers = Number - I01*C06, Bytes - I01*C06*C07. 421 o (I06) Total number and bytes of initial 200 OK for SUBSCRIBE 422 messages for all watchers = Number - I01*C06, Bytes - I01*C06*C08. 423 o (I07) Total number and bytes of initial NOTIFY messages for all 424 watchers = Number - I01*C06, The calculation for the number of 425 bytes is different when dialog optimization is used or not. When 426 dialog optimization is not applied the number of bytes will be 427 calculated by: (I01*C06*C09)+(I01*C06*C11) and when dialog 428 optimization is applied the number of bytes will be calculated by 429 (I01*C06*(C09+C14+C15))+(I01*C06*C04*(C11+C13+C14)). 430 o (I08) Total number and bytes of initial 200 OK for NOTIFY messages 431 for all watchers = Number - I04*C06, Bytes - I04*C06*C10. 432 o (I09) Total number and bytes of initial messages per day = Number 433 - numbers in I05+I06+I07+I08, Size -sizes in I05+I06+I07+I08. 435 2.3.3. Steady State Messages 437 Here we describe the calculations for the steady state messages. 438 Steady state is the time between the initial subscription and the 439 tear down of the subscription. It contains the notifies due to state 440 change and the subscription refreshes. 442 o (S01) NOTIFY messages due to state change per watched presentity 443 per day (less 2 since the NOTIFY for initial and terminating state 444 is calculated in the initial and terminating calculations) = 445 (C02*C01-2). 446 o (S02) 200 (for NOTIFY due to state change) messages per watched 447 presentity per day (less 2 since the NOTIFY for initial and 448 terminating state is calculated in the initial and terminating 449 calculations) = (C02*C01-2). 450 o (S03) Total number and size of messages due to state change per 451 day = Number - (S01+S02)*C06*C04. The calculation for the number 452 of bytes is different when dialog optimization is used or not. 453 When dialog optimization is not applied the number of bytes will 454 be calculated by: (C06*C04)*((S01*(C09+C11))+(S02*C10)) and when 455 dialog optimization is applied the number of bytes will be 456 calculated by (C06*C04)*((S01*(C09+C11+C13+C14+C15+C14))+ 457 (S02*C10)). This includes the the multipart boundary of the 458 resource list. Note that for dialog optimization it is assumed 459 that only a single presentity is changed and partial state 460 notification is used. 461 o (S04) Number of SUBSCRIBE messages for refreshes per watcher per 462 day = ((C01/C03)-1)*C05. One is subtracted since the termination 463 is calculated separately. for example if there are 8 hours in the 464 day and a refresh should occur every hour, there are 7 refreshes 465 during the day and not 8. 466 o (S05) Number of 200 OK messages for SUBSCRIBE messages for 467 refreshes per watcher per day = ((C01/C03)-1)*C05. 468 o (S06) Number of NOTIFY messages for refreshes per watcher per day 469 = ((C01/C03)-1)*C05. Since when NOTIFY optimization is used [17] 470 there is no need to send NOTIFY for refreshes, S06 will be zero 471 when NOTIFY optimizations is used. 472 o (S07) Number of 200 OK messages for NOTIFY messages for refreshes 473 per watcher per day = ((C01/C03)-1)*C05. Since when NOTIFY 474 optimization is used [17] there is no need to send NOTIFY for 475 refreshes, S07 will be zero when NOTIFY optimizations is used. 476 o (S08) Total number and size of messages due to SUBSCRIBE refreshes 477 per day = Number - (S04+S05+S06+S07)*C06. The number of bytes is 478 calculated by adding the SUBSCIRBE bytes (S04*C06*C07), the OK for 479 SUBSCRIBE bytes (S05*C06*C08), the NOTIFY bytes C06*(S06*(C09+ 480 C11)) and the OK for NOTIFY (S07*C06*C10). Note that the formula 481 for the notify bytes is for the dialog optimization is not used 482 and when it used the formula will be: C06*(S06*((C09+C14+C15)+ 483 (C04*(C11+C13+C14)))). Note that a full state should be given in 484 SUBSCRIBE refreshes in resource lists. See section 5.2 in [9]. 485 The fact that the full state needs to be returned in a NOTIFY 486 response to refresh makes the NOTIFY optimization more efficient 487 in conjunction with the dialog optimization. 489 o (S09) Total number and bytes of steady messages per day = Number - 490 numbers in S03+S08, Bytes - sizes in S03+S08. 492 2.3.4. Termination Messages 494 The following are the calculations for the messages in the 495 termination phase of the of the subscriptions. The calculations 496 contain both number of messages and the number of bytes. 498 o (T01) Number of terminating SUBSCRIBE messages per watcher = C05. 499 o (T02) Number of terminating 200 OK messages for SUBSCRIBE messages 500 per watcher = C05. 501 o (T03) Number of terminating NOTIFY messages per watcher = C05. 502 Since when NOTIFY optimization is used [17] there is no need to 503 send NOTIFY for terminations, T03 will be zero when NOTIFY 504 optimization is used. 505 o (T04) Number of terminating 200 OK messages for NOTIFY messages 506 per watcher = C05. Since when NOTIFY optimization is used [17] 507 there is no need to send NOTIFY for terminations, T04 will be zero 508 when NOTIFY optimization is used. 509 o (T05) Total number and bytes of terminating SUBSCRIBE messages for 510 all watchers = Number - T01*C06, Bytes - T01*C06*C07. 511 o (T06) Total number and bytes of terminating 200 OK for SUBSCRIBE 512 messages for all watchers = Number - T01*C06, Bytes - T01*C06*C08. 513 o (T07) Total number and bytes of terminating NOTIFY messages for 514 all watchers = Number - T01*C06, The number of bytes is calculated 515 to be: (T03*C06*(C09+C11) when dialog optimization is not used 516 and: (T03*C06*(C09+C14+C15))+(T03*C06*C04*(C11+C13+C14)) when 517 dialog optimization is used. Note that a full state should be 518 given in SUBSCRIBE refreshes in resource lists. See section 5.2 519 in [9]. 520 o (T08) Total number and bytes of terminating 200 OK for NOTIFY 521 messages for all watchers = Number - T04*C06, Bytes - T04*C06*C10. 522 o (T09) Total number and bytes of terminating messages per day = 523 Number - numbers in T05+T06+T07+T08, Size -sizes in T05+T06+T07+ 524 T08. 526 2.3.5. Bottom Line 528 The following are the calculations of several totals that are based 529 on the above calculations. 531 o (B01) Total number of messages and bytes during the day = Messages 532 - Number of messages in I09+S09+T09, Bytes - Number of bytes in 533 I09+S09+T09. 534 o (B02) Total number of messages and bytes per second = Messages - 535 Number of messages in B01/(C01*3600) Bytes - Number of bytes in 536 B01/(C01*3600). 538 o (B02) Total number of message and bytes per user per day = 539 Messages - number of messages in B01/C06 Bytes - Number of bytes 540 in B01/C06. 542 2.3.6. Rush Hour Calculations 544 With the way that the calculations are built, it is relatively easy 545 to see the affect of rush hours at the beginning and the end of the 546 day. for the beginning of the day we should look at the numbers of 547 "(I09) Total number and bytes of initial messages per day" and for 548 the end of the day we should look at the number of "(T09) Total 549 number and bytes of terminating messages per day". Taking these 550 numbers with some assumed percentage of the numbers of users that log 551 in at the same hour should give good indication for the rush hour 552 load. 554 2.4. No optimizations used 556 The following table uses some common presence characteristics to 557 demonstrate the effect these factors have on state and message rate 558 within a presence domain using base SIP protocols without any 559 proposed optimizations. In this example, there are two presence 560 domains with total of 40,000 federating users with an average of 4 561 contacts in the peer domain. Note that the main calculation is done 562 for a presence document size of 350 bytes which is the base PIDF [4] 563 document size but the bottom line calculation is also given for a 564 presence document size for rich presence [5] which is assumed to be 565 3000 bytes based on the examples given in the RFCs. This two folded 566 calculation is done for every use case in this document. 568 ** Constants 569 (C01) Subscription lifetime (hours)...........................8 570 (C02) Presence state changes / hour...........................3 571 (C03) Subscription refresh interval / hour....................1 572 (C04) Total federated presentities per watcher................4 573 (C05) Number of dialogs to maintain per watcher...............4 574 (C06) Total number of watchers in domains................40,000 575 (C07) SUBSCRIBE message size in bytes.......................450 576 (C08) 200 OK for SUBSCRIBE message size in bytes............370 577 (C09) NOTIFY message size not including presence doc........500 578 (C10) 200 OK for NOTIFY message size in bytes...............370 579 (C11) Size of an average presence document..................350 581 ** Initial Messages 582 (I01) Initial SUBSCRIBE msgs per watcher......................4 583 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............4 584 (I03) Initial NOTIFY msgs per watcher.........................4 585 (I04) Initial 200 OK msgs (NOTIFY) per watcher................4 586 (I05) Total number & bytes of initial SUBSCRIBE msgs 587 Number of msgs for all watchers...............160,000 588 Bytes for all watchers.....................72,000,000 589 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 590 Number of msgs for all watchers...............160,000 591 Bytes for all watchers.....................59,200,000 592 (I07) Total number & bytes of initial NOTIFY msgs 593 Number of msgs for all watchers...............160,000 594 Bytes for all watchers....................136,000,000 595 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 596 Number of msgs for all watchers...............160,000 597 Bytes for all watchers.....................59,200,000 598 (I09) Total number & bytes of initial messages per day 599 Number of msgs for all watchers...............640,000 600 Bytes for all watchers....................326,400,000 602 ** Steady State Messages 603 (S01) NOTIFY msgs due to state change 604 per watched presentity per day.....................22 605 (S02) 200 (for NOTIFY due to state change) msgs 606 per watched presentity per day.....................22 607 (S03) Total number and size of msgs due to state change per day 608 Number of msgs for all watchers.............7,040,000 609 Bytes for all watchers..................4,294,400,000 610 (S04) Number of SUBSCRIBE msgs for refreshes 611 per watcher per day................................28 612 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 613 per watcher per day................................28 614 (S06) Number of NOTIFY msgs for refreshes 615 per watcher per day................................28 616 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 617 per watcher per day................................28 618 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 619 Number of msgs for all watchers per day.....4,480,000 620 Bytes for all watchers per day..........2,284,800,000 621 (S09) Total number & bytes of steady messages per day 622 Number of msgs for all watchers............11,520,000 623 Bytes for all watchers..................6,579,200,000 625 ** Termination Messages 626 (T01) Terminating SUBSCRIBE msgs per watcher..................4 627 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........4 628 (T03) Terminating NOTIFY msgs per watcher.....................4 629 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............4 630 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 631 Number of msgs for all watchers.............. 160,000 632 Bytes for all watchers.....................72,000,000 633 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 634 Number of msgs for all watchers...............160,000 635 Bytes for all watchers.....................59,200,000 636 (T07) Total number & bytes of terminating NOTIFY msgs 637 Number of msgs for all watchers...............160,000 638 Bytes for all watchers....................136,000,000 639 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 640 Number of msgs for all watchers...............160,000 641 Bytes for all watchers.....................59,200,000 642 (T09) Total number & bytes of terminating messages per day 643 Number of msgs for all watchers...............640,000 644 Bytes for all watchers....................326,400,000 646 ** Bottom Line 647 (B01) Total of messages between domains..............12,800,000 648 Total of bytes between domains (PD=350).....7,232,000,000 649 Total of bytes between domains (PD=3000)...20,376,000,000 650 (B02) Total number of messages / second.. ..................444 651 Total of bytes per second (PD=350)................251,111 652 Total of bytes per second (PD=3000)...............707,500 653 (B03) Total number of by msgs per user/day......... ........320 654 Total number of bytes per user/day (PD=350).......180,800 655 Total number of bytes per user/day (PD=3000)......509,400 657 Figure 1: No optimizations used 659 2.5. Dialog optimization used 661 The same analysis provided above is repeated here with the assumption 662 that the dialog optimization is applied. Note that while the sign-in 663 (ramp up) and sign-out messages flows are positively affected, the 664 steady state rates are not. 666 ** Constants 667 (C01) Subscription lifetime (hours)...........................8 668 (C02) Presence state changes / hour...........................3 669 (C03) Subscription refresh interval / hour....................1 670 (C04) Total federated presentities per watcher................4 671 (C05) Number of dialogs to maintain per watcher...............1 672 (C06) Total number of watchers in domains................40,000 673 (C07) SUBSCRIBE message size in bytes.......................450 674 (C08) 200 OK for SUBSCRIBE message size in bytes............370 675 (C09) NOTIFY message size not including presence doc........500 676 (C10) 200 OK for NOTIFY message size in bytes...............370 677 (C11) Size of an average presence document..................350 678 (C13) Additional data per document in RLMI..................160 679 (C14) Multiparty boundary in RLMI document..................144 680 (C15) XML root node in RLMI document........................144 681 ** Initial Messages 682 (I01) Initial SUBSCRIBE msgs per watcher......................1 683 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1 684 (I03) Initial NOTIFY msgs per watcher.........................1 685 (I04) Initial 200 OK msgs (NOTIFY) per watcher................1 686 (I05) Total number & bytes of initial SUBSCRIBE msgs 687 Number of msgs for all watchers................40,000 688 Bytes for all watchers.....................18,000,000 689 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 690 Number of msgs for all watchers................40,000 691 Bytes for all watchers.....................14,800,000 692 (I07) Total number & bytes of initial NOTIFY msgs 693 Number of msgs for all watchers................40,000 694 Bytes for all watchers....................136,160,000 695 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 696 Number of msgs for all watchers................40,000 697 Bytes for all watchers.....................14,800,000 698 (I09) Total number & bytes of initial messages per day 699 Number of msgs for all watchers...............160,000 700 Bytes for all watchers....................183,760,000 702 ** Steady State Messages 703 (S01) NOTIFY msgs due to state change 704 per watched presentity per day.....................22 705 (S02) 200 (for NOTIFY due to state change) msgs 706 per watched presentity per day.....................22 707 (S03) Total number and size of msgs due to state change per day 708 Number of msgs for all watchers.............7,040,000 709 Bytes for all watchers..................6,378,240,000 710 (S04) Number of SUBSCRIBE msgs for refreshes 711 per watcher per day.................................7 712 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 713 per watcher per day.................................7 714 (S06) Number of NOTIFY msgs for refreshes 715 per watcher per day.................................7 716 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 717 per watcher per day.................................7 718 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 719 Number of msgs for all watchers per day.....1,120,000 720 Bytes for all watchers per day..........1,286,320,000 721 (S09) Total number & bytes of steady messages per day 722 Number of msgs for all watchers.............8,160,000 723 Bytes for all watchers..................7,664,560,000 725 ** Termination Messages 726 (T01) Terminating SUBSCRIBE msgs per watcher..................1 727 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1 728 (T03) Terminating NOTIFY msgs per watcher.....................1 729 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............1 730 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 731 Number of msgs for all watchers................40,000 732 Bytes for all watchers.....................18,000,000 733 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 734 Number of msgs for all watchers................40,000 735 Bytes for all watchers.....................14,800,000 736 (T07) Total number & bytes of terminating NOTIFY msgs 737 Number of msgs for all watchers................40,000 738 Bytes for all watchers....................136,160,000 739 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 740 Number of msgs for all watchers................40,000 741 Bytes for all watchers.....................14,800,000 742 (T09) Total number & bytes of terminating messages per day 743 Number of msgs for all watchers...............160,000 744 Bytes for all watchers....................183,760,000 746 ** Bottom Line 747 (B01) Total of messages between domains...............8,480,000 748 Total of bytes between domains (PD=350).....8,032,080,000 749 Total of bytes between domains (PD=3000)...21,176,080,000 750 (B02) Total number of messages / second.....................294 751 Total of bytes per second (PD=350)................278,892 752 Total of bytes per second (PD=3000)...............735,281 753 (B03) Total number of by msgs per user/day..................212 754 Total number of bytes per user/day (PD=350).......200,802 755 Total number of bytes per user/day (PD=3000)......529,042 757 Figure 2: Dialog optimization used 759 2.6. NOTIFY optimization used 761 The initial analysis of analysis provided in Figure 1 is repeated 762 here with the assumption that the notify optimization is applied. 763 The optimization saves the need for NOTIFY upon refreshing a 764 SUBSCRIBE if there was no change since the last NOTIFY. It is 765 assumed here that there will be no NOTIFY message for a SUBSCRIBE 766 refreshes and terminations. As should be expected this optimization 767 affects the steady and termination state and does not affect the 768 initial state. 770 ** Constants 771 (C01) Subscription lifetime (hours)...........................8 772 (C02) Presence state changes / hour...........................3 773 (C03) Subscription refresh interval / hour....................1 774 (C04) Total federated presentities per watcher................4 775 (C05) Number of dialogs to maintain per watcher...............4 776 (C06) Total number of watchers in domains................40,000 777 (C07) SUBSCRIBE message size in bytes.......................450 778 (C08) 200 OK for SUBSCRIBE message size in bytes............370 779 (C09) NOTIFY message size not including presence doc........500 780 (C10) 200 OK for NOTIFY message size in bytes...............370 781 (C11) Size of an average presence document..................350 783 ** Initial Messages 784 (I01) Initial SUBSCRIBE msgs per watcher......................4 785 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............4 786 (I03) Initial NOTIFY msgs per watcher.........................4 787 (I04) Initial 200 OK msgs (NOTIFY) per watcher................4 788 (I05) Total number & bytes of initial SUBSCRIBE msgs 789 Number of msgs for all watchers...............160,000 790 Bytes for all watchers.....................72,000,000 791 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 792 Number of msgs for all watchers...............160,000 793 Bytes for all watchers.....................59,200,000 794 (I07) Total number & bytes of initial NOTIFY msgs 795 Number of msgs for all watchers...............160,000 796 Bytes for all watchers....................136,000,000 797 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 798 Number of msgs for all watchers...............160,000 799 Bytes for all watchers.....................59,200,000 800 (I09) Total number & bytes of initial messages per day 801 Number of msgs for all watchers...............640,000 802 Bytes for all watchers....................326,400,000 804 ** Steady State Messages 805 (S01) NOTIFY msgs due to state change 806 per watched presentity per day.....................22 807 (S02) 200 (for NOTIFY due to state change) msgs 808 per watched presentity per day.....................22 809 (S03) Total number and size of msgs due to state change per day 810 Number of msgs for all watchers.............7,040,000 811 Bytes for all watchers..................4,294,400,000 812 (S04) Number of SUBSCRIBE msgs for refreshes 813 per watcher per day................................28 814 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 815 per watcher per day................................28 816 (S06) Number of NOTIFY msgs for refreshes 817 per watcher per day.................................0 818 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 819 per watcher per day.................................0 820 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 821 Number of msgs for all watchers per day.....2,240,000 822 Bytes for all watchers per day............918,400,000 823 (S09) Total number & bytes of steady messages per day 824 Number of msgs for all watchers.............9,280,000 825 Bytes for all watchers..................5,212,800,000 827 ** Termination Messages 828 (T01) Terminating SUBSCRIBE msgs per watcher..................4 829 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........4 830 (T03) Terminating NOTIFY msgs per watcher.....................0 831 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............0 832 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 833 Number of msgs for all watchers.............. 160,000 834 Bytes for all watchers.....................72,000,000 835 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 836 Number of msgs for all watchers...............160,000 837 Bytes for all watchers.....................59,200,000 838 (T07) Total number & bytes of terminating NOTIFY msgs 839 Number of msgs for all watchers.....................0 840 Bytes for all watchers..............................0 841 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 842 Number of msgs for all watchers.....................0 843 Bytes for all watchers..............................0 844 (T09) Total number & bytes of terminating messages per day 845 Number of msgs for all watchers...............320,000 846 Bytes for all watchers....................131,200,000 848 ** Bottom Line 849 (B01) Total of messages between domains..............10,240,000 850 Total of bytes between domains (PD=350).....5,670,400,000 851 Total of bytes between domains (PD=3000)...15,422,400,000 852 (B02) Total number of messages / second.....................356 853 Total of bytes per second (PD=350)................196,889 854 Total of bytes per second (PD=3000)...............535,500 855 (B03) Total number of by msgs per user/day..................256 856 Total number of bytes per user/day (PD=350).......141,760 857 Total number of bytes per user/day (PD=3000)......385,560 859 Figure 3: NOTIFY optimization used 861 2.7. Dialog & NOTIFY optimizations used 863 Here both optimizations are combined. In all the subsequent use 864 cases we will show only the analysis with no optimizations and with 865 both optimizations combined. 867 ** Constants 868 (C01) Subscription lifetime (hours)...........................8 869 (C02) Presence state changes / hour...........................3 870 (C03) Subscription refresh interval / hour....................1 871 (C04) Total federated presentities per watcher................4 872 (C05) Number of dialogs to maintain per watcher...............1 873 (C06) Total number of watchers in domains................40,000 874 (C07) SUBSCRIBE message size in bytes.......................450 875 (C08) 200 OK for SUBSCRIBE message size in bytes............370 876 (C09) NOTIFY message size not including presence doc........500 877 (C10) 200 OK for NOTIFY message size in bytes...............370 878 (C11) Size of an average presence document..................350 879 (C13) Additional data per document in RLMI..................160 880 (C14) Multiparty boundary in RLMI document..................144 881 (C15) XML root node in RLMI document........................144 883 ** Initial Messages 884 (I01) Initial SUBSCRIBE msgs per watcher......................1 885 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1 886 (I03) Initial NOTIFY msgs per watcher.........................1 887 (I04) Initial 200 OK msgs (NOTIFY) per watcher................1 888 (I05) Total number & bytes of initial SUBSCRIBE msgs 889 Number of msgs for all watchers................40,000 890 Bytes for all watchers.....................18,000,000 891 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 892 Number of msgs for all watchers................40,000 893 Bytes for all watchers.....................14,800,000 894 (I07) Total number & bytes of initial NOTIFY msgs 895 Number of msgs for all watchers................40,000 896 Bytes for all watchers....................136,160,000 897 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 898 Number of msgs for all watchers................40,000 899 Bytes for all watchers.....................14,800,000 900 (I09) Total number & bytes of initial messages per day 901 Number of msgs for all watchers...............160,000 902 Bytes for all watchers....................183,760,000 904 ** Steady State Messages 905 (S01) NOTIFY msgs due to state change 906 per watched presentity per day.....................22 907 (S02) 200 (for NOTIFY due to state change) msgs 908 per watched presentity per day.....................22 909 (S03) Total number and size of msgs due to state change per day 910 Number of msgs for all watchers.............7,040,000 911 Bytes for all watchers..................6,378,240,000 912 (S04) Number of SUBSCRIBE msgs for refreshes 913 per watcher per day.................................7 914 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 915 per watcher per day.................................7 916 (S06) Number of NOTIFY msgs for refreshes 917 per watcher per day.................................0 918 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 919 per watcher per day.................................0 920 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 921 Number of msgs for all watchers per day.......560,000 922 Bytes for all watchers per day............229,600,000 923 (S09) Total number & bytes of steady messages per day 924 Number of msgs for all watchers.............7,600,000 925 Bytes for all watchers..................6,607,840,000 927 ** Termination Messages 928 (T01) Terminating SUBSCRIBE msgs per watcher..................1 929 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1 930 (T03) Terminating NOTIFY msgs per watcher.....................0 931 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............0 932 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 933 Number of msgs for all watchers................40,000 934 Bytes for all watchers.....................18,000,000 935 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 936 Number of msgs for all watchers................40,000 937 Bytes for all watchers.....................14,800,000 938 (T07) Total number & bytes of terminating NOTIFY msgs 939 Number of msgs for all watchers.....................0 940 Bytes for all watchers..............................0 941 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 942 Number of msgs for all watchers.....................0 943 Bytes for all watchers..............................0 944 (T09) Total number & bytes of terminating messages per day 945 Number of msgs for all watchers................80,000 946 Bytes for all watchers.....................32,800,000 948 ** Bottom Line 949 (B01) Total of messages between domains...............7,840,000 950 Total of bytes between domains (PD=350).....6,824,400,000 951 Total of bytes between domains (PD=3000)...16,576,400,000 952 (B02) Total number of messages / second.....................272 953 Total of bytes per second (PD=350)................236,958 954 Total of bytes per second (PD=3000)...............575,569 955 (B03) Total number of by msgs per user/day..................196 956 Total number of bytes per user/day (PD=350).......170,610 957 Total number of bytes per user/day (PD=3000)......414,410 959 Figure 4: Dialog & NOTIFY optimizations used 961 2.8. Presence Federation Scenarios 963 While scalability issues exist in any large deployment, certain 964 characteristics make the deployment conducive to the existing 965 optimizations, and others have characteristics that do not. 966 Following is a list of federation scenarios that have varying usage 967 characteristics. For each, a message rate and bandwidth table is 968 provided reflecting typical changes message rates. Those 969 characteristics can alter the overall effectiveness of existing 970 optimizations. 972 Note that the number of users used is not the number of the users in 973 the domains but the actual logged in users. As was mentioned before 974 not all the domain users will use the presence service at the same 975 time. The number used for number of watchers and number of watched 976 presentities are for online users. 978 2.8.1. Widely distributed inter-domain presence 980 In some environments presence federation may be very common, perhaps 981 even more common than intra-domain presence. An example of this type 982 of environment is a small ISV or public server. Users in that small 983 ISV are not likely to subscribe to the presence of other users in the 984 their server since they do not necessarily have any relationship with 985 each other aside from receiving service from the same provider. They 986 are much more likely to be subscribed to the presence of users in one 987 of the federated domains (whether in consumer domains, academic, 988 other ISVs, etc). Common characteristics of this deployment are: 990 o Federated subscriptions are the majority of subscription traffic 991 o Individual users are likely to subscribe to multiple users in any 992 one domain 993 o The intersection of users in the deployment watching the same 994 presentities is quite small (i.e., probability that watchers in 995 the domain subscribe to the same presentity is low) 997 To account for the extraordinarily high percentage of federation 998 traffic, the number of federated presentities is increased to 20. 999 The number of watchers in the domain could also be adjusted to 1000 account for an expected larger community of users being peered with, 1001 it is omitted here for simplification 1003 The first table below provides the calculations without optimizations 1004 the second table provides the calculations with optimization. 1006 ** Constants 1007 (C01) Subscription lifetime (hours)...........................8 1008 (C02) Presence state changes / hour...........................3 1009 (C03) Subscription refresh interval / hour....................1 1010 (C04) Total federated presentities per watcher...............20 1011 (C05) Number of dialogs to maintain per watcher..............20 1012 (C06) Total number of watchers in domains................40,000 1013 (C07) SUBSCRIBE message size in bytes.......................450 1014 (C08) 200 OK for SUBSCRIBE message size in bytes............370 1015 (C09) NOTIFY message size not including presence doc........500 1016 (C10) 200 OK for NOTIFY message size in bytes...............370 1017 (C11) Size of an average presence document..................350 1019 ** Initial Messages 1020 (I01) Initial SUBSCRIBE msgs per watcher.....................20 1021 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher............20 1022 (I03) Initial NOTIFY msgs per watcher........................20 1023 (I04) Initial 200 OK msgs (NOTIFY) per watcher...............20 1024 (I05) Total number & bytes of initial SUBSCRIBE msgs 1025 Number of msgs for all watchers...............800,000 1026 Bytes for all watchers....................360,000,000 1027 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 1028 Number of msgs for all watchers...............800,000 1029 Bytes for all watchers....................296,000,000 1030 (I07) Total number & bytes of initial NOTIFY msgs 1031 Number of msgs for all watchers...............800,000 1032 Bytes for all watchers....................680,000,000 1033 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 1034 Number of msgs for all watchers...............800,000 1035 Bytes for all watchers....................296,000,000 1036 (I09) Total number & bytes of initial messages per day 1037 Number of msgs for all watchers.............3,200,000 1038 Bytes for all watchers..................1,632,000,000 1040 ** Steady State Messages 1041 (S01) NOTIFY msgs due to state change 1042 per watched presentity per day.....................22 1043 (S02) 200 (for NOTIFY due to state change) msgs 1044 per watched presentity per day.....................22 1045 (S03) Total number and size of msgs due to state change per day 1046 Number of msgs for all watchers............35,200,000 1047 Bytes for all watchers.................21,472,000,000 1048 (S04) Number of SUBSCRIBE msgs for refreshes 1049 per watcher per day...............................140 1050 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 1051 per watcher per day...............................140 1052 (S06) Number of NOTIFY msgs for refreshes 1053 per watcher per day...............................140 1054 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1055 per watcher per day...............................140 1056 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1057 Number of msgs for all watchers per day....22,400,000 1058 Bytes for all watchers per day.........11,424,000,000 1059 (S09) Total number & bytes of steady messages per day 1060 Number of msgs for all watchers............57,600,000 1061 Bytes for all watchers.................32,896,000,000 1063 ** Termination Messages 1064 (T01) Terminating SUBSCRIBE msgs per watcher.................20 1065 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........20 1066 (T03) Terminating NOTIFY msgs per watcher....................20 1067 (T04) Terminating 200 OK msgs (NOTIFY) per watcher...........20 1068 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1069 Number of msgs for all watchers...............800,000 1070 Bytes for all watchers....................360,000,000 1071 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1072 Number of msgs for all watchers...............800,000 1073 Bytes for all watchers....................296,000,000 1074 (T07) Total number & bytes of terminating NOTIFY msgs 1075 Number of msgs for all watchers...............800,000 1076 Bytes for all watchers....................680,000,000 1077 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 1078 Number of msgs for all watchers...............800,000 1079 Bytes for all watchers....................296,000,000 1080 (T09) Total number & bytes of terminating messages per day 1081 Number of msgs for all watchers.............3,200,000 1082 Bytes for all watchers..................1,632,000,000 1084 ** Bottom Line 1085 (B01) Total of messages between domains..............64,000,000 1086 Total of bytes between domains (PD=350)....36,160,000,000 1087 Total of bytes between domains (PD=3000)..101,880,000,000 1088 (B02) Total number of messages / second...................2,222 1089 Total of bytes per second (PD=350)..............1,255,556 1090 Total of bytes per second (PD=3000).............3,537,500 1091 (B03) Total number of by msgs per user/day................1,600 1092 Total number of bytes per user/day (PD=350).......904,000 1093 Total number of bytes per user/day (PD=3000).....,547,000 1095 Figure 5: Widely distributed inter-domain with no optimizations 1097 ** Constants 1098 (C01) Subscription lifetime (hours)...........................8 1099 (C02) Presence state changes / hour...........................3 1100 (C03) Subscription refresh interval / hour....................1 1101 (C04) Total federated presentities per watcher...............20 1102 (C05) Number of dialogs to maintain per watcher...............1 1103 (C06) Total number of watchers in domains................40,000 1104 (C07) SUBSCRIBE message size in bytes.......................450 1105 (C08) 200 OK for SUBSCRIBE message size in bytes............370 1106 (C09) NOTIFY message size not including presence doc........500 1107 (C10) 200 OK for NOTIFY message size in bytes...............370 1108 (C11) Size of an average presence document..................350 1109 (C13) Additional data per document in RLMI..................160 1110 (C14) Multiparty boundary in RLMI document..................144 1111 (C15) XML root node in RLMI document........................144 1112 ** Initial Messages 1113 (I01) Initial SUBSCRIBE msgs per watcher......................1 1114 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1 1115 (I03) Initial NOTIFY msgs per watcher.........................1 1116 (I04) Initial 200 OK msgs (NOTIFY) per watcher................1 1117 (I05) Total number & bytes of initial SUBSCRIBE msgs 1118 Number of msgs for all watchers................40,000 1119 Bytes for all watchers.....................18,000,000 1120 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 1121 Number of msgs for all watchers................40,000 1122 Bytes for all watchers.....................14,800,000 1123 (I07) Total number & bytes of initial NOTIFY msgs 1124 Number of msgs for all watchers................40,000 1125 Bytes for all watchers....................554,720,000 1126 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 1127 Number of msgs for all watchers................40,000 1128 Bytes for all watchers.....................14,800,000 1129 (I09) Total number & bytes of initial messages per day 1130 Number of msgs for all watchers...............160,000 1131 Bytes for all watchers....................602,320,000 1133 ** Steady State Messages 1134 (S01) NOTIFY msgs due to state change 1135 per watched presentity per day.....................22 1136 (S02) 200 (for NOTIFY due to state change) msgs 1137 per watched presentity per day.....................22 1138 (S03) Total number and size of msgs due to state change per day 1139 Number of msgs for all watchers............35,200,000 1140 Bytes for all watchers.................31,891,200,000 1141 (S04) Number of SUBSCRIBE msgs for refreshes 1142 per watcher per day.................................7 1143 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 1144 per watcher per day.................................7 1145 (S06) Number of NOTIFY msgs for refreshes 1146 per watcher per day.................................0 1147 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1148 per watcher per day.................................0 1149 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1150 Number of msgs for all watchers per day.......560,000 1151 Bytes for all watchers per day............229,600,000 1152 (S09) Total number & bytes of steady messages per day 1153 Number of msgs for all watchers............35,760,000 1154 Bytes for all watchers.................32,120,800,000 1156 ** Termination Messages 1157 (T01) Terminating SUBSCRIBE msgs per watcher..................1 1158 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1 1159 (T03) Terminating NOTIFY msgs per watcher.....................0 1160 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............0 1161 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1162 Number of msgs for all watchers................40,000 1163 Bytes for all watchers.....................18,000,000 1164 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1165 Number of msgs for all watchers................40,000 1166 Bytes for all watchers.....................14,800,000 1167 (T07) Total number & bytes of terminating NOTIFY msgs 1168 Number of msgs for all watchers.....................0 1169 Bytes for all watchers..............................0 1170 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 1171 Number of msgs for all watchers.....................0 1172 Bytes for all watchers..............................0 1173 (T09) Total number & bytes of terminating messages per day 1174 Number of msgs for all watchers................80,000 1175 Bytes for all watchers.....................32,800,000 1177 ** Bottom Line 1178 (B01) Total of messages between domains..............36,000,000 1179 Total of bytes between domains (PD=350)....32,755,920,000 1180 Total of bytes between domains (PD=3000)...81,515,920,000 1181 (B02) Total number of messages / second...................1,250 1182 Total of bytes per second (PD=350)..............1,137,358 1183 Total of bytes per second (PD=3000).............2,830,414 1184 (B03) Total number of by msgs per user/day..................900 1185 Total number of bytes per user/day (PD=350).......818,898 1186 Total number of bytes per user/day (PD=3000)....2,037,898 1188 Figure 6: Widely distributed inter-domain with optimizations 1190 2.8.2. Associated inter-domain presence 1192 In this type of environment, the domain is a collection of associated 1193 users such as an enterprise. Here, federation is once again very 1194 common. However, there is also a strong association between some 1195 users in the deployment. These associations make it somewhat more 1196 likely that users in that domain will be watchers of the same 1197 presentity. This can occur because of business relationships (e.g. 1198 two co-workers on a project federating with a partner company). 1200 Common characteristics of this deployment are: 1202 o Federated subscriptions are large minority or small majority of 1203 subscription traffic 1204 o Individual users are likely to subscribe to multiple users in any 1205 one domain, especially their own 1207 o The intersection of users in the deployment watching the same 1208 presentities increases 1210 This federation type has traffic rates similar to the previous 1211 examples but with different levels of association of the users. 1213 2.8.3. Very large network peering 1215 In this environment, two or more very large networks create a peering 1216 relationship allowing their users to subscribe to presence in the 1217 other domains. Where as the number of users in other deployment 1218 types ranges from hundreds to several hundred thousand, these large 1219 networks host up to hundreds of millions of users. Examples of these 1220 networks are large wireless carriers and consumer IM networks. 1222 Common characteristics of this deployment are: 1224 o As users become accustomed to network boundaries disappearing, 1225 federated subscriptions become as common as subscriptions within 1226 the same domain 1227 o Individual users are highly likely to want to see presence of 1228 multiple presentities in the peer network 1229 o The intersection of users in the deployment watching the same 1230 presentities is very high (i.e., two or more users in network A 1231 are extremely likely to be watching a same user in network B) 1232 o Status changes increase greatly due to typical observed consumer 1233 behavior 1235 The first table below provides the calculations without optimizations 1236 the second table provides the calculations with optimizations. Even 1237 though the optimizations help a lot (almost cut the number of 1238 messages by half), the numbers are still very high. Note also that 1239 the bandwidth required is very high. 1241 ** Constants 1242 (C01) Subscription lifetime (hours)...........................8 1243 (C02) Presence state changes / hour...........................6 1244 (C03) Subscription refresh interval / hour....................1 1245 (C04) Total federated presentities per watcher...............10 1246 (C05) Number of dialogs to maintain per watcher..............10 1247 (C06) Total number of watchers in domains............20,000,000 1248 (C07) SUBSCRIBE message size in bytes.......................450 1249 (C08) 200 OK for SUBSCRIBE message size in bytes............370 1250 (C09) NOTIFY message size not including presence doc........500 1251 (C10) 200 OK for NOTIFY message size in bytes...............370 1252 (C11) Size of an average presence document..................350 1254 ** Initial Messages 1255 (I01) Initial SUBSCRIBE msgs per watcher.....................10 1256 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher............10 1257 (I03) Initial NOTIFY msgs per watcher........................10 1258 (I04) Initial 200 OK msgs (NOTIFY) per watcher...............10 1259 (I05) Total number & bytes of initial SUBSCRIBE msgs 1260 Number of msgs for all watchers...........200,000,000 1261 Bytes for all watchers.................90,000,000,000 1262 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 1263 Number of msgs for all watchers...........200,000,000 1264 Bytes for all watchers.................74,000,000,000 1265 (I07) Total number & bytes of initial NOTIFY msgs 1266 Number of msgs for all watchers...........200,000,000 1267 Bytes for all watchers................170,000,000,000 1268 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 1269 Number of msgs for all watchers...........200,000,000 1270 Bytes for all watchers.................74,000,000,000 1271 (I09) Total number & bytes of initial messages per day 1272 Number of msgs for all watchers...........800,000,000 1273 Bytes for all watchers................408,000,000,000 1275 ** Steady State Messages 1276 (S01) NOTIFY msgs due to state change 1277 per watched presentity per day.....................46 1278 (S02) 200 (for NOTIFY due to state change) msgs 1279 per watched presentity per day.....................46 1280 (S03) Total number and size of msgs due to state change per day 1281 Number of msgs for all watchers........18,400,000,000 1282 Bytes for all watchers.............11,224,000,000,000 1283 (S04) Number of SUBSCRIBE msgs for refreshes 1284 per watcher per day................................70 1285 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 1286 per watcher per day................................70 1287 (S06) Number of NOTIFY msgs for refreshes 1288 per watcher per day................................70 1289 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1290 per watcher per day................................70 1291 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1292 Number of msgs for all watchers per day.5,600,000,000 1293 Bytes for all watchers per day......2,856,000,000,000 1294 (S09) Total number & bytes of steady messages per day 1295 Number of msgs for all watchers........24,000,000,000 1296 Bytes for all watchers.............14,080,000,000,000 1298 ** Termination Messages 1299 (T01) Terminating SUBSCRIBE msgs per watcher.................10 1300 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........10 1301 (T03) Terminating NOTIFY msgs per watcher....................10 1302 (T04) Terminating 200 OK msgs (NOTIFY) per watcher...........10 1303 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1304 Number of msgs for all watchers...........200,000,000 1305 Bytes for all watchers.................90,000,000,000 1306 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1307 Number of msgs for all watchers...........200,000,000 1308 Bytes for all watchers.................74,000,000,000 1309 (T07) Total number & bytes of terminating NOTIFY msgs 1310 Number of msgs for all watchers...........200,000,000 1311 Bytes for all watchers................170,000,000,000 1312 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 1313 Number of msgs for all watchers...........200,000,000 1314 Bytes for all watchers.................74,000,000,000 1315 (T09) Total number & bytes of terminating messages per day 1316 Number of msgs for all watchers...........800,000,000 1317 Bytes for all watchers................408,000,000,000 1319 ** Bottom Line 1320 (B01) Total of messages between domains..........25,600,000,000 1321 Total of bytes bet. domains (PD=350)...14,896,000,000,000 1322 Total of bytes bet. domains (PD=3000)..44,046,000,000,000 1323 (B02) Total number of messages / second.................888,889 1324 Total of bytes per second (PD=350)............517,222,222 1325 Total of bytes per second (PD=3000).........1,529,375,000 1326 (B03) Total number of by msgs per user/day................1,280 1327 Total number of bytes per user/day (PD=350).......744,800 1328 Total number of bytes per user/day (PD=3000)....2,202,300 1330 Figure 7: Very large network peering with no optimizations 1332 ** Constants 1333 (C01) Subscription lifetime (hours)...........................8 1334 (C02) Presence state changes / hour...........................6 1335 (C03) Subscription refresh interval / hour....................1 1336 (C04) Total federated presentities per watcher...............10 1337 (C05) Number of dialogs to maintain per watcher...............1 1338 (C06) Total number of watchers in domains............20,000,000 1339 (C07) SUBSCRIBE message size in bytes.......................450 1340 (C08) 200 OK for SUBSCRIBE message size in bytes............370 1341 (C09) NOTIFY message size not including presence doc........500 1342 (C10) 200 OK for NOTIFY message size in bytes...............370 1343 (C11) Size of an average presence document..................350 1344 (C13) Additional data per document in RLMI..................160 1345 (C14) Multiparty boundary in RLMI document..................144 1346 (C15) XML root node in RLMI document........................144 1348 ** Initial Messages 1349 (I01) Initial SUBSCRIBE msgs per watcher......................1 1350 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1 1351 (I03) Initial NOTIFY msgs per watcher.........................1 1352 (I04) Initial 200 OK msgs (NOTIFY) per watcher................1 1353 (I05) Total number & bytes of initial SUBSCRIBE msgs 1354 Number of msgs for all watchers............20,000,000 1355 Bytes for all watchers..................9,000,000,000 1356 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 1357 Number of msgs for all watchers............20,000,000 1358 Bytes for all watchers..................7,400,000,000 1359 (I07) Total number & bytes of initial NOTIFY msgs 1360 Number of msgs for all watchers............20,000,000 1361 Bytes for all watchers................146,560,000,000 1362 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 1363 Number of msgs for all watchers............20,000,000 1364 Bytes for all watchers..................7,400,000,000 1365 (I09) Total number & bytes of initial messages per day 1366 Number of msgs for all watchers............80,000,000 1367 Bytes for all watchers................170,360,000,000 1369 ** Steady State Messages 1370 (S01) NOTIFY msgs due to state change 1371 per watched presentity per day.....................46 1372 (S02) 200 (for NOTIFY due to state change) msgs 1373 per watched presentity per day.....................46 1374 (S03) Total number and size of msgs due to state change per day 1375 Number of msgs for all watchers........18,400,000,000 1376 Bytes for all watchers.............16,670,400,000,000 1377 (S04) Number of SUBSCRIBE msgs for refreshes 1378 per watcher per day.................................7 1379 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 1380 per watcher per day.................................7 1381 (S06) Number of NOTIFY msgs for refreshes 1382 per watcher per day.................................0 1383 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1384 per watcher per day.................................0 1385 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1386 Number of msgs for all watchers per day...280,000,000 1387 Bytes for all watchers per day........114,800,000,000 1388 (S09) Total number & bytes of steady messages per day 1389 Number of msgs for all watchers........18,680,000,000 1390 Bytes for all watchers.............16,785,200,000,000 1392 ** Termination Messages 1393 (T01) Terminating SUBSCRIBE msgs per watcher..................1 1394 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1 1395 (T03) Terminating NOTIFY msgs per watcher.....................0 1396 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............0 1397 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1398 Number of msgs for all watchers............20,000,000 1399 Bytes for all watchers..................9,000,000,000 1400 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1401 Number of msgs for all watchers............20,000,000 1402 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: Very 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 the two. This scenario is unique 1430 in 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 with 1433 multiple independent vendor presence solutions deployed (e.g., a 1434 presence solution for desktop messaging deployed alongside a presence 1435 solution for IP telephony). 1437 Common characteristics of this deployment are 1439 o The difference between subscriptions to presentities in one system 1440 vs. the other are completely arbitrary. Any one presentity is as 1441 likely to be homed on one infrastructure as the other. 1442 o Active users are almost guaranteed of subscribing to many users in 1443 the peer infrastructure. 1445 o The level of intersection of presentities is extremely high. 1447 The first table below provides the calculations without optimizations 1448 the second table provides the calculations with optimization. Even 1449 though the relatively conservative numbers are used, the amount of 1450 messages is still very high even though optimization may cut the 1451 traffic by more then 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 1541 Figure 9: Intra-domain peering with no optimizations 1543 ** Constants 1544 (C01) Subscription lifetime (hours)...........................8 1545 (C02) Presence state changes / hour...........................3 1546 (C03) Subscription refresh interval / hour....................1 1547 (C04) Total federated presentities per watcher...............10 1548 (C05) Number of dialogs to maintain per watcher...............1 1549 (C06) Total number of watchers in domains...............120,000 1550 (C07) SUBSCRIBE message size in bytes.......................450 1551 (C08) 200 OK for SUBSCRIBE message size in bytes............370 1552 (C09) NOTIFY message size not including presence doc........500 1553 (C10) 200 OK for NOTIFY message size in bytes...............370 1554 (C11) Size of an average presence document..................350 1555 (C13) Additional data per document in RLMI..................160 1556 (C14) Multiparty boundary in RLMI document..................144 1557 (C15) XML root node in RLMI document........................144 1559 ** Initial Messages 1560 (I01) Initial SUBSCRIBE msgs per watcher......................1 1561 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1 1562 (I03) Initial NOTIFY msgs per watcher.........................1 1563 (I04) Initial 200 OK msgs (NOTIFY) per watcher................1 1564 (I05) Total number & bytes of initial SUBSCRIBE msgs 1565 Number of msgs for all watchers...............120,000 1566 Bytes for all watchers.....................54,000,000 1567 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 1568 Number of msgs for all watchers...............120,000 1569 Bytes for all watchers.....................44,400,000 1570 (I07) Total number & bytes of initial NOTIFY msgs 1571 Number of msgs for all watchers...............120,000 1572 Bytes for all watchers....................879,360,000 1573 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 1574 Number of msgs for all watchers...............120,000 1575 Bytes for all watchers.....................44,400,000 1576 (I09) Total number & bytes of initial messages per day 1577 Number of msgs for all watchers...............480,000 1578 Bytes for all watchers..................1,022,160,000 1580 ** Steady State Messages 1581 (S01) NOTIFY msgs due to state change 1582 per watched presentity per day.....................22 1583 (S02) 200 (for NOTIFY due to state change) msgs 1584 per watched presentity per day.....................22 1585 (S03) Total number and size of msgs due to state change per day 1586 Number of msgs for all watchers............52,800,000 1587 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 1593 (S06) Number of NOTIFY msgs for refreshes 1594 per watcher per day.................................0 1595 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1596 per watcher per day.................................0 1597 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1598 Number of msgs for all watchers per day.....1,680,000 1599 Bytes for all watchers per day............688,800,000 1600 (S09) Total number & bytes of steady messages per day 1601 Number of msgs for all watchers............54,480,000 1602 Bytes for all watchers.................48,525,600,000 1604 ** Termination Messages 1605 (T01) Terminating SUBSCRIBE msgs per watcher..................1 1606 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1 1607 (T03) Terminating NOTIFY msgs per watcher.....................1 1608 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............1 1609 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1610 Number of msgs for all watchers...............120,000 1611 Bytes for all watchers.....................54,000,000 1612 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1613 Number of msgs for all watchers...............120,000 1614 Bytes for all watchers.....................44,400,000 1615 (T07) Total number & bytes of terminating NOTIFY msgs 1616 Number of msgs for all watchers.....................0 1617 Bytes for all watchers..............................0 1618 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 1619 Number of msgs for all watchers...............120,000 1620 Bytes for all watchers.....................44,400,000 1621 (T09) Total number & bytes of terminating messages per day 1622 Number of msgs for all watchers...............240,000 1623 Bytes for all watchers.....................98.400,000 1625 ** Bottom Line 1626 (B01) Total of messages between domains..............55,200,000 1627 Total of bytes between domains (PD=350)....49,646,160,000 1628 Total of bytes between domains (PD=3000)..122,796,160,000 1629 (B02) Total number of messages / second...................1,917 1630 Total of bytes per second (PD=350)..............1,723,825 1631 Total of bytes per second (PD=3000).............4,263,408 1632 (B03) Total number of by msgs per user/day..................460 1633 Total number of bytes per user/day (PD=350).......413,718 1634 Total number of bytes per user/day (PD=3000)....1,023,218 1636 Figure 10: Intra-domain peering with optimizations 1638 2.9. Partial Notifications Optimization 1640 Draft [12] define a way for the watcher to request getting only what 1641 was changed in the presence document. The following is a calculation 1642 of the bandwidth that is saved in the very large peering network 1643 case, when we add the partial notification optimization to the dialog 1644 and NOTIFY optimization. It is assumed that except for the initial 1645 NOTIFY all the other NOTIFY messages will be partial. It is also 1646 assumed that only a single attribute in the presence document will be 1647 changed each time, thus the size of the partial presence document is 1648 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: Very large networks peering with NOTIFY and partial 1741 optimizations 1743 2.10. Very Optimized SIP 1745 SIP is network agnostic protocol, therefore, the protocol carries 1746 additional messages like 200 OK that would have been redundant in a 1747 protocol that is TCP based only. 1749 The following calculation assumes an imaginary TCP only based version 1750 of SIP that optimizes the following: 1752 o There is no 200 OK for each message. Since only TCP has to be 1753 supported, there is not need to compensate for network issues. 1754 o There is no refresh for subscriptions. 1755 o There is no NOTIFY upon termination of SUBSCRIPTION 1756 o The size of each message is smaller since there is no need for the 1757 various headers that SIP uses for routing etc. So we need to 1758 assume smaller message sizes while we will keep the size of the 1759 presence document the same. 1761 As notes above the calculations in this document do not assume 1762 offline means of getting parts of the presence information. 1763 Therefore, in addition to the above optimizations, the other 1764 optimizations that were assumed in the document will be assumed here 1765 also. These includes partial notifications and the dialog 1766 optimizations. The NOTIFY optimization is not relevant here since 1767 there are no refreshes of subscriptions. 1769 The following is a calculation for the very large networks peering 1770 scenario assuming the imaginary TCP only SIP. It is very interesting 1771 to note that the dialog optimization does not reduce the number of 1772 bytes when partial notification optimization is applied (on the 1773 contrary) due to the RLMI overhead. 1775 ** Constants 1776 (C01) Subscription lifetime (hours)...........................8 1777 (C02) Presence state changes / hour...........................6 1778 (C03) Subscription refresh interval / hour....................0 1779 (C04) Total federated presentities per watcher...............10 1780 (C05) Number of dialogs to maintain per watcher...............1 1781 (C06) Total number of watchers in domains............20,000,000 1782 (C07) SUBSCRIBE message size in bytes.......................150 1783 (C08) 200 OK for SUBSCRIBE message size in bytes..............0 1784 (C09) NOTIFY message size not including presence doc........150 1785 (C10) 200 OK for NOTIFY message size in bytes.................0 1786 (C11) Size of an average presence document..................350 1787 (C12) Size of an average partial presence document..........200 1789 ** Initial Messages 1790 (I01) Initial SUBSCRIBE msgs per watcher......................1 1791 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............0 1792 (I03) Initial NOTIFY msgs per watcher.........................1 1793 (I04) Initial 200 OK msgs (NOTIFY) per watcher................0 1794 (I05) Total number & bytes of initial SUBSCRIBE msgs 1795 Number of msgs for all watchers............20,000,000 1796 Bytes for all watchers..................3,000,000,000 1797 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 1798 Number of msgs for all watchers.....................0 1799 Bytes for all watchers..............................0 1800 (I07) Total number & bytes of initial NOTIFY msgs 1801 Number of msgs for all watchers............20,000,000 1802 Bytes for all watchers................136,680,000,000 1803 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 1804 Number of msgs for all watchers.....................0 1805 Bytes for all watchers..............................0 1806 (I09) Total number & bytes of initial messages per day 1807 Number of msgs for all watchers............40,000,000 1808 Bytes for all watchers................139,680,000,000 1810 ** Steady State Messages 1811 (S01) NOTIFY msgs due to state change 1812 per watched presentity per day.....................46 1813 (S02) 200 (for NOTIFY due to state change) msgs 1814 per watched presentity per day......................0 1815 (S03) Total number and size of msgs due to state change per day 1816 Number of msgs for all watchers.........9,200,000,000 1817 Bytes for all watchers..............8,666,400,000,000 1818 (S04) Number of SUBSCRIBE msgs for refreshes 1819 per watcher per day.................................0 1820 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 1821 per watcher per day.................................0 1822 (S06) Number of NOTIFY msgs for refreshes 1823 per watcher per day.................................0 1824 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1825 per watcher per day.................................0 1826 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1827 Number of msgs for all watchers per day.............0 1828 Bytes for all watchers per day......................0 1829 (S09) Total number & bytes of steady messages per day 1830 Number of msgs for all watchers.........9,200,000,000 1831 Bytes for all watchers..............8,666,400,000,000 1833 ** Termination Messages 1834 (T01) Terminating SUBSCRIBE msgs per watcher..................1 1835 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........0 1836 (T03) Terminating NOTIFY msgs per watcher.....................0 1837 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............0 1838 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1839 Number of msgs for all watchers............20,000,000 1840 Bytes for all watchers..................3,000,000,000 1841 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1842 Number of msgs for all watchers.....................0 1843 Bytes for all watchers..............................0 1844 (T07) Total number & bytes of terminating NOTIFY msgs 1845 Number of msgs for all watchers.....................0 1846 Bytes for all watchers..............................0 1847 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 1848 Number of msgs for all watchers.....................0 1849 Bytes for all watchers..............................0 1850 (T09) Total number & bytes of terminating messages per day 1851 Number of msgs for all watchers............20,000,000 1852 Bytes for all watchers..................3,000,000,000 1854 ** Bottom Line 1855 (B01) Total of messages between domains...........9,260,000,000 1856 Total of bytes between domains (PD=350).8,809,080,000,000 1857 Total of bytes bet. domains (PD=3000)...9,339,080,000,000 1858 (B02) Total number of messages / second.................321,528 1859 Total of bytes per second (PD=350)............305,870,833 1860 Total of bytes per second (PD=3000)...........324,273,611 1861 (B03) Total number of by msgs per user/day..................463 1862 Total number of bytes per user/day (PD=350).......440,454 1863 Total number of bytes per user/day (PD=3000)......466,954 1865 Figure 12: Very large networks peering, TCP only SIP+Partial+Dialog 1866 optimizations 1868 ** Constants 1869 (C01) Subscription lifetime (hours)...........................8 1870 (C02) Presence state changes / hour...........................6 1871 (C03) Subscription refresh interval / hour....................0 1872 (C04) Total federated presentities per watcher...............10 1873 (C05) Number of dialogs to maintain per watcher..............10 1874 (C06) Total number of watchers in domains............20,000,000 1875 (C07) SUBSCRIBE message size in bytes.......................150 1876 (C08) 200 OK for SUBSCRIBE message size in bytes..............0 1877 (C09) NOTIFY message size not including presence doc........150 1878 (C10) 200 OK for NOTIFY message size in bytes.................0 1879 (C11) Size of an average presence document..................350 1880 (C12) Size of an average partial presence document..........200 1882 ** Initial Messages 1883 (I01) Initial SUBSCRIBE msgs per watcher.....................10 1884 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............0 1885 (I03) Initial NOTIFY msgs per watcher........................10 1886 (I04) Initial 200 OK msgs (NOTIFY) per watcher................0 1887 (I05) Total number & bytes of initial SUBSCRIBE msgs 1888 Number of msgs for all watchers...........200,000,000 1889 Bytes for all watchers.................30,000,000,000 1890 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 1891 Number of msgs for all watchers.....................0 1892 Bytes for all watchers..............................0 1893 (I07) Total number & bytes of initial NOTIFY msgs 1894 Number of msgs for all watchers...........200,000,000 1895 Bytes for all watchers................100,000,000,000 1896 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 1897 Number of msgs for all watchers.....................0 1898 Bytes for all watchers..............................0 1899 (I09) Total number & bytes of initial messages per day 1900 Number of msgs for all watchers...........400,000,000 1901 Bytes for all watchers................130,000,000,000 1903 ** Steady State Messages 1904 (S01) NOTIFY msgs due to state change 1905 per watched presentity per day.....................46 1906 (S02) 200 (for NOTIFY due to state change) msgs 1907 per watched presentity per day......................0 1908 (S03) Total number and size of msgs due to state change per day 1909 Number of msgs for all watchers.........9,200,000,000 1910 Bytes for all watchers..............3,220,000,000,000 1911 (S04) Number of SUBSCRIBE msgs for refreshes 1912 per watcher per day.................................0 1913 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 1914 per watcher per day.................................0 1915 (S06) Number of NOTIFY msgs for refreshes 1916 per watcher per day.................................0 1917 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1918 per watcher per day.................................0 1919 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1920 Number of msgs for all watchers per day.............0 1921 Bytes for all watchers per day......................0 1922 (S09) Total number & bytes of steady messages per day 1923 Number of msgs for all watchers.........9,200,000,000 1924 Bytes for all watchers..............3,220,000,000,000 1926 ** Termination Messages 1927 (T01) Terminating SUBSCRIBE msgs per watcher.................10 1928 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........0 1929 (T03) Terminating NOTIFY msgs per watcher.....................0 1930 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............0 1931 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1932 Number of msgs for all watchers...........200,000,000 1933 Bytes for all watchers.................30,000,000,000 1934 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1935 Number of msgs for all watchers.....................0 1936 Bytes for all watchers..............................0 1937 (T07) Total number & bytes of terminating NOTIFY msgs 1938 Number of msgs for all watchers.....................0 1939 Bytes for all watchers..............................0 1940 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 1941 Number of msgs for all watchers.....................0 1942 Bytes for all watchers..............................0 1943 (T09) Total number & bytes of terminating messages per day 1944 Number of msgs for all watchers...........200,000,000 1945 Bytes for all watchers.................30,000,000,000 1947 ** Bottom Line 1948 (B01) Total of messages between domains...........9,800,000,000 1949 Total of bytes between domains (PD=350).3,380,000,000,000 1950 Total of bytes bet. domains (PD=3000)...3,910,280,000,000 1951 (B02) Total number of messages / second.................340,278 1952 Total of bytes per second (PD=350)............117,361,111 1953 Total of bytes per second (PD=3000)...........135,763,889 1954 (B03) Total number of by msgs per user/day..................490 1955 Total number of bytes per user/day (PD=350).......169,000 1956 Total number of bytes per user/day (PD=3000)......195,500 1958 Figure 13: Very large networks peering, TCP only SIP+Partial 1959 optimizations 1961 3. State Management 1963 In previous sections we have discussed the big amount of messages 1964 that need to be sent to/from a presence server In this section the 1965 state that needs to be maintained by a presence server will be 1966 analyzed and shown 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. 1972 2. Maintain the state of the subscriptions of watchers and provide 1973 timely updates to the watchers. 1975 For a single subscription from a single watcher on a presentity, the 1976 presence server has to maintain the following state: 1978 o Subscription state including all the parameters that are needed in 1979 order to maintain the subscription as timers. 1980 o Optional filtering information that was requested by the watcher. 1981 This includes enough information that is needed for doing the 1982 filtering. In addition additional information has to be 1983 maintained if partial notification is being supported for the 1984 subscription 1985 o Optional rate management information as throttling 1986 o Watcher information [2], [3] that is the result of the 1987 subscription in order to enable watched presentities to see who is 1988 watching them. 1990 For each presentity that has been subscribed to in the presence 1991 server, the presence server has to maintain the following state: 1993 o A list of the subscriptions for the presentity. Note that this is 1994 already taken care of from the size calculation point of view by 1995 the subscription state above. 1996 o Authorization information for the presentity. 1998 For each presentity for which there was any publication and the 1999 presentity has a state other then a default value, the presence 2000 server has to maintain the current value of the presentity. 2002 3.1. State Size Calculations 2004 Lets assume the following sizes: 2006 o Subscription size - 2K bytes. This includes watcher information 2007 that need to be created by the presence server for each 2008 subscription. This is for each subscription that is done by each 2009 watcher to each presentity that the watcher is watching. So if we 2010 have 10K watchers we should have 10K of these. 2011 o Subscribed to resource - 1K bytes (for privacy information and 2012 other management info). This is for each presentity that is being 2013 watched. No matter how many watchers are watching it. The 2014 subscriptions themselves are already calculated in the previous 2015 bullet. 2017 o Resource with a state - 6K bytes. This is a moderate assumption 2018 if we take into account the amount of data that is being put in a 2019 presence document as multiple devices, calendar and geographical 2020 information. This is for each presentity that has state other 2021 then the default empty state. It does not matter if it is being 2022 watched or not. 2024 3.1.1. Tiny System 2026 o 10K subscriptions = 19M bytes. 2027 o 5K subscribed to presentities = 5M bytes. 2028 o 10K presentities with state = 58M bytes. 2030 Total is 82M bytes. 2032 3.1.2. Medium System 2034 o 100K subscriptions = 195M bytes. 2035 o 50K subscribed to presentities = 49M bytes. 2036 o 100K presentities with state = 586M bytes. 2038 Total is 830M bytes. 2040 3.1.3. Large System 2042 o 6M subscriptions = 11,718M bytes. 2043 o 3M subscribed to presentities = 2,929M bytes. 2044 o 4M presentities with state = 23437M bytes. 2046 Total is 38G bytes. 2048 3.1.4. Very Large System 2050 o 150M subscriptions = 292,969M bytes. 2051 o 75M subscribed to presentities = 73,242M bytes. 2052 o 100M presentities with state = 585,937M bytes. 2054 Total is 952G bytes which is a very big number for a very dynamic 2055 storage as needed by the presence server. 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 seem not so big for 2062 databases even for the very large system, we need to remember that 2063 this state is a very dynamic state. Subscriptions come and go all 2064 the time, the status of presentities is being updated and so 2065 forth. This means that the presence server has to manage its 2066 state in a medium that is very dynamic and for such large sizes 2067 this task is not trivial. 2068 o Interlinked state - The subscriptions and the subscribed to 2069 presentities are dependent on each other. There needs to be a 2070 link from the presentity to the subscriptions and vice versa. See 2071 Section 4.5 about the interlinkage that is created due to resource 2072 lists. 2073 o Moderate assumptions - The size assumptions that were made above 2074 are quite moderate. As presence is becoming more a core 2075 middleware functionality that holds a lot of data on the user. In 2076 real-life the numbers above may be even higher and the presence 2077 server can have additional overhead as managing the SIP sessions, 2078 networking and more. 2080 Although the calculations above do not show that there is a real 2081 issue with state management of presence in medium systems or even in 2082 big systems since it should be possible to divide the state between 2083 different machines, the state size is still very big. A bigger issue 2084 with the state is more when resource lists are involved and create an 2085 interlinked state between many servers. In that case the division of 2086 very big state to multiple servers becomes less trivial... 2088 4. Processing complexities 2090 The basic presence paradigm consists from a watcher and a presentity 2091 to which the watcher watches. It sounds simple enough but there are 2092 many additions and extensions that the presence server has to manage 2093 that make the processing of the presence server very complex. 2095 In this section we show that in addition to the large amount of 2096 messages and the big state that the presence server has to handle, it 2097 has also to handle quite intensive processing for aggregation, 2098 partial notify and publish, filtering and privacy. This adds another 2099 complexity to the presence server in the CPU front in addition to the 2100 network and memory fronts that were described before. 2102 4.1. Aggregation 2104 A presence document may contain multiple resources. These resources 2105 can be devices of the presentity, information that is received form 2106 external providers of presence information for the presentity as 2107 geographical and calendar information and more. 2109 The presence server needs to be able to get the updates from all the 2110 resources and aggregate them correctly into a single presence 2111 document. Although this is just "XML processing" task, the amount of 2112 updates that the presence server may get, the need to keep the 2113 presence document aligned with its schema and the need to notify the 2114 users as soon as possible create a significant processing burden on 2115 the presence server 2117 4.2. Partial Publish and Notify 2119 Drafts [12], [13] define a way for the watcher to request getting 2120 only what was changed in the presence document and for the publisher 2121 of presence information to publish only what was changed in the 2122 presence document since the last publish. Although these 2123 optimizations help in reducing the amount of the data that is sent 2124 from/to the presence server, these optimizations create additional 2125 processing burden on the presence server. 2127 When a partial publish is arriving to the presence server, the 2128 presence server has to be able to process the partial publish, change 2129 only what is indicated in the partial publish while keeping the 2130 presence document in a well formed shape according to the schema. 2132 In partial notify the processing is even more complex since each 2133 watcher needs to get the partial update based on the last update that 2134 was received by that watcher. Therefore [12] specifies a versioning 2135 mechanism that enables the watcher to get the updates based on the 2136 previous state that it has seen. This versioning mechanism has to be 2137 maintained by the presence server for each watcher that is subscribed 2138 to a presentity and requires partial notify. 2140 4.3. Filtering 2142 Filtering as defined in RFCs [7], [8] enables a watcher to request to 2143 be notified only when the presence document fulfills certain 2144 conditions. Although this is a very convenient feature for watchers, 2145 the burden that is put on the presence server is quite big. For each 2146 change in the presence document, the presence server needs to compute 2147 the filtering expressions which can be very complex, decide whether 2148 and what to send to the watcher that have requested filtering. 2150 4.4. Authorization 2152 Draft [14] defines presence authorization rules that can be used by 2153 presentities to define who can see what from their presence 2154 documents. The processing that the presence server has to do here is 2155 very similar to filtering. When there is a change to any presence 2156 document that has privacy defined for it, the presence server needs 2157 to create different notification for different watchers according to 2158 what is defined in the authorization rules. 2160 4.5. Resource List Service 2162 RFC [9] defines a way to subscribe on a single URI while that URI is 2163 actually a list of resources that are being subscribed to by a single 2164 subscription. Although this is quite useful mechanism and it 2165 significantly saves on the number of sessions between the watcher and 2166 the presence server (as we show in the calculations of messages), 2167 this feature has the potential to make the scalability issue of 2168 presence systems harder and more complex. 2170 The reasons that resource lists may make the scalability problem of 2171 the presence server even more complex are: 2173 o Subscriptions and state - The resource list may contain reference 2174 to many other presence servers in many other domains. This 2175 requires the RLS to create subscriptions to other presence servers 2176 and buffer the state of all presentities in order to be able to 2177 provide the full state of the presentities in the list when 2178 needed. So in the overall system, the subscriptions that were 2179 saved between the watcher and the presence server are moved to the 2180 backend system while state has been duplicated between the various 2181 presence servers that serve the various presentities and the RLSs. 2182 This issue could have been mitigated if there was a way for the 2183 RLS to retrieve the presence information for many watchers while 2184 adhering to privacy when sending the actual notifications to the 2185 watchers. 2186 o Interlinkage - The resource list subscription will reach one RLS 2187 that will open it and send it to many presence servers and to 2188 other RLSs (if there is a subgroup inside the list). This way a 2189 complex linkage between the state of many components is created. 2190 This linkage makes state management and other maintenance of a 2191 presence systems quite complex. 2192 o Big lists are easy - There are two types of groups that may be 2193 used with this feature, private groups that are defined by/for 2194 each watcher and public groups that are defined in the system and 2195 can be used by any watcher. Although we should expect IT 2196 administrators to take caution when creating public groups, this 2197 may be not the case in real life. The connection between the size 2198 of the public group and the load on the presence server system may 2199 not apparent to everyone. Furthermore many public groups that are 2200 used in presence systems may have been created for other purposes 2201 as email systems (where the size of the lists was not so 2202 important) and are taken as they are to presence systems. So for 2203 example we may very easily find that a public group that actually 2204 covers all the users in the enterprise are used by many users in 2205 the enterprise thus creating unbearable load on the presence 2206 server. Note that this issue is not a protocol or design issue 2207 but more a usage issue that may have a real impact on the presence 2208 system. 2209 o Stopping notifications - A watcher may accidentally subscribe to a 2210 very big list and be overwhelmed by the amount of notifies that it 2211 receives from the presence server. There is no current way to 2212 stop this stream of notifies and even canceling the subscription 2213 may take time until being affective. 2215 The issues mentioned above are one example of an optimization that 2216 helps in one part of the system but creates even bigger problems in 2217 the overall system. There is a need to think about the problems 2218 listed above but more then that there is a need to make sure that 2219 when an optimization is introduced it does not create issues in other 2220 places. 2222 5. Current Optimizations 2224 This section lists and discusses several optimizations that are 2225 either already part of the SIP protocol or they have been suggested 2226 in various drafts. Several other optimizations that have been 2227 suggested but have not been discussed in any working group yet are 2228 summarized in [19] and in [21]. Note that trials with batched 2229 notifies optimization that is describes in [19], showed an 2230 improvement of 117% in the whole throughput of presence traffic. 2232 o Subnot-etags - Draft [17]. This draft suggests ways to suppress 2233 the sending of unnecessary notifies when for example a 2234 subscription is refreshed. This suggestion seems to be an 2235 efficient optimization since it saves both the number of messages 2236 sent and on the processing time of the presence server. 2237 o Resource List Service - [9] enable creating a single subscription 2238 session between the watcher and the presence server for 2239 subscribing on a list of users. This saves the amount of sessions 2240 that are created between watchers and presence servers. On the 2241 other hand, this mechanism enables creating very large amount of 2242 subscriptions in the presence server/RLS system thus enabling the 2243 creation of a very large number of subscriptions between presence 2244 servers and RLSs with relatively few clients especially if large 2245 public groups are used. It seems that in order to really optimize 2246 in this area, the usage of large public groups should not be 2247 considered as BCP and there should be a way for an RLS to create a 2248 single subscription for multiple occurrences of the same resource 2249 in resource lists. See consolidates subscriptions below. 2250 o Partial notify/publish - Drafts [12], [13] define a way for the 2251 subscriber to request getting only what was changed in the 2252 presence document and for the publisher of presence information to 2253 publish only what was changed in the presence document since the 2254 last publish. Although these optimizations help in reducing the 2255 amount of actual data that is sent from/to the presence server, 2256 these optimizations create additional processing burden on the 2257 presence server as was discussed above. 2258 o Filtering as defined in RFCs [7], [8] enables a watcher to request 2259 to be notified only when the presence document fulfills certain 2260 conditions. Although this optimization enables saving on the 2261 amount of messages that are sent from the presence server to the 2262 watcher, this optimization puts more burden on the processing time 2263 of the presence server as was discussed above. 2264 o Throttling [20] defines a mechanism in which a watcher requires to 2265 be updated only in certain intervals. Although this mechanism may 2266 give some extra load on the processing time of the presence 2267 server, that load is negligible and the reduction on the amount of 2268 messages sent from the presence server to the watchers is 2269 significant. This optimization is even more important with 2270 resource lists where there can be many resources in the resource 2271 lists and if the traffic of updates on resource list is not 2272 regulated, the watcher may get very large amount of notifications. 2273 o Presence specific sigcomp dictionary [15] defines a SIGCOMP [1] 2274 dictionary for presence. This optimization will enable to reduce 2275 the number of bytes that are transferred in presence systems by 2276 compressing the textual SIP messages and using the specialized 2277 presence dictionary the compression may be more significant then 2278 just using SIGCOMP as is. Note that number of actual messages 2279 will remain the same and a calculation of the amount of bytes that 2280 will be saved may be useful here. 2281 o Content Indirection [6] enables sending only the URI of the 2282 presence document to the watcher thus offloading the presence 2283 server from sending the presence document to the watcher. This 2284 optimization may be useful in some cases especially where there is 2285 a big number of users that get the same presence document. 2287 6. Summary 2289 Following is a summary of the various calculations. This is repeated 2290 here in order to ease the understanding of the conclusions that are 2291 listed below. 2293 The following table summarizes the various constants that are used in 2294 ALL calculations. 2296 (C01) Subscription lifetime (hours)...........................8 2297 (C03) Subscription refresh interval / hour....................1 2298 (C05) Number of dialogs to maintain per watcher = Number of 2299 federated presentities when dialog optimization is 2300 not used and to 1 when dialog optimization is used. 2301 (C07) SUBSCRIBE message size in bytes.......................450 2302 (C08) 200 OK for SUBSCRIBE message size in bytes............370 2303 (C09) NOTIFY message size not including presence doc........500 2304 (C10) 200 OK for NOTIFY message size in bytes...............370 2305 (C11) Size of an average presence document..........350 or 3000 2306 Calculations are done for both sizes 2307 (C12) Size of an average partial presence document..........200 2308 (C13) Additional data per document in RLMI..................160 2309 (C14) Multiparty boundary in RLMI document..................144 2310 (C15) XML root node in RLMI document........................144 2312 Figure 14: Constants in ALL calculations 2314 The following table summarizes the results of various optimization 2315 factors for the basic use case. 2317 C02 Presence state changes / hour.............................3 2318 C04 Total federated presentities per watcher..................4 2319 C06 Total # of watchers in the federated domains.........40,000 2321 No optimizations are applied 2323 (B01) Total of messages between domains..............12,800,000 2324 Total of bytes between domains (PD=350).....7,232,000,000 2325 Total of bytes between domains (PD=3000)...20,376,000,000 2326 (B02) Total number of messages / second.. ..................444 2327 Total of bytes per second (PD=350)................251,111 2328 Total of bytes per second (PD=3000)...............707,500 2329 (B03) Total number of by msgs per user/day......... ........320 2330 Total number of bytes per user/day (PD=350).......180,800 2331 Total number of bytes per user/day (PD=3000)......509,400 2333 Dialog optimization is applied 2335 (B01) Total of messages between domains...............8,480,000 2336 Total of bytes between domains (PD=350).....8,032,080,000 2337 Total of bytes between domains (PD=3000)...21,176,080,000 2338 (B02) Total number of messages / second.....................294 2339 Total of bytes per second (PD=350)................278,892 2340 Total of bytes per second (PD=3000)...............735,281 2341 (B03) Total number of by msgs per user/day..................212 2342 Total number of bytes per user/day (PD=350).......200,802 2343 Total number of bytes per user/day (PD=3000)......529,042 2345 Notify optimization is applied 2347 (B01) Total of messages between domains..............10,240,000 2348 Total of bytes between domains (PD=350).....5,670,400,000 2349 Total of bytes between domains (PD=3000)...15,422,400,000 2350 (B02) Total number of messages / second.....................356 2351 Total of bytes per second (PD=350)................196,889 2352 Total of bytes per second (PD=3000)...............535,500 2353 (B03) Total number of by msgs per user/day..................256 2354 Total number of bytes per user/day (PD=350).......141,760 2355 Total number of bytes per user/day (PD=3000)......385,560 2357 Dialog and notify optimizations are applied 2359 (B01) Total of messages between domains...............7,840,000 2360 Total of bytes between domains (PD=350).....6,824,400,000 2361 Total of bytes between domains (PD=3000)...16,576,400,000 2362 (B02) Total number of messages / second.....................272 2363 Total of bytes per second (PD=350)................236,958 2364 Total of bytes per second (PD=3000)...............575,569 2365 (B03) Total number of by msgs per user/day..................196 2366 Total number of bytes per user/day (PD=350).......170,610 2367 Total number of bytes per user/day (PD=3000)......414,410 2369 Figure 15: Basic use case 2371 The following table summarizes the results of various optimization 2372 factors for the widely distributed inter domain use case. 2374 C02 Presence state changes / hour.............................3 2375 C04 Total federated presentities per watcher.................20 2376 C06 Total # of watchers in the federated domains.........40,000 2378 No optimizations are applied 2380 (B01) Total of messages between domains..............64,000,000 2381 Total of bytes between domains (PD=350)....36,160,000,000 2382 Total of bytes between domains (PD=3000)..101,880,000,000 2383 (B02) Total number of messages / second...................2,222 2384 Total of bytes per second (PD=350)..............1,255,556 2385 Total of bytes per second (PD=3000).............3,537,500 2386 (B03) Total number of by msgs per user/day................1,600 2387 Total number of bytes per user/day (PD=350).......904,000 2388 Total number of bytes per user/day (PD=3000).....,547,000 2390 Dialog and notify optimizations are applied 2392 (B01) Total of messages between domains..............36,000,000 2393 Total of bytes between domains (PD=350)....32,755,920,000 2394 Total of bytes between domains (PD=3000)...81,515,920,000 2395 (B02) Total number of messages / second...................1,250 2396 Total of bytes per second (PD=350)..............1,137,358 2397 Total of bytes per second (PD=3000).............2,830,414 2398 (B03) Total number of by msgs per user/day..................900 2399 Total number of bytes per user/day (PD=350).......818,898 2400 Total number of bytes per user/day (PD=3000)....2,037,898 2402 Figure 16: Widely distributed inter-domain 2404 The following table summarizes the results of various optimization 2405 factors for the intra-domain peering use case. 2407 C02 Presence state changes / hour.............................3 2408 C04 Total federated presentities per watcher.................10 2409 C06 Total # of watchers in the federated domains........120,000 2411 No optimizations are applied 2413 B01 Total of messages between domains................96,000,000 2414 Total of bytes between domains (PD=350)........54,240,000,000 2415 Total of bytes between domains (PD=3000)......152,820,000,000 2416 B02 Total number of messages / second.....................3,333 2417 Total of bytes per second (PD=350)..................1,883,333 2418 Total of bytes per second (PD=3000).................5,306,250 2419 B03 Total number of by msgs per user/day....................800 2420 Total number of bytes per user/day (PD=350)...........452,000 2421 Total number of bytes per user/day (PD=3000)........1,273,500 2423 Dialog and notify optimizations are applied 2425 (B01) Total of messages between domains..............55,200,000 2426 Total of bytes between domains (PD=350)....49,646,160,000 2427 Total of bytes between domains (PD=3000)..122,796,160,000 2428 (B02) Total number of messages / second...................1,917 2429 Total of bytes per second (PD=350)..............1,723,825 2430 Total of bytes per second (PD=3000).............4,263,408 2431 (B03) Total number of by msgs per user/day..................460 2432 Total number of bytes per user/day (PD=350).......413,718 2433 Total number of bytes per user/day (PD=3000)....1,023,218 2435 Figure 17: Inter-domain peering 2437 The following table summarizes the results of various optimization 2438 factors for the very large scale peering networks use case. 2440 C02 Presence state changes / hour.............................6 2441 C04 Total federated presentities per watcher.................10 2442 C06 Total # of watchers in the federated domains.....20,000,000 2444 No optimizations are applied 2446 (B01) Total of messages between domains..........25,600,000,000 2447 Total of bytes bet. domains (PD=350)...14,896,000,000,000 2448 Total of bytes bet. domains (PD=3000)..44,046,000,000,000 2449 (B02) Total number of messages / second.................888,889 2450 Total of bytes per second (PD=350)............517,222,222 2451 Total of bytes per second (PD=3000).........1,529,375,000 2452 (B03) Total number of by msgs per user/day................1,280 2453 Total number of bytes per user/day (PD=350).......744,800 2454 Total number of bytes per user/day (PD=3000)....2,202,300 2456 Dialog and notify optimizations are applied 2458 (B01) Total of messages between domains..........18,800,000,000 2459 Total of bytes bet. domains (PD=350)...16,971,960,000,000 2460 Total of bytes bet. domains (PD=3000)..41,881,960,000,000 2461 (B02) Total number of messages / second.................652,778 2462 Total of bytes per second (PD=350)............589,304,167 2463 Total of bytes per second (PD=3000).........1,454,234,722 2464 (B03) Total number of by msgs per user/day..................940 2465 Total number of bytes per user/day (PD=350).......848,598 2466 Total number of bytes per user/day (PD=3000)....2,094,098 2468 Partial and notify optimizations are applied 2470 (B01) Total of messages between domains..........22,400,000,000 2471 Total of bytes bet. domains (PD=350)...11,564,000,000,000 2472 Total of bytes bet. domains (PD=3000)..12,094,000,000,000 2473 (B02) Total number of messages / second.................777,778 2474 Total of bytes per second (PD=350)............401,527,778 2475 Total of bytes per second (PD=3000)...........419,930,556 2476 (B03) Total number of by msgs per user/day................1,120 2477 Total number of bytes per user/day (PD=350).......578,200 2478 Total number of bytes per user/day (PD=3000)......604,700 2480 TCP only SIP+Partial+Dialog optimizations 2482 (B01) Total of messages between domains...........9,260,000,000 2483 Total of bytes between domains (PD=350).8,809,080,000,000 2484 Total of bytes bet. domains (PD=3000)...9,339,080,000,000 2485 (B02) Total number of messages / second.................321,528 2486 Total of bytes per second (PD=350)............305,870,833 2487 Total of bytes per second (PD=3000)...........324,273,611 2488 (B03) Total number of by msgs per user/day..................463 2489 Total number of bytes per user/day (PD=350).......440,454 2490 Total number of bytes per user/day (PD=3000)......466,954 2492 TCP only SIP+Partial optimizations 2494 (B01) Total of messages between domains...........9,800,000,000 2495 Total of bytes between domains (PD=350).3,380,000,000,000 2496 Total of bytes bet. domains (PD=3000)...3,910,280,000,000 2497 (B02) Total number of messages / second.................340,278 2498 Total of bytes per second (PD=350)............117,361,111 2499 Total of bytes per second (PD=3000)...........135,763,889 2500 (B03) Total number of by msgs per user/day..................490 2501 Total number of bytes per user/day (PD=350).......169,000 2502 Total number of bytes per user/day (PD=3000)......195,500 2503 Figure 18: Very large scale peering networks 2505 7. Conclusions 2507 The following conclusions can be drawn from the above numbers: 2509 o Due to the overhead of RLMI, the dialog optimization does not help 2510 in reducing the number of bytes nor in the number of the messages. 2511 It seems to be more important from the point of view of the 2512 convenience of the user since it enables the user to manage his/ 2513 hers watch list on e.g. a web page. 2514 o The notify optimization optimizes both the number of messages and 2515 the number of bytes. 2516 o Partial notification saves a lot in the number of bytes especially 2517 when the presence document is a rich presence document which is 2518 relatively big. 2519 o Comparing to very optimized SIP protocol (imaginary TCP only SIP) 2520 shows that the number of messages is less by about a half. The 2521 number of bytes is also reduced by about a half. 2522 o When looking at the numbers from the perspective of the number of 2523 bytes that a user "consumes" per day the numbers may not look so 2524 big. Nevertheless, we should remember that the overall affect on 2525 the network may be quite big since the network will have to convey 2526 dozens of Giga bytes per day for the modest use cases that are 2527 described in this document for presence traffic only. Recalling 2528 that presence is only an enabler for other media these numbers are 2529 not so easy to handle. 2531 The document analyzes the scalability of presence systems and of the 2532 SIP based in particular. It is apparent that the scalability of 2533 these systems is far from being trivial from several perspectives: 2534 number of messages, network bandwidth, state management and CPU load. 2536 As part of the analysis we have analyzed several optimizations and 2537 showed the effect of these optimizations on the number of messages 2538 and the number of bytes that are sent between the federating domains. 2540 We have also computed the number of messages and bytes for a very 2541 large scale peering network while assuming a protocol that has much 2542 less overhead then SIP. Even in that protocol we got relatively high 2543 numbers. 2545 It is very possible that the issues that are described in this 2546 document are inherent to presence systems in general and not specific 2547 to the SIMPLE protocol. Organizations need to be prepared to invest 2548 a lot in network and hardware in order to create real big systems. 2549 However, it is apparent that not all the possible optimizations were 2550 done yet and further work is needed in the IETF in order to provide 2551 better scalability 2553 Nevertheless, we should remember that SIP was originally designed for 2554 end to end session creation and number and size of messages are of 2555 secondary importance for end to end session negotiation. For large 2556 scale and especially for very 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 will 2563 be very 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 very optimized for the 2570 load and can assume some assumptions about the network (e.g. do not 2571 use unreliable protocol as UDP but only TCP). 2573 When servers is connecting to another server using current protocol, 2574 there will be an extreme number of redundant messages due to the 2575 overhead of supporting UDP and to the need to send multiple presence 2576 documents for the same watched user due to privacy issue. A server 2577 to server protocol will have to address these issues. Some initial 2578 work to address these issues can be found in: [19], [21] and [22] 2580 Another issue that is more concerning protocol design is whether 2581 NOTIFY messages should not be considered as media as audio, video and 2582 even text messaging are considered? The SUBSCRIBE can be extended to 2583 do similar three way handshake as INVITE and negotiate where the 2584 notify messages should go, rate and other parameters. This way the 2585 load can be offloaded to a specialized NOTIFY "relays" thus not 2586 loading the control path of SIP. One of the possible ideas (Marc 2587 Willekens) is to use the SIP stack for the client/server NOTIFY but 2588 make use of a more optimized and controllable protocol for the 2589 server-to-server interface. Another possibility is to use the MSRP 2590 [10], [11]protocol for the notifies. 2592 8. Security Considerations 2594 This document discusses scalability issues with the existing SIP/ 2595 SIMPLE presence protocol and model. Therefore, there are no security 2596 considerations to be considered for this document. However, a lot of 2597 the possible optimizations that should emerge as a result of this 2598 document will have security implications that will need to be solved. 2600 9. IANA Considerations 2602 This document has no actions for IANA. 2604 10. Changes from Previous Versions 2606 10.1. Changes in version 05 2608 o Fixed mistakes in calculations that were found by Victoria 2609 Beltran-Martinez, both relate to dialog optimizations. One 2610 mistake was not including the multipart boundary of the resource 2611 list itself in S03 when dialog optimizations were used. The other 2612 one was assuming in T07 that only a single presentity is returned 2613 in termination in T07 calculation. 2614 o Fixed nits that were referred to me by Robert Sparks 2616 10.2. Changes in version 04 2618 o Fixed mistake in the formula of I07 and S08 (RLMI was not 2619 included). Affect on total number of bytes was very small. 2620 o Fixed mistake in the text of the calculation of number of bytes 2621 for S08 for non dialog optimization. No actual change in number 2622 of bytes since the excel file calculations were done correctly. 2623 o Removed general references throughout the text to "other 2624 protocols". This was done in order to avoid the impression that 2625 the document tries to compare SIP protocol with any other presence 2626 base protocol. 2627 o Several other editorial and clarification changes 2629 10.3. Changes in version 03 2631 o Added some input from real life deployments and input on a test 2632 with batched notifies. 2633 o Added Calculations of messages and bytes per user. 2634 o Calculations are now done both for minimal size of presence 2635 document and for an average size of rich presence document. 2636 o Comparison with other protocol is now done using small, tiny and 2637 rich presence document sizes. 2638 o Removed dialog optimization with partial notification since it is 2639 not relevant 2640 o Fixed a few issues in calculations that were found by Victoria 2641 Beltran-Martinez. 2643 * Added overhead for RLMI for dialog optimizations (list 2644 subscription). This calculation fix actually shows that dialog 2645 optimization is not a real optimization from the point of view 2646 of bytes and number of messages. 2647 * When NOTIFY optimizations are applied no need for final NOTIFY 2648 * The usage of RLS between domains was clarified. 2649 o Significantly enhanced the conclusions section 2650 o Several typo fixes 2652 10.4. Changes in version 02 2654 o Fixed a bug in the calculations. Thanks to Marc Willekens for 2655 finding the bug. 2657 10.5. Changes in version 01 2659 o Clarifications and corrections of the computation model and the 2660 computations. 2661 o Added several more computations to show the influence of different 2662 optimizations. 2663 o The requirements were moved to [18] 2664 o The new suggestions for optimizations were moved to [19] 2666 11. Acknowledgments 2668 We would like to thank Jonathan Rosenberg, Ben Campbell, Robert 2669 Sparks, Markus Isomaki Piotr Boni, David Viamonte, Aki Niemi and 2670 Peter-Saint Andre for ideas and input. Special thanks to Marc 2671 Willekens and Victoria Beltran-Martinez for finding several issues in 2672 the calculations. 2674 12. Informational References 2676 [1] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, 2677 Z., and J. Rosenberg, "Signaling Compression (SigComp)", 2678 RFC 3320, January 2003. 2680 [2] Rosenberg, J., "A Watcher Information Event Template-Package 2681 for the Session Initiation Protocol (SIP)", RFC 3857, 2682 August 2004. 2684 [3] Rosenberg, J., "An Extensible Markup Language (XML) Based 2685 Format for Watcher Information", RFC 3858, August 2004. 2687 [4] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and 2688 J. Peterson, "Presence Information Data Format (PIDF)", 2689 RFC 3863, August 2004. 2691 [5] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, 2692 "RPID: Rich Presence Extensions to the Presence Information 2693 Data Format (PIDF)", RFC 4480, July 2006. 2695 [6] Burger, E., "A Mechanism for Content Indirection in Session 2696 Initiation Protocol (SIP) Messages", RFC 4483, May 2006. 2698 [7] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 2699 Requena, "Functional Description of Event Notification 2700 Filtering", RFC 4660, September 2006. 2702 [8] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 2703 Requena, "An Extensible Markup Language (XML)-Based Format for 2704 Event Notification Filtering", RFC 4661, September 2006. 2706 [9] Roach, A., Campbell, B., and J. Rosenberg, "A Session 2707 Initiation Protocol (SIP) Event Notification Extension for 2708 Resource Lists", RFC 4662, August 2006. 2710 [10] Campbell, B., Mahy, R., and C. Jennings, "The Message Session 2711 Relay Protocol (MSRP)", RFC 4975, September 2007. 2713 [11] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the 2714 Message Sessions Relay Protocol (MSRP)", RFC 4976, 2715 September 2007. 2717 [12] Lonnfors, M., Costa-Requena, J., Leppanen, E., and H. 2718 Khartabil, "Session Initiation Protocol (SIP) Extension for 2719 Partial Notification of Presence Information", RFC 5263, 2720 September 2008. 2722 [13] Niemi, A., Lonnfors, M., and E. Leppanen, "Publication of 2723 Partial Presence Information", RFC 5264, September 2008. 2725 [14] Rosenberg, J., "Presence Authorization Rules", RFC 5025, 2726 December 2007. 2728 [15] Garcia-Martin, M., "The Presence-Specific Static Dictionary for 2729 Signaling Compression (Sigcomp)", RFC 5112, January 2008. 2731 [16] Camarillo, G., "Subscriptions to Request-Contained Resource 2732 Lists in the Session Initiation Protocol (SIP)", 2733 draft-ietf-sipping-uri-list-subscribe-05 (work in progress), 2734 May 2006. 2736 [17] Niemi, A., "An Extension to Session Initiation Protocol (SIP) 2737 Events for Conditional Event Notification", 2738 draft-ietf-sip-subnot-etags-03 (work in progress), July 2008. 2740 [18] Houri, A., Parameswar, S., Aoki, E., Singh, V., and H. 2741 Schulzrinne, "Scaling Requirements for Presence in SIP/SIMPLE", 2742 draft-ietf-sipping-presence-scaling-requirements-01 (work in 2743 progress), July 2008. 2745 [19] Houri, A., "Scaling Optimizations for Presence in SIP/SIMPLE", 2746 draft-houri-simple-interdomain-scaling-optimizations-00 (work 2747 in progress), July 2007. 2749 [20] Niemi, A., Kiss, K., and S. Loreto, "Session Initiation 2750 Protocol (SIP) Event Notification Extension for Notification 2751 Throttling", draft-niemi-sipping-event-throttle-07 (work in 2752 progress), October 2008. 2754 [21] Rosenberg, J., Donovan, S., and K. McMurry, "Optimizing 2755 Federated Presence with View Sharing", 2756 draft-ietf-simple-view-sharing-01 (work in progress), 2757 July 2008. 2759 [22] Rosenberg, J., Houri, A., and C. Smyth, "Models for Intra- 2760 Domain Presence and Instant Messaging (IM) Federation", 2761 draft-ietf-simple-intradomain-federation-01 (work in progress), 2762 July 2008. 2764 Authors' Addresses 2766 Avshalom Houri 2767 IBM 2768 Science Park 2769 Rehovot, 2770 Israel 2772 Email: avshalom@il.ibm.com 2774 Edwin Aoki 2775 AOL LLC 2776 401 Ellis St. 2777 Mountain View, CA 94043 2778 USA 2780 Email: aoki@aol.net 2781 Sriram Parameswar 2782 Microsoft Corporation 2783 One Microsoft Way 2784 Redmond, WA 98052 2785 USA 2787 Email: Sriram.Parameswar@microsoft.com 2789 Tim Rang 2790 Microsoft Corporation 2791 One Microsoft Way 2792 Redmond, WA 98052 2793 USA 2795 Email: timrang@microsoft.com 2797 Vishal Singh 2798 Columbia University 2799 Department of Computer Science 2800 450 Computer Science Building 2801 New York, NY 10027 2802 US 2804 Email: vs2140@cs.columbia.edu 2805 URI: http://www.cs.columbia.edu/~vs2140 2807 Henning Schulzrinne 2808 Columbia University 2809 Department of Computer Science 2810 450 Computer Science Building 2811 New York, NY 10027 2812 US 2814 Phone: +1 212 939 7004 2815 Email: hgs+ecrit@cs.columbia.edu 2816 URI: http://www.cs.columbia.edu/~hgs 2818 Full Copyright Statement 2820 Copyright (C) The IETF Trust (2008). 2822 This document is subject to the rights, licenses and restrictions 2823 contained in BCP 78, and except as set forth therein, the authors 2824 retain all their rights. 2826 This document and the information contained herein are provided on an 2827 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2828 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2829 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2830 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2831 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2832 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2834 Intellectual Property 2836 The IETF takes no position regarding the validity or scope of any 2837 Intellectual Property Rights or other rights that might be claimed to 2838 pertain to the implementation or use of the technology described in 2839 this document or the extent to which any license under such rights 2840 might or might not be available; nor does it represent that it has 2841 made any independent effort to identify any such rights. Information 2842 on the procedures with respect to rights in RFC documents can be 2843 found in BCP 78 and BCP 79. 2845 Copies of IPR disclosures made to the IETF Secretariat and any 2846 assurances of licenses to be made available, or the result of an 2847 attempt made to obtain a general license or permission for the use of 2848 such proprietary rights by implementers or users of this 2849 specification can be obtained from the IETF on-line IPR repository at 2850 http://www.ietf.org/ipr. 2852 The IETF invites any interested party to bring to its attention any 2853 copyrights, patents or patent applications, or other proprietary 2854 rights that may cover technology that may be required to implement 2855 this standard. Please address the information to the IETF at 2856 ietf-ipr@ietf.org.