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