idnits 2.17.1 draft-ietf-simple-interdomain-scaling-analysis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2670. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2681. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2688. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2694. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 18, 2007) is 6001 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 2500, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 2505, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '2') (Obsoleted by RFC 6665) == Outdated reference: A later version (-10) exists of draft-ietf-simple-partial-notify-09 == Outdated reference: A later version (-07) exists of draft-ietf-simple-partial-publish-06 == Outdated reference: A later version (-03) exists of draft-ietf-sip-subnot-etags-01 == Outdated reference: A later version (-08) exists of draft-niemi-sipping-event-throttle-05 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 8 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: May 21, 2008 AOL LLC 6 S. Parameswar 7 T. Rang 8 Microsoft Corporation 9 V. Singh 10 H. Schulzrinne 11 Columbia U. 12 November 18, 2007 14 Presence Interdomain Scaling Analysis for SIP/SIMPLE 15 draft-ietf-simple-interdomain-scaling-analysis-03.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on May 21, 2008. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 46 Abstract 48 The document analyzes the traffic that is generated due to presence 49 subscriptions between domains. It is shown that the amount of 50 traffic can be extremely big. In addition to the very large traffic 51 the document also analyzes the affects of a large presence system on 52 the memory footprint and the CPU load. Current approved and in work 53 optimizations to the SIMPLE protocol are analyzed with the possible 54 impact on the load. Separate documents contain the requirements for 55 optimizations and suggestions for new optimizations. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Message Load . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.1. Known Optimizations . . . . . . . . . . . . . . . . . . . 5 62 2.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.3. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 2.3.1. Constants . . . . . . . . . . . . . . . . . . . . . . 7 65 2.3.2. Initial Messages . . . . . . . . . . . . . . . . . . . 9 66 2.3.3. Steady State Messages . . . . . . . . . . . . . . . . 10 67 2.3.4. Termination Messages . . . . . . . . . . . . . . . . . 11 68 2.3.5. Bottom Line . . . . . . . . . . . . . . . . . . . . . 11 69 2.3.6. Rush Hour Calculations . . . . . . . . . . . . . . . . 12 70 2.4. SIMPLE with no optimizations . . . . . . . . . . . . . . . 12 71 2.5. SIMPLE with dialog optimization . . . . . . . . . . . . . 14 72 2.6. SIMPLE with NOTIFY optimization . . . . . . . . . . . . . 16 73 2.7. SIMPLE with Dialog & NOTIFY optimizations . . . . . . . . 18 74 2.8. Presence Federations . . . . . . . . . . . . . . . . . . . 20 75 2.8.1. Widely distributed inter-domain presence . . . . . . . 21 76 2.8.2. Associated inter-domain presence . . . . . . . . . . . 25 77 2.8.3. Very large network peering . . . . . . . . . . . . . . 26 78 2.8.4. Intra-domain peering . . . . . . . . . . . . . . . . . 30 79 2.9. Partial Notifications Optimization . . . . . . . . . . . . 35 80 2.10. Other Protocols . . . . . . . . . . . . . . . . . . . . . 37 81 3. State Management . . . . . . . . . . . . . . . . . . . . . . . 39 82 3.1. State Size Calculations . . . . . . . . . . . . . . . . . 40 83 3.1.1. Tiny System . . . . . . . . . . . . . . . . . . . . . 40 84 3.1.2. Medium System . . . . . . . . . . . . . . . . . . . . 41 85 3.1.3. Large System . . . . . . . . . . . . . . . . . . . . . 41 86 3.1.4. Very Large System . . . . . . . . . . . . . . . . . . 41 87 4. Processing complexities . . . . . . . . . . . . . . . . . . . 42 88 4.1. Aggregation . . . . . . . . . . . . . . . . . . . . . . . 42 89 4.2. Partial Publish and Notify . . . . . . . . . . . . . . . . 42 90 4.3. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 43 91 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 43 92 4.5. Resource List Service . . . . . . . . . . . . . . . . . . 43 93 5. Current Optimizations . . . . . . . . . . . . . . . . . . . . 45 94 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 95 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 51 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . 53 97 9. Changes from Previous Versions . . . . . . . . . . . . . . . . 54 98 9.1. Changes in version 03 . . . . . . . . . . . . . . . . . . 54 99 9.2. Changes in version 02 . . . . . . . . . . . . . . . . . . 54 100 9.3. Changes in version 01 . . . . . . . . . . . . . . . . . . 54 101 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54 102 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 103 11.1. Normative References . . . . . . . . . . . . . . . . . . . 55 104 11.2. Informational References . . . . . . . . . . . . . . . . . 55 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57 106 Intellectual Property and Copyright Statements . . . . . . . . . . 59 108 1. Introduction 110 The document analyzes the traffic that is generated due to presence 111 subscriptions between domains. It is shown that the number of 112 messages and the amount of data sent can be extremely big. In 113 addition to the very large traffic the document also analysis the 114 affects of a large presence system on the memory footprint and the 115 CPU load. Current approved and in work optimizations to the SIMPLE 116 protocol are analyzed with the possible impact on the load. Other 117 documents contain the requirements for optimizations [21] and 118 suggestions for new optimizations are included in the following 119 documents: [22]. [24] 121 This document is intended to be drive work on possible solutions that 122 will make the deployment of a presence server more reasonable task. 123 Although a comparison to another protocol is given in the document, 124 the intention of the document is not try to compare the SIP based 125 presence protocol to other types of presence protocols but only to 126 analyze the SIP based presence protocol. It is very likely that that 127 the scalability issues are inherent to the deployment of presence 128 systems and not to a certain protocol. 130 The document discusses the following areas. In each area we try to 131 show the complexity and the load that the presence server has to 132 handle in order to provide its service. 134 o Messages load - By computing the number of messages that are 135 required for connecting presence systems the document shows that 136 the number of messages is very big and it is quite obvious that 137 some optimizations are needed. In addition we also show that the 138 bandwidth required is also very big. 139 o State management - Due to the nature of the service that the 140 presence server provides, the presence server has to manage a 141 relatively big and complex state and some computations are 142 provided in the document. 143 o Processing complexities - The presence server maintains many small 144 objects and has to do frequent operations on these objects. We 145 show that these operations and especially the optimizations that 146 are intended to save on the amount of data that is being sent 147 between watchers and presence servers, are not so simple and may 148 create a very heavy processing load on the presence server. 149 o Groups - Resource List Servers [12] optimize the number of 150 sessions that are created between the watchers and the presence 151 server. On the other hand, this optimization may create an 152 exponential size of subscription due to the unbearable ease of 153 subscribing to large groups. 155 The term presence domain or presence system appears in the document 156 several time. By this term we refer to a presence server that 157 provides presence subscription and notification services to its 158 users. The system can be a system that is deployed in a small 159 enterprise or in a very large consumer network. 161 2. Message Load 163 Some optimizations are approved or are being defined for the SIP 164 presence protocol, but even with these optimizations a very large 165 number of messages & large bandwidth are needed in order to establish 166 federation between presence systems of large communities. Further 167 thinking is needed in order to make large deployment of presence 168 systems less resource demanding. 170 Note that even though this document talks about inter domain traffic, 171 the introduction of resource list servers (RLSs) [12] introduce very 172 similar traffic pattern in intra-domain and in inter-domain. See 173 detailed discussion on resource lists in Section 4.5. 175 2.1. Known Optimizations 177 The current optimizations that are approved or are approved as 178 working group items in the SIMPLE working group can be divided into 179 two categories: 181 o Dialogs saving optimization - Here we refer to optimizations as 182 the resource list RFC [12] or to the URI list subscriptions draft 183 [19]. These documents define ways to reduce the number of dialogs 184 that are required between the subscriber and the presence system. 186 Note that dialog optimization or RLS usage as it is used in 187 this document refers to the usage of a URI that represents a 188 list of a URI list between domains and not within the same 189 domain. An example is a user Alice in domain example.org that 190 subsides to URI of e.g. external-reps-list at example.com or 191 uses a URI list to subscribe at on her watch list in 192 example.com. Note also that when calculating the traffic that 193 is due to RLS within a domain the traffic between the RLS and 194 the presence agents should also be taken into account. 195 However, since in this document we are mostly dealing with 196 inter- domain traffic, the traffic between the RLS and the 197 presence agents was not taken into account. 198 o 199 Notification optimizations - Here we refer to the optimizations 200 that are suggested in the subnot-etags draft [20]. This draft 201 suggests ways to suppress the sending of unnecessary notifies when 202 for example a subscription is refreshed. There are other drafts 203 that reduce the size of messages as partial notifications or 204 filtering but in this document we mostly care about the amount of 205 messages & bandwidth so the partial optimizations can help a bit 206 in the bandwidth but will not help in the number of messages. 208 2.2. Assumptions 210 In the document we have several assumptions regarding size of 211 messages, rate of presence change and more. It should be noted that 212 these assumptions are not directly based on rigorous statistics that 213 was done on actual SIP based deployments of presence systems but more 214 from some experience on other types of presence based systems. 216 In a large consumer network we have seen the following patterns: 218 o Approximately 110 users in the watch list in average. 219 o There are approximately 12 billion status changes a day (139k/ 220 second) across the network. Of these, when a proprietary binary 221 protocol is used to convey the status changes the average of the 222 message is about 188 bytes. When SIP NOTIFY is used the average 223 is about 1228 bytes for the message. 224 o The average of logins/logouts in the system is about 2000 logins 225 per second and about 4000 logouts per second. When something 226 happens - either a promotion, contest, or a network hiccup that 227 causes many users to login and logout simultaneously, there are 228 about 20,000 logins per second. 229 o The peak of the instant messages sent is about 50,000 messages per 230 second. 232 In a deployment in enterprises we have seen the following patterns: 234 o Averages watch list size was 200 users. 235 o About half of the registered users were online at peak time 236 o Status change per hour was 2 changes per hour. 237 o The average logins/logouts in the system was about 5 logins per 238 second with additional 15 logins/logouts during start/end of day 239 rush hours. 241 Even though the assumptions in this document are not based on 242 rigorous statistical data the target here is not to analyze specific 243 system but show that even with VERY moderate assumptions (which are 244 even less then the observations mentioned above), the number of 245 messages, the network bandwidth, the required state management and 246 the load on the CPU is very high. Real life systems should have a 247 much bigger scalability requirements. for example the presence state 248 change that we assumed (one presence state change per hour) is maybe 249 one of the most moderate assumptions that we have taken. Experience 250 from consumer networks show that the frequency here is much bigger 251 and especially with the younger generation. In an environment where 252 a user may have several devices and other resources for presence 253 information as geographical location and calendar the frequency of 254 presence state changes will be much higher. 256 It is very hard to measure presence load since the behavior of users 257 is very different. Some users will have a very small number of 258 presentities in their watch list while others may have hundreds. 259 Some users will change their state a lot and have many sources of 260 presence information while others may have very small number of 261 changes during the day. In addition the "rush hour" calculations of 262 when the day starts and ends were not included yet in this document. 263 Rush hour differs between different enterprises and is still 264 different in the consumer presence systems. It is very hard if not 265 impossible to take into a static model all the possible combinations. 267 2.3. Analysis 269 The basic SIMPLE subscription dialog involves the following message- 270 transfer: 272 o SUBSCRIBE/200 273 o Initial NOTIFY/200 274 o (j) NOTIFY/200 where 'j' is the number of presence changes seen by 275 the watcher 276 o (k) SUBSCRIBE/200 where 'k' is the number of subscription dialog 277 refresh periods 278 o SUBSCRIBE/200 with Expires = 0 to terminate the dialog 279 o NOTIFY/200 ending the dialog 281 An individual watcher will generate X number of SIMPLE subscription 282 dialogs corresponding to the number of presentities it chooses to 283 watch. The amount of traffic generated is significantly affected by 284 several factors: 286 o Number of watchers connected to the system 287 o Number of presentities connected to the system 288 o Frequency of changes to presence information 290 This document contains several calculations that show the expected 291 message rate and bandwidth between presence domains. The following 292 sections explain the assumptions and methods behind the calculations. 294 2.3.1. Constants 296 The following are number of "constants" that we use in the 297 calculations. Some of the constants are used throughout the 298 calculation while other change between use cases 299 o (C01) Subscription lifetime (hours)- The assumed lifetime of a 300 subscription in hours. We assume 8 hours for all calculations. 301 o (C02) Presence state changes / hour - The average time that a 302 presentity changes his/hers status in one hour. We assumed 3 303 times per hour for most calculations. Note that for some users in 304 consumer messaging systems, the actual number of changes is likely 305 to be much higher. 306 o (C03) Subscription refresh interval / hour - The duration of the 307 SUBSCRIBE session after which it needs to be refreshed. We 308 assumed that the duration is one hour. 309 o (C04) Total federated presentities per watcher - The number of 310 presentities that the watcher is watching. The number here 311 changes in this document according to the type of the specific 312 deployment. 313 o (C05) Number of dialogs to maintain per watcher - The number of 314 the SUBSCRIBE dialogs that are maintained per watcher. if a dialog 315 optimization is not assumed this number is equal to A04, otherwise 316 it is 1. 317 o (C06) Total number of watchers in the federated presence domains. 318 The number here is the number of all watchers in all the federated 319 domains. 320 o (C07) SUBSCRIBE message size in bytes. We assume 450 bytes in all 321 calculations. The size is based on a typical SUBSCIRBE taken from 322 RFCs. 323 o (C08) 200 OK for SUBSCRIBE message size in bytes. We assume 370 324 bytes in all calculations. The size is based on a typical 200 OK 325 taken from RFCs. 326 o (C09) NOTIFY message size not including the presence document. 327 The size of this message for a single presentity is assumed to be 328 500 bytes for the NOTIFY message itself (based on sizes from 329 examples in RFCs). 330 o (C10) 200 OK for NOTIFY message size in bytes. We assume 370 331 bytes in all calculations. The size is based on a typical 200 OK 332 taken from RFCs. 333 o (C11) Size of an average presence document. In the previous 334 version of this document we have used only the size of 3000 bytes 335 for a presence document. This number was calculated based on 336 examples of rich presence document in RFCs. Due to discussion in 337 the SIMPLE list where it was claimed that it may be too big and 338 due to the fact that we are talking here about federation between 339 communities where the rich presence document may be of less use, 340 we have done all the calculations with two sizes of presence 341 document. One size is the minimal size of the PIDF [6] document 342 which was taken to be 350 bytes based on examples from RFCs and 343 the other size is the 3000 bytes for rich presence document [8]. 344 It should be noted that assuming 3000 bytes for presence document 345 is relatively modest if we take into account multiple devices and 346 location information. 348 o (C12) The size of NOTIFY when partial [15] notification is being 349 done. We have taken this size to be 200 bytes. The size is much 350 smaller then the example that is given in [15] but the example 351 given there assumes multiple changes in the presence document and 352 here we assume a single change. 354 When dialog optimization [12] is used, an RLMI document is 355 being sent and that document contains the presence documents 356 for the users that are in the watch list. In previous version 357 of this document we have omitted the overhead of the RLMI 358 document. This "bug" was found by Victoria Beltran-Martinez 359 and is being fixed in this document by adding the constants 360 C13, C14 and C15 to the calculations 361 o 362 (C13) Item size per each contact in RLMI document, 160 bytes. 363 o (C14) The size of the multipart boundary (per each contact) in 364 RLMI notifications, 144 bytes. 365 o (C15) The size of the XML root node in RLMI document (once per 366 notification), 144 bytes. 368 2.3.2. Initial Messages 370 The following are the calculations for the messages in the initial 371 phase of the establishment of the subscriptions. The calculations 372 contain both number of messages and the number of bytes. 374 o (I01) Number of initial SUBSCRIBE messages per watcher = C05. 375 o (I02) Number of initial 200 OK messages for SUBSCRIBE messages per 376 watcher = C05. 377 o (I03) Number of initial NOTIFY messages per watcher = C05. 378 o (I04) Number of initial 200 OK messages for NOTIFY messages per 379 watcher = C05. 380 o (I05) Total number and bytes of initial SUBSCRIBE messages for all 381 watchers = Number - I01*C06, Bytes - I01*C06*C07. 382 o (I06) Total number and bytes of initial 200 OK for SUBSCRIBE 383 messages for all watchers = Number - I01*C06, Bytes - I01*C06*C08. 384 o (I07) Total number and bytes of initial NOTIFY messages for all 385 watchers = Number - I01*C06, The calculation for the number of 386 bytes is different when dialog optimization is used or not. When 387 dialog optimization is not applied the number of bytes will be 388 calculated by: (I01*C06*C09)+(I01*C06*C11) and when dialog 389 optimization is applied the number of bytes will be calculated by 390 (I01*C06*(C09+C15))+(I01*C06*C04*(C11+C13+C14)). 391 o (I08) Total number and bytes of initial 200 OK for NOTIFY messages 392 for all watchers = Number - I04*C06, Bytes - I04*C06*C10. 393 o (I09) Total number and bytes of initial messages per day = Number 394 - numbers in I05+I06+I07+I08, Size -sizes in I05+I06+I07+I08. 396 2.3.3. Steady State Messages 398 Here we describe the calculations for the steady state messages. 399 Steady state is the time between the initial subscription and the 400 tear down of the subscription. It contains the notifies due to state 401 change and the subscription refreshes. 403 o (S01) NOTIFY messages due to state change per watched presentity 404 per day (less 2 since the NOTIFY for initial and terminating state 405 is calculated in the initial and terminating calculations) = 406 (C02*C01-2). 407 o (S02) 200 (for NOTIFY due to state change) messages per watched 408 presentity per day (less 2 since the NOTIFY for initial and 409 terminating state is calculated in the initial and terminating 410 calculations) = (C02*C01-2). 411 o (S03) Total number and size of messages due to state change per 412 day = Number - (S01+S02)*C06*C04. The calculation for the number 413 of bytes is different when dialog optimization is used or not. 414 When dialog optimization is not applied the number of bytes will 415 be calculated by: (C06*C04)*((S01*(C09+C11))+(S02*C10)) and when 416 dialog optimization is applied the number of bytes will be 417 calculated by (C06*C04)*((S01*(C09+C11+C13+C14+C15))+(S02*C10)). 418 Note that for dialog optimization it is assumed that only a single 419 presentity is changed and partial state notification is used. 420 o (S04) Number of SUBSCRIBE messages for refreshes per watcher per 421 day = ((C01/C03)-1)*C05. One is subtracted since the termination 422 is calculated separately. for example if there are 8 hours in the 423 day and a refresh should occur every hour, there are 7 refreshes 424 during the day and not 8. 425 o (S05) Number of 200 OK messages for SUBSCRIBE messages for 426 refreshes per watcher per day = ((C01/C03)-1)*C05. 427 o (S06) Number of NOTIFY messages for refreshes per watcher per day 428 = ((C01/C03)-1)*C05. Since when NOTIFY optimization is used [20] 429 there is no need to send NOTIFY for refreshes, S06 will be zero 430 when NOTIFY optimizations is used. 431 o (S07) Number of 200 OK messages for NOTIFY messages for refreshes 432 per watcher per day = ((C01/C03)-1)*C05. Since when NOTIFY 433 optimization is used [20] there is no need to send NOTIFY for 434 refreshes, S07 will be zero when NOTIFY optimizations is used. 435 o (S08) Total number and size of messages due to SUBSCRIBE refreshes 436 per day = Number - (S04+S05+S06+S07)*C06. The number of bytes is 437 calculated by adding the SUBSCIRBE bytes (S04*C06*C07), the OK for 438 SUBSCRIBE bytes (S05*C06*C08), the NOTIFY bytes C06*(S06*(C09+C15+ 439 C11+C13+C14)) and the OK for NOTIFY (S07*C06*C10). Note that the 440 formula for the notify bytes is for the dialog optimization is not 441 used and when it used the formula will be: C06*(S06*((C09+C15)+ 442 (C04*(C11+C13+C14)))). Note that a full state should be given in 443 SUBSCRIBE refreshes in resource lists. See section 4.5 in [12]. 445 The fact that the full state needs to be returned in a NOTIFY 446 response to refresh makes the NOTIFY optimization more efficient 447 in conjunction with the dialog optimization. 448 o (S09) Total number and bytes of steady messages per day = Number - 449 numbers in S03+S08, Bytes - sizes in S03+S08. 451 2.3.4. Termination Messages 453 The following are the calculations for the messages in the 454 termination phase of the of the subscriptions. The calculations 455 contain both number of messages and the number of bytes. 457 o (T01) Number of terminating SUBSCRIBE messages per watcher = C05. 458 o (T02) Number of terminating 200 OK messages for SUBSCRIBE messages 459 per watcher = C05. 460 o (T03) Number of terminating NOTIFY messages per watcher = C05. 461 Since when NOTIFY optimization is used [20] there is no need to 462 send NOTIFY for terminations, T03 will be zero when NOTIFY 463 optimization is used. 464 o (T04) Number of terminating 200 OK messages for NOTIFY messages 465 per watcher = C05. Since when NOTIFY optimization is used [20] 466 there is no need to send NOTIFY for terminations, T04 will be zero 467 when NOTIFY optimization is used. 468 o (T05) Total number and bytes of terminating SUBSCRIBE messages for 469 all watchers = Number - T01*C06, Bytes - T01*C06*C07. 470 o (T06) Total number and bytes of terminating 200 OK for SUBSCRIBE 471 messages for all watchers = Number - T01*C06, Bytes - T01*C06*C08. 472 o (T07) Total number and bytes of terminating NOTIFY messages for 473 all watchers = Number - T01*C06, The number of bytes is calculated 474 to be: (T03*C06*(C09+C11) when dialog optimization is not used 475 and: (T03*C06*(C09+C11+C13+C14+C15) when dialog optimization is 476 used. Note that for dialog optimization it is assumed that only a 477 single presentity is changed and partial state notification is 478 used. 479 o (T08) Total number and bytes of terminating 200 OK for NOTIFY 480 messages for all watchers = Number - T04*C06, Bytes - T04*C06*C10. 481 o (T09) Total number and bytes of terminating messages per day = 482 Number - numbers in T05+T06+T07+T08, Size -sizes in T05+T06+T07+ 483 T08. 485 2.3.5. Bottom Line 487 The following are the calculations of several totals that are based 488 on the above calculations. 490 o (B01) Total number of messages and bytes during the day = Messages 491 - Number of messages in I09+S09+T09, Bytes - Number of bytes in 492 I09+S09+T09. 494 o (B02) Total number of messages and bytes per second = Messages - 495 Number of messages in B01/(C01*3600) Bytes - Number of bytes in 496 B01/(C01*3600). 497 o (B02) Total number of message and bytes per user per day = 498 Messages - number of messages in B01/C06 Bytes - Number of bytes 499 in B01/C06. 501 2.3.6. Rush Hour Calculations 503 The way that the calculations are built it is relatively easy to see 504 the affect of rush hours at the beginning and the end of the day. for 505 the beginning of the day we should look at the numbers of "(I09) 506 Total number and bytes of initial messages per day" and for the end 507 of the day we should look at the number of "(T09) Total number and 508 bytes of terminating messages per day". Taking these numbers with 509 some assumed percentage of the numbers of users that log in at the 510 same hour should give good indication for the rush hour load. 512 2.4. SIMPLE with no optimizations 514 The following table uses some common presence characteristics to 515 demonstrate the effect these factors have on state and message rate 516 within a presence domain using base SIMPLE protocols without any 517 proposed optimizations. In this example, there are two presence 518 domains with total of 40,000 federating users with an average of 4 519 contacts in the peer domain. Note that the main calculation is done 520 for a presence document size of 350 bytes which is the base PIDF [6] 521 document size but the bottom line calculation is also given for a 522 presence document size for rich presence [8] which is assumed to be 523 3000 bytes based on the examples given in the RFCs. This two folded 524 calculation is done for every use case in this document. 526 ** Constants 527 (C01) Subscription lifetime (hours)...........................8 528 (C02) Presence state changes / hour...........................3 529 (C03) Subscription refresh interval / hour....................1 530 (C04) Total federated presentities per watcher................4 531 (C05) Number of dialogs to maintain per watcher...............4 532 (C06) Total number of watchers in domains................40,000 533 (C07) SUBSCRIBE message size in bytes.......................450 534 (C08) 200 OK for SUBSCRIBE message size in bytes............370 535 (C09) NOTIFY message size not including presence doc........500 536 (C10) 200 OK for NOTIFY message size in bytes...............370 537 (C11) Size of an average presence document..................350 539 ** Initial Messages 540 (I01) Initial SUBSCRIBE msgs per watcher......................4 541 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............4 542 (I03) Initial NOTIFY msgs per watcher.........................4 543 (I04) Initial 200 OK msgs (NOTIFY) per watcher................4 544 (I05) Total number & bytes of initial SUBSCRIBE msgs 545 Number of msgs for all watchers...............160,000 546 Bytes for all watchers.....................72,000,000 547 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 548 Number of msgs for all watchers...............160,000 549 Bytes for all watchers.....................59,200,000 550 (I07) Total number & bytes of initial NOTIFY msgs 551 Number of msgs for all watchers...............160,000 552 Bytes for all watchers....................136,000,000 553 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 554 Number of msgs for all watchers...............160,000 555 Bytes for all watchers.....................59,200,000 556 (I09) Total number & bytes of initial messages per day 557 Number of msgs for all watchers...............640,000 558 Bytes for all watchers....................326,400,000 560 ** Steady State Messages 561 (S01) NOTIFY msgs due to state change 562 per watched presentity per day.....................22 563 (S02) 200 (for NOTIFY due to state change) msgs 564 per watched presentity per day.....................22 565 (S03) Total number and size of msgs due to state change per day 566 Number of msgs for all watchers.............7,040,000 567 Bytes for all watchers..................4,294,400,000 568 (S04) Number of SUBSCRIBE msgs for refreshes 569 per watcher per day................................28 570 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 571 per watcher per day................................28 572 (S06) Number of NOTIFY msgs for refreshes 573 per watcher per day................................28 574 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 575 per watcher per day................................28 576 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 577 Number of msgs for all watchers per day.....4,480,000 578 Bytes for all watchers per day..........2,284,800,000 579 (S09) Total number & bytes of steady messages per day 580 Number of msgs for all watchers............11,520,000 581 Bytes for all watchers..................6,579,200,000 583 ** Termination Messages 584 (T01) Terminating SUBSCRIBE msgs per watcher..................4 585 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........4 586 (T03) Terminating NOTIFY msgs per watcher.....................4 587 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............4 588 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 589 Number of msgs for all watchers.............. 160,000 590 Bytes for all watchers.....................72,000,000 591 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 592 Number of msgs for all watchers...............160,000 593 Bytes for all watchers.....................59,200,000 594 (T07) Total number & bytes of terminating NOTIFY msgs 595 Number of msgs for all watchers...............160,000 596 Bytes for all watchers....................136,000,000 597 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 598 Number of msgs for all watchers...............160,000 599 Bytes for all watchers.....................59,200,000 600 (T09) Total number & bytes of terminating messages per day 601 Number of msgs for all watchers...............640,000 602 Bytes for all watchers....................326,400,000 604 ** Bottom Line 605 (B01) Total of messages between domains..............12,800,000 606 Total of bytes between domains (PD=350).....7,232,000,000 607 Total of bytes between domains (PD=3000)...20,376,000,000 608 (B02) Total number of messages / second.. ..................444 609 Total of bytes per second (PD=350)................251,111 610 Total of bytes per second (PD=3000)...............707,500 611 (B03) Total number of by msgs per user/day......... ........320 612 Total number of bytes per user/day (PD=350).......180,800 613 Total number of bytes per user/day (PD=3000)......509,400 615 Figure 1: SIMPLE with no optimizations 617 2.5. SIMPLE with dialog optimization 619 The same analysis provided above is repeated here with the assumption 620 that the dialog optimization is applied. Note that while the sign-in 621 (ramp up) and sign-out messages flows are positively affected, the 622 steady state rates are not. 624 ** Constants 625 (C01) Subscription lifetime (hours)...........................8 626 (C02) Presence state changes / hour...........................3 627 (C03) Subscription refresh interval / hour....................1 628 (C04) Total federated presentities per watcher................4 629 (C05) Number of dialogs to maintain per watcher...............1 630 (C06) Total number of watchers in domains................40,000 631 (C07) SUBSCRIBE message size in bytes.......................450 632 (C08) 200 OK for SUBSCRIBE message size in bytes............370 633 (C09) NOTIFY message size not including presence doc........500 634 (C10) 200 OK for NOTIFY message size in bytes...............370 635 (C11) Size of an average presence document..................350 636 (C13) Additional data per document in RLMI..................160 637 (C14) Multiparty boundary in RLMI document..................144 638 (C15) XML root node in RLMI document........................144 640 ** Initial Messages 641 (I01) Initial SUBSCRIBE msgs per watcher......................1 642 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1 643 (I03) Initial NOTIFY msgs per watcher.........................1 644 (I04) Initial 200 OK msgs (NOTIFY) per watcher................1 645 (I05) Total number & bytes of initial SUBSCRIBE msgs 646 Number of msgs for all watchers................40,000 647 Bytes for all watchers.....................18,000,000 648 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 649 Number of msgs for all watchers................40,000 650 Bytes for all watchers.....................14,800,000 651 (I07) Total number & bytes of initial NOTIFY msgs 652 Number of msgs for all watchers................40,000 653 Bytes for all watchers....................130,400,000 654 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 655 Number of msgs for all watchers................40,000 656 Bytes for all watchers.....................14,800,000 657 (I09) Total number & bytes of initial messages per day 658 Number of msgs for all watchers...............160,000 659 Bytes for all watchers....................178,000,000 661 ** Steady State Messages 662 (S01) NOTIFY msgs due to state change 663 per watched presentity per day.....................22 664 (S02) 200 (for NOTIFY due to state change) msgs 665 per watched presentity per day.....................22 666 (S03) Total number and size of msgs due to state change per day 667 Number of msgs for all watchers.............7,040,000 668 Bytes for all watchers..................5,871,360,000 669 (S04) Number of SUBSCRIBE msgs for refreshes 670 per watcher per day.................................7 671 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 672 per watcher per day.................................7 673 (S06) Number of NOTIFY msgs for refreshes 674 per watcher per day.................................7 675 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 676 per watcher per day.................................7 677 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 678 Number of msgs for all watchers per day.....1,120,000 679 Bytes for all watchers per day..........1,246,000,000 680 (S09) Total number & bytes of steady messages per day 681 Number of msgs for all watchers.............8,160,000 682 Bytes for all watchers..................7,117,360,000 684 ** Termination Messages 685 (T01) Terminating SUBSCRIBE msgs per watcher..................1 686 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1 687 (T03) Terminating NOTIFY msgs per watcher.....................1 688 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............1 689 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 690 Number of msgs for all watchers................40,000 691 Bytes for all watchers.....................18,000,000 692 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 693 Number of msgs for all watchers................40,000 694 Bytes for all watchers.....................14,800,000 695 (T07) Total number & bytes of terminating NOTIFY msgs 696 Number of msgs for all watchers................40,000 697 Bytes for all watchers.....................51,920,000 698 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 699 Number of msgs for all watchers................40,000 700 Bytes for all watchers.....................14,800,000 701 (T09) Total number & bytes of terminating messages per day 702 Number of msgs for all watchers...............160,000 703 Bytes for all watchers.....................99,520,000 705 ** Bottom Line 706 (B01) Total of messages between domains...............8,480,000 707 Total of bytes between domains (PD=350).....7,394,880,000 708 Total of bytes between domains (PD=3000)...20,220,880,000 709 (B02) Total number of messages / second.....................294 710 Total of bytes per second (PD=350)................256,767 711 Total of bytes per second (PD=3000)...............702,114 712 (B03) Total number of by msgs per user/day..................212 713 Total number of bytes per user/day (PD=350).......184,872 714 Total number of bytes per user/day (PD=3000)......505,522 716 Figure 2: SIMPLE with Dialog optimizations 718 2.6. SIMPLE with NOTIFY optimization 720 The initial analysis of analysis provided in Figure 1 is repeated 721 here with the assumption that the notify optimization is applied. 722 The optimization saves the need for NOTIFY upon refreshing a 723 SUBSCRIBE if there was no change since the last NOTIFY. It is 724 assumed here that there will be no NOTIFY message for a SUBSCRIBE 725 refreshes and terminations. As should be expected this optimization 726 affects the steady and termination state and does not affect the 727 initial state. 729 ** Constants 730 (C01) Subscription lifetime (hours)...........................8 731 (C02) Presence state changes / hour...........................3 732 (C03) Subscription refresh interval / hour....................1 733 (C04) Total federated presentities per watcher................4 734 (C05) Number of dialogs to maintain per watcher...............4 735 (C06) Total number of watchers in domains................40,000 736 (C07) SUBSCRIBE message size in bytes.......................450 737 (C08) 200 OK for SUBSCRIBE message size in bytes............370 738 (C09) NOTIFY message size not including presence doc........500 739 (C10) 200 OK for NOTIFY message size in bytes...............370 740 (C11) Size of an average presence document..................350 742 ** Initial Messages 743 (I01) Initial SUBSCRIBE msgs per watcher......................4 744 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............4 745 (I03) Initial NOTIFY msgs per watcher.........................4 746 (I04) Initial 200 OK msgs (NOTIFY) per watcher................4 747 (I05) Total number & bytes of initial SUBSCRIBE msgs 748 Number of msgs for all watchers...............160,000 749 Bytes for all watchers.....................72,000,000 750 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 751 Number of msgs for all watchers...............160,000 752 Bytes for all watchers.....................59,200,000 753 (I07) Total number & bytes of initial NOTIFY msgs 754 Number of msgs for all watchers...............160,000 755 Bytes for all watchers....................136,000,000 756 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 757 Number of msgs for all watchers...............160,000 758 Bytes for all watchers.....................59,200,000 759 (I09) Total number & bytes of initial messages per day 760 Number of msgs for all watchers...............640,000 761 Bytes for all watchers....................326,400,000 763 ** Steady State Messages 764 (S01) NOTIFY msgs due to state change 765 per watched presentity per day.....................22 766 (S02) 200 (for NOTIFY due to state change) msgs 767 per watched presentity per day.....................22 768 (S03) Total number and size of msgs due to state change per day 769 Number of msgs for all watchers.............7,040,000 770 Bytes for all watchers..................4,294,400,000 771 (S04) Number of SUBSCRIBE msgs for refreshes 772 per watcher per day................................28 773 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 774 per watcher per day................................28 775 (S06) Number of NOTIFY msgs for refreshes 776 per watcher per day.................................0 777 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 778 per watcher per day.................................0 779 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 780 Number of msgs for all watchers per day.....2,240,000 781 Bytes for all watchers per day............918,400,000 782 (S09) Total number & bytes of steady messages per day 783 Number of msgs for all watchers.............9,280,000 784 Bytes for all watchers..................5,212,800,000 786 ** Termination Messages 787 (T01) Terminating SUBSCRIBE msgs per watcher..................4 788 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........4 789 (T03) Terminating NOTIFY msgs per watcher.....................0 790 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............0 791 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 792 Number of msgs for all watchers.............. 160,000 793 Bytes for all watchers.....................72,000,000 794 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 795 Number of msgs for all watchers...............160,000 796 Bytes for all watchers.....................59,200,000 797 (T07) Total number & bytes of terminating NOTIFY msgs 798 Number of msgs for all watchers.....................0 799 Bytes for all watchers..............................0 800 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 801 Number of msgs for all watchers.....................0 802 Bytes for all watchers..............................0 803 (T09) Total number & bytes of terminating messages per day 804 Number of msgs for all watchers...............320,000 805 Bytes for all watchers....................131,200,000 807 ** Bottom Line 808 (B01) Total of messages between domains..............10,240,000 809 Total of bytes between domains (PD=350).....5,670,400,000 810 Total of bytes between domains (PD=3000)...15,422,400,000 811 (B02) Total number of messages / second.....................356 812 Total of bytes per second (PD=350)................196,889 813 Total of bytes per second (PD=3000)...............535,500 814 (B03) Total number of by msgs per user/day..................256 815 Total number of bytes per user/day (PD=350).......141,760 816 Total number of bytes per user/day (PD=3000)......385,560 818 Figure 3: SIMPLE with NOTIFY optimizations 820 2.7. SIMPLE with Dialog & NOTIFY optimizations 822 Here both optimizations are combined. In all the subsequent use 823 cases we will show only the analysis with no optimizations and with 824 both optimizations combined. 826 ** Constants 827 (C01) Subscription lifetime (hours)...........................8 828 (C02) Presence state changes / hour...........................3 829 (C03) Subscription refresh interval / hour....................1 830 (C04) Total federated presentities per watcher................4 831 (C05) Number of dialogs to maintain per watcher...............1 832 (C06) Total number of watchers in domains................40,000 833 (C07) SUBSCRIBE message size in bytes.......................450 834 (C08) 200 OK for SUBSCRIBE message size in bytes............370 835 (C09) NOTIFY message size not including presence doc........500 836 (C10) 200 OK for NOTIFY message size in bytes...............370 837 (C11) Size of an average presence document..................350 838 (C13) Additional data per document in RLMI..................160 839 (C14) Multiparty boundary in RLMI document..................144 840 (C15) XML root node in RLMI document........................144 842 ** Initial Messages 843 (I01) Initial SUBSCRIBE msgs per watcher......................1 844 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1 845 (I03) Initial NOTIFY msgs per watcher.........................1 846 (I04) Initial 200 OK msgs (NOTIFY) per watcher................1 847 (I05) Total number & bytes of initial SUBSCRIBE msgs 848 Number of msgs for all watchers................40,000 849 Bytes for all watchers.....................18,000,000 850 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 851 Number of msgs for all watchers................40,000 852 Bytes for all watchers.....................14,800,000 853 (I07) Total number & bytes of initial NOTIFY msgs 854 Number of msgs for all watchers................40,000 855 Bytes for all watchers....................130,400,000 856 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 857 Number of msgs for all watchers................40,000 858 Bytes for all watchers.....................14,800,000 859 (I09) Total number & bytes of initial messages per day 860 Number of msgs for all watchers...............160,000 861 Bytes for all watchers....................178,000,000 863 ** Steady State Messages 864 (S01) NOTIFY msgs due to state change 865 per watched presentity per day.....................22 866 (S02) 200 (for NOTIFY due to state change) msgs 867 per watched presentity per day.....................22 868 (S03) Total number and size of msgs due to state change per day 869 Number of msgs for all watchers.............7,040,000 870 Bytes for all watchers..................5,871,360,000 871 (S04) Number of SUBSCRIBE msgs for refreshes 872 per watcher per day.................................7 873 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 874 per watcher per day.................................7 875 (S06) Number of NOTIFY msgs for refreshes 876 per watcher per day.................................0 878 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 879 per watcher per day.................................0 880 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 881 Number of msgs for all watchers per day.......560,000 882 Bytes for all watchers per day............229,600,000 883 (S09) Total number & bytes of steady messages per day 884 Number of msgs for all watchers.............7,600,000 885 Bytes for all watchers..................6,100,960,000 887 ** Termination Messages 888 (T01) Terminating SUBSCRIBE msgs per watcher..................1 889 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1 890 (T03) Terminating NOTIFY msgs per watcher.....................0 891 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............0 892 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 893 Number of msgs for all watchers................40,000 894 Bytes for all watchers.....................18,000,000 895 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 896 Number of msgs for all watchers................40,000 897 Bytes for all watchers.....................14,800,000 898 (T07) Total number & bytes of terminating NOTIFY msgs 899 Number of msgs for all watchers.....................0 900 Bytes for all watchers..............................0 901 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 902 Number of msgs for all watchers.....................0 903 Bytes for all watchers..............................0 904 (T09) Total number & bytes of terminating messages per day 905 Number of msgs for all watchers................80,000 906 Bytes for all watchers.....................32,800,000 908 ** Bottom Line 909 (B01) Total of messages between domains...............7,840,000 910 Total of bytes between domains (PD=350).....6,311,760,000 911 Total of bytes between domains (PD=3000)...16,063,760,000 912 (B02) Total number of messages / second.....................272 913 Total of bytes per second (PD=350)................219,158 914 Total of bytes per second (PD=3000)...............557,769 915 (B03) Total number of by msgs per user/day..................196 916 Total number of bytes per user/day (PD=350).......157,794 917 Total number of bytes per user/day (PD=3000)......401,594 919 Figure 4: SIMPLE with Dialog & NOTIFY optimizations 921 2.8. Presence Federations 923 While scalability issues exist in any large deployment, certain 924 characteristics make the deployment conducive to the existing 925 resource- list optimizations, and others have characteristics that 926 cannot be exploited with the existing SIMPLE model. Following is a 927 list of federation relationships that have varying usage 928 characteristics. For each, a message rate and bandwidth table is 929 provided reflecting typical changes message rates. Those 930 characteristics can alter the overall effectiveness of existing 931 optimizations. 933 2.8.1. Widely distributed inter-domain presence 935 In some environments presence federation may be very common, perhaps 936 even more common than intra-domain presence. An example of this type 937 of environment is a small ISV or public server. Users in that small 938 ISV are not likely to subscribe to the presence of other users in the 939 their server since they do not necessarily have any relationship with 940 each other aside from receiving service from the same provider. They 941 are much more likely to be subscribed to the presence of users in one 942 of the federated domains (whether in consumer domains, academic, 943 other ISVs, etc). Common characteristics of this deployment are: 945 o Federated subscriptions are the majority of subscription traffic 946 o Individual users are likely to subscribe to multiple users in any 947 one domain 948 o The intersection of users in the deployment watching the same 949 presentities is quite small (i.e., probability that watchers in 950 the domain subscribe to the same presentity is low) 952 To account for the extraordinarily high percentage of federation 953 traffic, the number of federated presentities is increased to 20. 954 The number of watchers in the domain could also be adjusted to 955 account for an expected larger community of users being peered with, 956 it is omitted here for simplification 958 The first table below provides the calculations without optimizations 959 the second table provides the calculations with optimization. 961 ** Constants 962 (C01) Subscription lifetime (hours)...........................8 963 (C02) Presence state changes / hour...........................3 964 (C03) Subscription refresh interval / hour....................1 965 (C04) Total federated presentities per watcher...............20 966 (C05) Number of dialogs to maintain per watcher..............20 967 (C06) Total number of watchers in domains................40,000 968 (C07) SUBSCRIBE message size in bytes.......................450 969 (C08) 200 OK for SUBSCRIBE message size in bytes............370 970 (C09) NOTIFY message size not including presence doc........500 971 (C10) 200 OK for NOTIFY message size in bytes...............370 972 (C11) Size of an average presence document..................350 973 ** Initial Messages 974 (I01) Initial SUBSCRIBE msgs per watcher.....................20 975 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher............20 976 (I03) Initial NOTIFY msgs per watcher........................20 977 (I04) Initial 200 OK msgs (NOTIFY) per watcher...............20 978 (I05) Total number & bytes of initial SUBSCRIBE msgs 979 Number of msgs for all watchers...............800,000 980 Bytes for all watchers....................360,000,000 981 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 982 Number of msgs for all watchers...............800,000 983 Bytes for all watchers....................296,000,000 984 (I07) Total number & bytes of initial NOTIFY msgs 985 Number of msgs for all watchers...............800,000 986 Bytes for all watchers....................680,000,000 987 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 988 Number of msgs for all watchers...............800,000 989 Bytes for all watchers....................296,000,000 990 (I09) Total number & bytes of initial messages per day 991 Number of msgs for all watchers.............3,200,000 992 Bytes for all watchers..................1,632,000,000 994 ** Steady State Messages 995 (S01) NOTIFY msgs due to state change 996 per watched presentity per day.....................22 997 (S02) 200 (for NOTIFY due to state change) msgs 998 per watched presentity per day.....................22 999 (S03) Total number and size of msgs due to state change per day 1000 Number of msgs for all watchers............35,200,000 1001 Bytes for all watchers.................21,472,000,000 1002 (S04) Number of SUBSCRIBE msgs for refreshes 1003 per watcher per day...............................140 1004 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 1005 per watcher per day...............................140 1006 (S06) Number of NOTIFY msgs for refreshes 1007 per watcher per day...............................140 1008 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1009 per watcher per day...............................140 1010 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1011 Number of msgs for all watchers per day....22,400,000 1012 Bytes for all watchers per day.........11,424,000,000 1013 (S09) Total number & bytes of steady messages per day 1014 Number of msgs for all watchers............57,600,000 1015 Bytes for all watchers.................32,896,000,000 1017 ** Termination Messages 1018 (T01) Terminating SUBSCRIBE msgs per watcher.................20 1019 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........20 1020 (T03) Terminating NOTIFY msgs per watcher....................20 1021 (T04) Terminating 200 OK msgs (NOTIFY) per watcher...........20 1022 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1023 Number of msgs for all watchers...............800,000 1024 Bytes for all watchers....................360,000,000 1025 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1026 Number of msgs for all watchers...............800,000 1027 Bytes for all watchers....................296,000,000 1028 (T07) Total number & bytes of terminating NOTIFY msgs 1029 Number of msgs for all watchers...............800,000 1030 Bytes for all watchers....................680,000,000 1031 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 1032 Number of msgs for all watchers...............800,000 1033 Bytes for all watchers....................296,000,000 1034 (T09) Total number & bytes of terminating messages per day 1035 Number of msgs for all watchers.............3,200,000 1036 Bytes for all watchers..................1,632,000,000 1038 ** Bottom Line 1040 B01 Total of messages between domains................64,000,000 1041 Total of bytes between domains (PD=350)........36,160,000,000 1042 Total of bytes between domains (PD=3000)......101,880,000,000 1043 B02 Total number of messages / second.....................2,222 1044 Total of bytes per second (PD=350)..................1,255,556 1045 Total of bytes per second (PD=3000).................3,537,500 1046 B03 Total number of by msgs per user/day..................1,600 1047 Total number of bytes per user/day (PD=350)...........904,000 1048 Total number of bytes per user/day (PD=3000)........2,547,000 1050 (B01) Total of messages between domains..............64,000,000 1051 Total of bytes between domains (PD=350)....36,160,000,000 1052 Total of bytes between domains (PD=3000)..101,880,000,000 1053 (B02) Total number of messages / second...................2,222 1054 Total of bytes per second (PD=350)..............1,255,556 1055 Total of bytes per second (PD=3000).............3,537,500 1056 (B03) Total number of by msgs per user/day................1,600 1057 Total number of bytes per user/day (PD=350).......904,000 1058 Total number of bytes per user/day (PD=3000).....,547,000 1060 Figure 5: Widely distributed inter-domain with no optimizations 1062 ** Constants 1063 (C01) Subscription lifetime (hours)...........................8 1064 (C02) Presence state changes / hour...........................3 1065 (C03) Subscription refresh interval / hour....................1 1066 (C04) Total federated presentities per watcher...............20 1067 (C05) Number of dialogs to maintain per watcher...............1 1068 (C06) Total number of watchers in domains................40,000 1069 (C07) SUBSCRIBE message size in bytes.......................450 1070 (C08) 200 OK for SUBSCRIBE message size in bytes............370 1071 (C09) NOTIFY message size not including presence doc........500 1072 (C10) 200 OK for NOTIFY message size in bytes...............370 1073 (C11) Size of an average presence document..................350 1074 (C13) Additional data per document in RLMI..................160 1075 (C14) Multiparty boundary in RLMI document..................144 1076 (C15) XML root node in RLMI document........................144 1078 ** Initial Messages 1079 (I01) Initial SUBSCRIBE msgs per watcher......................1 1080 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1 1081 (I03) Initial NOTIFY msgs per watcher.........................1 1082 (I04) Initial 200 OK msgs (NOTIFY) per watcher................1 1083 (I05) Total number & bytes of initial SUBSCRIBE msgs 1084 Number of msgs for all watchers................40,000 1085 Bytes for all watchers.....................18,000,000 1086 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 1087 Number of msgs for all watchers................40,000 1088 Bytes for all watchers.....................14,800,000 1089 (I07) Total number & bytes of initial NOTIFY msgs 1090 Number of msgs for all watchers................40,000 1091 Bytes for all watchers....................548,960,000 1092 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 1093 Number of msgs for all watchers................40,000 1094 Bytes for all watchers.....................14,800,000 1095 (I09) Total number & bytes of initial messages per day 1096 Number of msgs for all watchers...............160,000 1097 Bytes for all watchers....................596,560,000 1099 ** Steady State Messages 1100 (S01) NOTIFY msgs due to state change 1101 per watched presentity per day.....................22 1102 (S02) 200 (for NOTIFY due to state change) msgs 1103 per watched presentity per day.....................22 1104 (S03) Total number and size of msgs due to state change per day 1105 Number of msgs for all watchers............35,200,000 1106 Bytes for all watchers.................29,356,800,000 1107 (S04) Number of SUBSCRIBE msgs for refreshes 1108 per watcher per day.................................7 1109 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 1110 per watcher per day.................................7 1111 (S06) Number of NOTIFY msgs for refreshes 1112 per watcher per day.................................0 1113 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1114 per watcher per day.................................0 1116 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1117 Number of msgs for all watchers per day.......560,000 1118 Bytes for all watchers per day............229,600,000 1119 (S09) Total number & bytes of steady messages per day 1120 Number of msgs for all watchers............35,760,000 1121 Bytes for all watchers.................29,586,400,000 1123 ** Termination Messages 1124 (T01) Terminating SUBSCRIBE msgs per watcher..................1 1125 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1 1126 (T03) Terminating NOTIFY msgs per watcher.....................0 1127 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............0 1128 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1129 Number of msgs for all watchers................40,000 1130 Bytes for all watchers.....................18,000,000 1131 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1132 Number of msgs for all watchers................40,000 1133 Bytes for all watchers.....................14,800,000 1134 (T07) Total number & bytes of terminating NOTIFY msgs 1135 Number of msgs for all watchers.....................0 1136 Bytes for all watchers..............................0 1137 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 1138 Number of msgs for all watchers.....................0 1139 Bytes for all watchers..............................0 1140 (T09) Total number & bytes of terminating messages per day 1141 Number of msgs for all watchers................80,000 1142 Bytes for all watchers.....................32,800,000 1144 ** Bottom Line 1145 (B01) Total of messages between domains..............36,000,000 1146 Total of bytes between domains (PD=350)....30,215,760,000 1147 Total of bytes between domains (PD=3000)...78,975,760,000 1148 (B02) Total number of messages / second...................1,250 1149 Total of bytes per second (PD=350)..............1,049,158 1150 Total of bytes per second (PD=3000).............2,742,214 1151 B(03 )Total number of by msgs per user/day..................900 1152 Total number of bytes per user/day (PD=350).......755,394 1153 Total number of bytes per user/day (PD=3000)....1,974,394 1155 Figure 6: Widely distributed inter-domain with optimizations 1157 2.8.2. Associated inter-domain presence 1159 In this type of environment, the domain is a collection of associated 1160 users such as an enterprise. Here, federation is once again very 1161 common. However, there is also a strong association between some 1162 users in the deployment. These associations make it somewhat more 1163 likely that users in that domain will be watchers of the same 1164 presentity. This can occur because of business relationships (e.g. 1165 two co-workers on a project federating with a partner company). 1167 Common characteristics of this deployment are: 1169 o Federated subscriptions are large minority or small majority of 1170 subscription traffic 1171 o Individual users are likely to subscribe to multiple users in any 1172 one domain, especially their own 1173 o The intersection of users in the deployment watching the same 1174 presentities increases 1176 This federation type has traffic rates similar to the previous 1177 examples but with different levels of association of the users. 1179 2.8.3. Very large network peering 1181 In this environment, two or more very large networks create a peering 1182 relationship allowing their users to subscribe to presence in the 1183 other domains. Where as the number of users in other deployment 1184 types ranges from hundreds to several hundred thousand, these large 1185 networks host up to hundreds of millions of users. Examples of these 1186 networks are large wireless carriers and consumer IM networks. 1188 Common characteristics of this deployment are: 1190 o As users become accustomed to network boundaries disappearing, 1191 federated subscriptions become as common as subscriptions within 1192 the same domain 1193 o Individual users are highly likely to want to see presence of 1194 multiple presentities in the peer network 1195 o The intersection of users in the deployment watching the same 1196 presentities is very high (i.e., two or more users in network A 1197 are extremely likely to be watching a same user in network B) 1198 o Status changes increase greatly due to typical observed consumer 1199 behavior 1201 The first table below provides the calculations without optimizations 1202 the second table provides the calculations with optimizations. Even 1203 though the optimizations help a lot (almost cut the number of 1204 messages by half), the numbers are still very high. Note also that 1205 the bandwidth required is very high. 1207 ** Constants 1208 (C01) Subscription lifetime (hours)...........................8 1209 (C02) Presence state changes / hour...........................6 1210 (C03) Subscription refresh interval / hour....................1 1211 (C04) Total federated presentities per watcher...............10 1212 (C05) Number of dialogs to maintain per watcher..............10 1213 (C06) Total number of watchers in domains............20,000,000 1214 (C07) SUBSCRIBE message size in bytes.......................450 1215 (C08) 200 OK for SUBSCRIBE message size in bytes............370 1216 (C09) NOTIFY message size not including presence doc........500 1217 (C10) 200 OK for NOTIFY message size in bytes...............370 1218 (C11) Size of an average presence document..................350 1220 ** Initial Messages 1221 (I01) Initial SUBSCRIBE msgs per watcher.....................10 1222 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher............10 1223 (I03) Initial NOTIFY msgs per watcher........................10 1224 (I04) Initial 200 OK msgs (NOTIFY) per watcher...............10 1225 (I05) Total number & bytes of initial SUBSCRIBE msgs 1226 Number of msgs for all watchers...........200,000,000 1227 Bytes for all watchers.................90,000,000,000 1228 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 1229 Number of msgs for all watchers...........200,000,000 1230 Bytes for all watchers.................74,000,000,000 1231 (I07) Total number & bytes of initial NOTIFY msgs 1232 Number of msgs for all watchers...........200,000,000 1233 Bytes for all watchers................170,000,000,000 1234 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 1235 Number of msgs for all watchers...........200,000,000 1236 Bytes for all watchers.................74,000,000,000 1237 (I09) Total number & bytes of initial messages per day 1238 Number of msgs for all watchers...........800,000,000 1239 Bytes for all watchers................408,000,000,000 1241 ** Steady State Messages 1242 (S01) NOTIFY msgs due to state change 1243 per watched presentity per day.....................46 1244 (S02) 200 (for NOTIFY due to state change) msgs 1245 per watched presentity per day.....................46 1246 (S03) Total number and size of msgs due to state change per day 1247 Number of msgs for all watchers........18,400,000,000 1248 Bytes for all watchers.............11,224,000,000,000 1249 (S04) Number of SUBSCRIBE msgs for refreshes 1250 per watcher per day................................70 1251 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 1252 per watcher per day................................70 1253 (S06) Number of NOTIFY msgs for refreshes 1254 per watcher per day................................70 1255 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1256 per watcher per day................................70 1257 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1258 Number of msgs for all watchers per day.5,600,000,000 1259 Bytes for all watchers per day......2,856,000,000,000 1261 (S09) Total number & bytes of steady messages per day 1262 Number of msgs for all watchers........24,000,000,000 1263 Bytes for all watchers.............14,080,000,000,000 1265 ** Termination Messages 1266 (T01) Terminating SUBSCRIBE msgs per watcher.................10 1267 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........10 1268 (T03) Terminating NOTIFY msgs per watcher....................10 1269 (T04) Terminating 200 OK msgs (NOTIFY) per watcher...........10 1270 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1271 Number of msgs for all watchers...........200,000,000 1272 Bytes for all watchers.................90,000,000,000 1273 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1274 Number of msgs for all watchers...........200,000,000 1275 Bytes for all watchers.................74,000,000,000 1276 (T07) Total number & bytes of terminating NOTIFY msgs 1277 Number of msgs for all watchers...........200,000,000 1278 Bytes for all watchers................170,000,000,000 1279 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 1280 Number of msgs for all watchers...........200,000,000 1281 Bytes for all watchers.................74,000,000,000 1282 (T09) Total number & bytes of terminating messages per day 1283 Number of msgs for all watchers...........800,000,000 1284 Bytes for all watchers................408,000,000,000 1286 ** Bottom Line 1287 (B01) Total of messages between domains..........25,600,000,000 1288 Total of bytes bet. domains (PD=350)...14,896,000,000,000 1289 Total of bytes bet. domains (PD=3000)..44,046,000,000,000 1290 (B02) Total number of messages / second.................888,889 1291 Total of bytes per second (PD=350)............517,222,222 1292 Total of bytes per second (PD=3000).........1,529,375,000 1293 (B03) Total number of by msgs per user/day................1,280 1294 Total number of bytes per user/day (PD=350).......744,800 1295 Total number of bytes per user/day (PD=3000)....2,202,300 1297 Figure 7: Very large network peering with no optimizations 1299 ** Constants 1300 (C01) Subscription lifetime (hours)...........................8 1301 (C02) Presence state changes / hour...........................6 1302 (C03) Subscription refresh interval / hour....................1 1303 (C04) Total federated presentities per watcher...............10 1304 (C05) Number of dialogs to maintain per watcher...............1 1305 (C06) Total number of watchers in domains............20,000,000 1306 (C07) SUBSCRIBE message size in bytes.......................450 1307 (C08) 200 OK for SUBSCRIBE message size in bytes............370 1308 (C09) NOTIFY message size not including presence doc........500 1309 (C10) 200 OK for NOTIFY message size in bytes...............370 1310 (C11) Size of an average presence document..................350 1311 (C13) Additional data per document in RLMI..................160 1312 (C14) Multiparty boundary in RLMI document..................144 1313 (C15) XML root node in RLMI document........................144 1315 ** Initial Messages 1316 (I01) Initial SUBSCRIBE msgs per watcher......................1 1317 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1 1318 (I03) Initial NOTIFY msgs per watcher.........................1 1319 (I04) Initial 200 OK msgs (NOTIFY) per watcher................1 1320 (I05) Total number & bytes of initial SUBSCRIBE msgs 1321 Number of msgs for all watchers............20,000,000 1322 Bytes for all watchers..................9,000,000,000 1323 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 1324 Number of msgs for all watchers............20,000,000 1325 Bytes for all watchers..................7,400,000,000 1326 (I07) Total number & bytes of initial NOTIFY msgs 1327 Number of msgs for all watchers............20,000,000 1328 Bytes for all watchers................143,680,000,000 1329 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 1330 Number of msgs for all watchers............20,000,000 1331 Bytes for all watchers..................7,400,000,000 1332 (I09) Total number & bytes of initial messages per day 1333 Number of msgs for all watchers............80,000,000 1334 Bytes for all watchers................167,480,000,000 1336 ** Steady State Messages 1337 (S01) NOTIFY msgs due to state change 1338 per watched presentity per day.....................46 1339 (S02) 200 (for NOTIFY due to state change) msgs 1340 per watched presentity per day.....................46 1341 (S03) Total number and size of msgs due to state change per day 1342 Number of msgs for all watchers........18,400,000,000 1343 Bytes for all watchers.............15,345,600,000,000 1344 (S04) Number of SUBSCRIBE msgs for refreshes 1345 per watcher per day.................................7 1346 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 1347 per watcher per day.................................7 1348 (S06) Number of NOTIFY msgs for refreshes 1349 per watcher per day.................................0 1350 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1351 per watcher per day.................................0 1352 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1353 Number of msgs for all watchers per day...280,000,000 1354 Bytes for all watchers per day........114,800,000,000 1355 (S09) Total number & bytes of steady messages per day 1356 Number of msgs for all watchers........18,680,000,000 1357 Bytes for all watchers.............15,460,400,000,000 1359 ** Termination Messages 1360 (T01) Terminating SUBSCRIBE msgs per watcher..................1 1361 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1 1362 (T03) Terminating NOTIFY msgs per watcher.....................0 1363 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............0 1364 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1365 Number of msgs for all watchers............20,000,000 1366 Bytes for all watchers..................9,000,000,000 1367 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1368 Number of msgs for all watchers............20,000,000 1369 Bytes for all watchers..................7,400,000,000 1370 (T07) Total number & bytes of terminating NOTIFY msgs 1371 Number of msgs for all watchers.....................0 1372 Bytes for all watchers..............................0 1373 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 1374 Number of msgs for all watchers.....................0 1375 Bytes for all watchers..............................0 1376 (T09) Total number & bytes of terminating messages per day 1377 Number of msgs for all watchers............40,000,000 1378 Bytes for all watchers.................16,400,000,000 1380 ** Bottom Line 1381 (B01) Total of messages between domains..........18,800,000,000 1382 Total of bytes bet. domains (PD=350)...15,644,400,000,000 1383 Total of bytes bet. domains (PD=3000)..40,554,280,000,000 1384 (B02) Total number of messages / second.................652,778 1385 Total of bytes per second (PD=350)............543,208,333 1386 Total of bytes per second (PD=3000).........1,408,134,722 1387 (B03) Total number of by msgs per user/day..................940 1388 Total number of bytes per user/day (PD=350).......782,220 1389 Total number of bytes per user/day (PD=3000)....2,027,714 1391 Figure 8: Very large network peering with optimizations 1393 2.8.4. Intra-domain peering 1395 Within a particular domain, multiple presence infrastructures are 1396 deployed with users split between the two. This scenario is unique 1397 in that federated messages do not pass outside the administrative 1398 domain's network. The two infrastructures peer directly inside the 1399 domain. A common example of this is an enterprise IT system with 1400 multiple independent vendor presence solutions deployed (e.g., a 1401 presence solution for desktop messaging deployed alongside a presence 1402 solution for IP telephony). 1404 Common characteristics of this deployment are 1406 o The difference between subscriptions to presentities in one system 1407 vs. the other are completely arbitrary. Any one presentity is as 1408 likely to be homed on one infrastructure as the other. 1409 o Active users are almost guaranteed of subscribing to many users in 1410 the peer infrastructure. 1411 o The level of intersection of presentities is extremely high. 1413 The first table below provides the calculations without optimizations 1414 the second table provides the calculations with optimization. Even 1415 though the relatively conservative numbers are used, the amount of 1416 messages is still very high even though optimization may cut the 1417 traffic by more then half 1419 ** Constants 1420 (C01) Subscription lifetime (hours)...........................8 1421 (C02) Presence state changes / hour...........................3 1422 (C03) Subscription refresh interval / hour....................1 1423 (C04) Total federated presentities per watcher...............10 1424 (C05) Number of dialogs to maintain per watcher..............10 1425 (C06) Total number of watchers in domains...............120,000 1426 (C07) SUBSCRIBE message size in bytes.......................450 1427 (C08) 200 OK for SUBSCRIBE message size in bytes............370 1428 (C09) NOTIFY message size not including presence doc........500 1429 (C10) 200 OK for NOTIFY message size in bytes...............370 1430 (C11) Size of an average presence document..................350 1432 ** Initial Messages 1433 (I01) Initial SUBSCRIBE msgs per watcher.....................10 1434 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher............10 1435 (I03) Initial NOTIFY msgs per watcher........................10 1436 (I04) Initial 200 OK msgs (NOTIFY) per watcher...............10 1437 (I05) Total number & bytes of initial SUBSCRIBE msgs 1438 Number of msgs for all watchers.............1,200,000 1439 Bytes for all watchers....................540,000,000 1440 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 1441 Number of msgs for all watchers.............1,200,000 1442 Bytes for all watchers....................444,000,000 1443 (I07) Total number & bytes of initial NOTIFY msgs 1444 Number of msgs for all watchers.............1,200,000 1445 Bytes for all watchers..................1,020,000,000 1446 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 1447 Number of msgs for all watchers.............1,200,000 1448 Bytes for all watchers....................444,000,000 1449 (I09) Total number & bytes of initial messages per day 1450 Number of msgs for all watchers.............4,800,000 1451 Bytes for all watchers..................2,448,000,000 1453 ** Steady State Messages 1454 (S01) NOTIFY msgs due to state change 1455 per watched presentity per day.....................22 1456 (S02) 200 (for NOTIFY due to state change) msgs 1457 per watched presentity per day.....................22 1458 (S03) Total number and size of msgs due to state change per day 1459 Number of msgs for all watchers............52,800,000 1460 Bytes for all watchers.................32,208,000,000 1461 (S04) Number of SUBSCRIBE msgs for refreshes 1462 per watcher per day................................70 1463 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 1464 per watcher per day................................70 1465 (S06) Number of NOTIFY msgs for refreshes 1466 per watcher per day................................70 1467 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1468 per watcher per day................................70 1469 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1470 Number of msgs for all watchers per day....33,600,000 1471 Bytes for all watchers per day.........17,136,000,000 1472 (S09) Total number & bytes of steady messages per day 1473 Number of msgs for all watchers............86,400,000 1474 Bytes for all watchers.................49,344,000,000 1476 ** Termination Messages 1477 (T01) Terminating SUBSCRIBE msgs per watcher.................10 1478 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........10 1479 (T03) Terminating NOTIFY msgs per watcher....................10 1480 (T04) Terminating 200 OK msgs (NOTIFY) per watcher...........10 1481 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1482 Number of msgs for all watchers.............1,200,000 1483 Bytes for all watchers....................540,000,000 1484 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1485 Number of msgs for all watchers.............1,200,000 1486 Bytes for all watchers....................444,000,000 1487 (T07) Total number & bytes of terminating NOTIFY msgs 1488 Number of msgs for all watchers.............1,200,000 1489 Bytes for all watchers..................1,020,000,000 1490 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 1491 Number of msgs for all watchers.............1,200,000 1492 Bytes for all watchers....................444,000,000 1493 (T09) Total number & bytes of terminating messages per day 1494 Number of msgs for all watchers.............4,800,000 1495 Bytes for all watchers..................2,448,000,000 1497 ** Bottom Line 1498 (B01) Total of messages between domains..............96,000,000 1499 Total of bytes between domains (PD=350)....54,240,000,000 1500 Total of bytes between domains (PD=3000)..152,820,000,000 1502 (B02) Total number of messages / second...................3,333 1503 Total of bytes per second (PD=350)..............1,883,333 1504 Total of bytes per second (PD=3000).............5,306,250 1505 B(03 )Total number of by msgs per user/day..................800 1506 Total number of bytes per user/day (PD=350).......452,000 1507 Total number of bytes per user/day (PD=3000)....1,273,500 1509 Figure 9: Intra-domain peering with no optimizations 1511 ** Constants 1512 (C01) Subscription lifetime (hours)...........................8 1513 (C02) Presence state changes / hour...........................3 1514 (C03) Subscription refresh interval / hour....................1 1515 (C04) Total federated presentities per watcher...............10 1516 (C05) Number of dialogs to maintain per watcher...............1 1517 (C06) Total number of watchers in domains...............120,000 1518 (C07) SUBSCRIBE message size in bytes.......................450 1519 (C08) 200 OK for SUBSCRIBE message size in bytes............370 1520 (C09) NOTIFY message size not including presence doc........500 1521 (C10) 200 OK for NOTIFY message size in bytes...............370 1522 (C11) Size of an average presence document..................350 1523 (C13) Additional data per document in RLMI..................160 1524 (C14) Multiparty boundary in RLMI document..................144 1525 (C15) XML root node in RLMI document........................144 1527 ** Initial Messages 1528 (I01) Initial SUBSCRIBE msgs per watcher......................1 1529 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1 1530 (I03) Initial NOTIFY msgs per watcher.........................1 1531 (I04) Initial 200 OK msgs (NOTIFY) per watcher................1 1532 (I05) Total number & bytes of initial SUBSCRIBE msgs 1533 Number of msgs for all watchers...............120,000 1534 Bytes for all watchers.....................54,000,000 1535 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 1536 Number of msgs for all watchers...............120,000 1537 Bytes for all watchers.....................44,400,000 1538 (I07) Total number & bytes of initial NOTIFY msgs 1539 Number of msgs for all watchers...............120,000 1540 Bytes for all watchers....................862,080,000 1541 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 1542 Number of msgs for all watchers...............120,000 1543 Bytes for all watchers.....................44,400,000 1544 (I09) Total number & bytes of initial messages per day 1545 Number of msgs for all watchers...............480,000 1546 Bytes for all watchers..................1,004,880,000 1548 ** Steady State Messages 1549 (S01) NOTIFY msgs due to state change 1550 per watched presentity per day.....................22 1551 (S02) 200 (for NOTIFY due to state change) msgs 1552 per watched presentity per day.....................22 1553 (S03) Total number and size of msgs due to state change per day 1554 Number of msgs for all watchers............52,800,000 1555 Bytes for all watchers.................44,035,200,000 1556 (S04) Number of SUBSCRIBE msgs for refreshes 1557 per watcher per day.................................7 1558 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 1559 per watcher per day.................................7 1560 (S06) Number of NOTIFY msgs for refreshes 1561 per watcher per day.................................0 1562 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1563 per watcher per day.................................0 1564 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1565 Number of msgs for all watchers per day.....1,680,000 1566 Bytes for all watchers per day............688,800,000 1567 (S09) Total number & bytes of steady messages per day 1568 Number of msgs for all watchers............54,480,000 1569 Bytes for all watchers.................44,724,000,000 1571 ** Termination Messages 1572 (T01) Terminating SUBSCRIBE msgs per watcher..................1 1573 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1 1574 (T03) Terminating NOTIFY msgs per watcher.....................1 1575 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............1 1576 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1577 Number of msgs for all watchers...............120,000 1578 Bytes for all watchers.....................54,000,000 1579 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1580 Number of msgs for all watchers...............120,000 1581 Bytes for all watchers.....................44,400,000 1582 (T07) Total number & bytes of terminating NOTIFY msgs 1583 Number of msgs for all watchers.....................0 1584 Bytes for all watchers..............................0 1585 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 1586 Number of msgs for all watchers...............120,000 1587 Bytes for all watchers.....................44,400,000 1588 (T09) Total number & bytes of terminating messages per day 1589 Number of msgs for all watchers...............240,000 1590 Bytes for all watchers.....................98.400,000 1592 ** Bottom Line 1593 (B01) Total of messages between domains..............55,200,000 1594 Total of bytes between domains (PD=350)....45,827,280,000 1595 Total of bytes between domains (PD=3000)..118,967,280,000 1596 (B02) Total number of messages / second...................1,917 1597 Total of bytes per second (PD=350)..............1,591,225 1598 Total of bytes per second (PD=3000).............4,130,808 1599 (B03) Total number of by msgs per user/day..................460 1600 Total number of bytes per user/day (PD=350).......381,894 1601 Total number of bytes per user/day (PD=3000)......991,394 1603 Figure 10: Intra-domain peering with optimizations 1605 2.9. Partial Notifications Optimization 1607 Draft [15] define a way for the watcher to request getting only what 1608 was changed in the presence document. The following is a calculation 1609 of the bandwidth that is saved in the very large peering network 1610 case, when we add the partial notification optimization to the dialog 1611 and NOTIFY optimization. It is assumed that except for the initial 1612 NOTIFY all the other NOTIFY messages will be partial. It is also 1613 assumed that only a single attribute in the presence document will be 1614 changed each time, thus the size of the partial presence document is 1615 assumed to be 200 bytes. 1617 ** Constants 1618 (C01) Subscription lifetime (hours)...........................8 1619 (C02) Presence state changes / hour...........................6 1620 (C03) Subscription refresh interval / hour....................1 1621 (C04) Total federated presentities per watcher...............10 1622 (C05) Number of dialogs to maintain per watcher..............10 1623 (C06) Total number of watchers in domains............20,000,000 1624 (C07) SUBSCRIBE message size in bytes.......................450 1625 (C08) 200 OK for SUBSCRIBE message size in bytes............370 1626 (C09) NOTIFY message size not including presence doc........500 1627 (C10) 200 OK for NOTIFY message size in bytes...............370 1628 (C11) Size of an average presence document..................350 1629 (C12) Size of an average partial presence document..........200 1631 ** Initial Messages 1632 (I01) Initial SUBSCRIBE msgs per watcher.....................10 1633 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher............10 1634 (I03) Initial NOTIFY msgs per watcher........................10 1635 (I04) Initial 200 OK msgs (NOTIFY) per watcher...............10 1636 (I05) Total number & bytes of initial SUBSCRIBE msgs 1637 Number of msgs for all watchers...........200,000,000 1638 Bytes for all watchers.................90,000,000,000 1639 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 1640 Number of msgs for all watchers...........200,000,000 1641 Bytes for all watchers..................74,00,000,000 1642 (I07) Total number & bytes of initial NOTIFY msgs 1643 Number of msgs for all watchers...........200,000,000 1644 Bytes for all watchers................170,000,000,000 1646 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 1647 Number of msgs for all watchers...........200,000,000 1648 Bytes for all watchers..................74,000,000,000 1649 (I09) Total number & bytes of initial messages per day 1650 Number of msgs for all watchers...........800,000,000 1651 Bytes for all watchers................408,000,000,000 1653 ** Steady State Messages 1654 (S01) NOTIFY msgs due to state change 1655 per watched presentity per day.....................46 1656 (S02) 200 (for NOTIFY due to state change) msgs 1657 per watched presentity per day.....................46 1658 (S03) Total number and size of msgs due to state change per day 1659 Number of msgs for all watchers........18,400,000,000 1660 Bytes for all watchers..............9,844,000,000,000 1661 (S04) Number of SUBSCRIBE msgs for refreshes 1662 per watcher per day................................70 1663 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 1664 per watcher per day................................70 1665 (S06) Number of NOTIFY msgs for refreshes 1666 per watcher per day.................................0 1667 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1668 per watcher per day.................................0 1669 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1670 Number of msgs for all watchers per day.2,800,000,000 1671 Bytes for all watchers per day......1,148,000,000,000 1672 (S09) Total number & bytes of steady messages per day 1673 Number of msgs for all watchers........21,200,000,000 1674 Bytes for all watchers.............10,992,000,000,000 1676 ** Termination Messages 1677 (T01) Terminating SUBSCRIBE msgs per watcher.................10 1678 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........10 1679 (T03) Terminating NOTIFY msgs per watcher.....................0 1680 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............0 1681 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1682 Number of msgs for all watchers...........200,000,000 1683 Bytes for all watchers.................90,000,000,000 1684 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1685 Number of msgs for all watchers...........200,000,000 1686 Bytes for all watchers.................74,000,000,000 1687 (T07) Total number & bytes of terminating NOTIFY msgs 1688 Number of msgs for all watchers.....................0 1689 Bytes for all watchers..............................0 1690 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 1691 Number of msgs for all watchers.....................0 1692 Bytes for all watchers..............................0 1693 (T09) Total number & bytes of terminating messages per day 1694 Number of msgs for all watchers...........400,000,000 1695 Bytes for all watchers................164.000,000,000 1697 ** Bottom Line 1698 (B01) Total of messages between domains..........22,400,000,000 1699 Total of bytes bet. domains (PD=350)...11,564,000,000,000 1700 Total of bytes bet. domains (PD=3000)..12,094,000,000,000 1701 (B02) Total number of messages / second.................777,778 1702 Total of bytes per second (PD=350)............401,527,778 1703 Total of bytes per second (PD=3000)...........419,930,556 1704 (B03) Total number of by msgs per user/day................1,120 1705 Total number of bytes per user/day (PD=350).......578,200 1706 Total number of bytes per user/day (PD=3000)......604,700 1708 Figure 11: Very large networks peering with NOTIFY and partial 1709 optimizations 1711 2.10. Other Protocols 1713 In SIP there are several differences from other protocols of presence 1714 as XMPP [7] and the proprietary protocols of the consumer domains. 1715 The differences are: 1717 o There is no 200 OK for each message. These protocols support only 1718 TCP and they do not compensate for network issues. 1719 o There is no refresh for subscription. 1720 o There is no NOTIFY upon termination of SUBSCRIPTION 1721 o The size of each message of these protocol is smaller since they 1722 are either binary and/or there is no need for the various headers 1723 that SIP uses for routing etc. So we need to assume smaller 1724 message sizes while we will keep the size of the presence document 1725 the same. 1727 The following is an analysis of the very large networks peering 1728 assuming all the changes in other protocols with respect to SIP. 1730 ** Constants 1731 (C01) Subscription lifetime (hours)...........................8 1732 (C02) Presence state changes / hour...........................6 1733 (C03) Subscription refresh interval / hour....................0 1734 (C04) Total federated presentities per watcher...............10 1735 (C05) Number of dialogs to maintain per watcher..............10 1736 (C06) Total number of watchers in domains............20,000,000 1737 (C07) SUBSCRIBE message size in bytes.......................150 1738 (C08) 200 OK for SUBSCRIBE message size in bytes..............0 1739 (C09) NOTIFY message size not including presence doc........150 1740 (C10) 200 OK for NOTIFY message size in bytes.................0 1741 (C11) Size of an average presence document..................350 1742 ** Initial Messages 1743 (I01) Initial SUBSCRIBE msgs per watcher.....................10 1744 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............0 1745 (I03) Initial NOTIFY msgs per watcher........................10 1746 (I04) Initial 200 OK msgs (NOTIFY) per watcher................0 1747 (I05) Total number & bytes of initial SUBSCRIBE msgs 1748 Number of msgs for all watchers...........200,000,000 1749 Bytes for all watchers.................30,000,000,000 1750 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 1751 Number of msgs for all watchers.....................0 1752 Bytes for all watchers..............................0 1753 (I07) Total number & bytes of initial NOTIFY msgs 1754 Number of msgs for all watchers...........200,000,000 1755 Bytes for all watchers................100,000,000,000 1756 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 1757 Number of msgs for all watchers.....................0 1758 Bytes for all watchers..............................0 1759 (I09) Total number & bytes of initial messages per day 1760 Number of msgs for all watchers...........400,000,000 1761 Bytes for all watchers................130,000,000,000 1763 ** Steady State Messages 1764 (S01) NOTIFY msgs due to state change 1765 per watched presentity per day.....................46 1766 (S02) 200 (for NOTIFY due to state change) msgs 1767 per watched presentity per day......................0 1768 (S03) Total number and size of msgs due to state change per day 1769 Number of msgs for all watchers.........9,200,000,000 1770 Bytes for all watchers..............4,600,000,000,000 1771 (S04) Number of SUBSCRIBE msgs for refreshes 1772 per watcher per day.................................0 1773 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 1774 per watcher per day.................................0 1775 (S06) Number of NOTIFY msgs for refreshes 1776 per watcher per day.................................0 1777 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1778 per watcher per day.................................0 1779 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1780 Number of msgs for all watchers per day.............0 1781 Bytes for all watchers per day......................0 1782 (S09) Total number & bytes of steady messages per day 1783 Number of msgs for all watchers.........9,200,480,000 1784 Bytes for all watchers..............4,600,000,000,000 1786 ** Termination Messages 1787 (T01) Terminating SUBSCRIBE msgs per watcher.................10 1788 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........0 1789 (T03) Terminating NOTIFY msgs per watcher.....................0 1790 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............0 1791 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1792 Number of msgs for all watchers...........200,000,000 1793 Bytes for all watchers.................30,000,000,000 1794 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1795 Number of msgs for all watchers.....................0 1796 Bytes for all watchers..............................0 1797 (T07) Total number & bytes of terminating NOTIFY msgs 1798 Number of msgs for all watchers.....................0 1799 Bytes for all watchers..............................0 1800 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 1801 Number of msgs for all watchers.....................0 1802 Bytes for all watchers..............................0 1803 (T09) Total number & bytes of terminating messages per day 1804 Number of msgs for all watchers...........200,000,000 1805 Bytes for all watchers.................30,000,000,000 1807 ** Bottom Line 1808 (B01) Total of messages between domains...........9,800,000,000 1809 Total of bytes between domains (PD=50)..1,940,000,000,000 1810 Total of bytes between domains (PD=350).4,760,000,000,000 1811 Total of bytes bet. domains (PD=3000)..29,670,000,000,000 1812 (B02) Total number of messages / second.................340,278 1813 Total of bytes per second (PD=50)..............67,361,111 1814 Total of bytes per second (PD=350)............165,277,778 1815 Total of bytes per second (PD=3000).........1,030,208,333 1816 (B03) Total number of by msgs per user/day..................490 1817 Total number of bytes per user/day (PD=50).........97,000 1818 Total number of bytes per user/day (PD=350).......238,000 1819 Total number of bytes per user/day (PD=3000)....1,483,500 1821 Figure 12: Very large networks peering in other protocols 1823 3. State Management 1825 In previous sections we have discussed the big amount of messages 1826 that need to be sent to/from a presence server In this section the 1827 state that needs to be maintained by a presence server will be 1828 analyzed and shown to be far from trivial. 1830 The presence server has two parallel tasks. 1832 1. Maintain the state of the presentities to which watchers 1833 subscribe. 1834 2. Maintain the state of the subscriptions of watchers and provide 1835 timely updates to the watchers. 1837 For a single subscription from a single watcher on a presentity, the 1838 presence server has to maintain the following state: 1840 o Subscription state including all the parameters that are needed in 1841 order to maintain the subscription as timers. 1842 o Optional filtering information that was requested by the watcher. 1843 This includes enough information that is needed for doing the 1844 filtering. In addition additional information has to be 1845 maintained if partial notification is being supported for the 1846 subscription 1847 o Optional rate management information as throttling 1848 o Watcher information [4], [5] that is the result of the 1849 subscription in order to enable watched presentities to see who is 1850 watching them. 1852 For each presentity that has been subscribed to in the presence 1853 server, the presence server has to maintain the following state: 1855 o A list of the subscriptions for the presentity. Note that this is 1856 already taken care of from the size calculation point of view by 1857 the subscription state above. 1858 o Authorization information for the presentity. 1860 For each presentity for which there was any publication and the 1861 presentity has a state other then a default value, the presence 1862 server has to maintain the current value of the presentity. 1864 3.1. State Size Calculations 1866 Lets assume the following sizes: 1868 o Subscription size - 2K bytes. This includes watcher information 1869 that need to be created by the presence server for each 1870 subscription. 1871 o Subscribed to resource - 1K bytes (for privacy information and 1872 other management info). The subscriptions themselves are already 1873 calculated in the previous bullet. 1874 o Resource with a state - 6K bytes. This is a moderate assumption 1875 if we take into account the amount of data that is being put in a 1876 presence document as multiple devices, calendar and geographical 1877 information. 1879 3.1.1. Tiny System 1881 o 10K subscriptions = 19M bytes. 1882 o 5K subscribed to presentities = 5M bytes. 1884 o 10K presentities with state = 58M bytes. 1886 Total is 82M bytes. 1888 3.1.2. Medium System 1890 o 100K subscriptions = 195M bytes. 1891 o 50K subscribed to presentities = 49M bytes. 1892 o 100K presentities with state = 586M bytes. 1894 Total is 830M bytes. 1896 3.1.3. Large System 1898 o 6M subscriptions = 11,718M bytes. 1899 o 3M subscribed to presentities = 2,929M bytes. 1900 o 4M presentities with state = 23437M bytes. 1902 Total is 38G bytes. 1904 3.1.4. Very Large System 1906 o 150M subscriptions = 292,969M bytes. 1907 o 75M subscribed to presentities = 73,242M bytes. 1908 o 100M presentities with state = 585,937M bytes. 1910 Total is 952G bytes which is a very big number for a very dynamic 1911 storage as needed by the presence server. 1913 Although the numbers above may seem moderate enough for the sizes 1914 that the presence server is handling we should consider the 1915 following: 1917 o Dynamic state - Although the state may seem not so big for 1918 databases even for the very large system, we need to remember that 1919 this state is a very dynamic state. Subscriptions come and go all 1920 the time, the status of presentities is being updated and so 1921 forth. This means that the presence server has to manage its 1922 state in a medium that is very dynamic and for such large sizes 1923 this task is not trivial. 1924 o Interlinked state - The subscriptions and the subscribed to 1925 presentities are dependent on each other. There needs to be a 1926 link from the presentity to the subscriptions and vice versa. See 1927 Section 4.5 about the interlinkage that is created due to resource 1928 lists. 1929 o Moderate assumptions - The size assumptions that were made above 1930 are quite moderate. As presence is becoming more a core 1931 middleware functionality that holds a lot of data on the user. In 1932 real-life the numbers above may be even higher and the presence 1933 server can have additional overhead as managing the SIP sessions, 1934 networking and more. 1936 Although the calculations above do not show that there is a real 1937 issue with state management of presence in medium systems or even in 1938 big systems since it should be possible to divide the state between 1939 different machines, the state size is still very big. A bigger issue 1940 with the state is more when resource lists are involved and create an 1941 interlinked state between many servers. In that case the division of 1942 very big state to multiple servers becomes less trivial... 1944 4. Processing complexities 1946 The basic presence paradigm consists from a watcher and a presentity 1947 to which the watcher watches. It sounds simple enough but there are 1948 many additions and extensions that the presence server has to manage 1949 that make the processing of the presence server very complex. 1951 In this section we show that in addition to the large amount of 1952 messages and the big state that the presence server has to handle, it 1953 has also to handle quite intensive processing for aggregation, 1954 partial notify and publish, filtering and privacy. This adds another 1955 complexity to the presence server in the CPU front in addition to the 1956 network and memory fronts that were described before. 1958 4.1. Aggregation 1960 A presence document may contain multiple resources. These resources 1961 can be devices of the presentity, information that is received form 1962 external providers of presence information for the presentity as 1963 geographical and calendar information and more. 1965 The presence server needs to be able to get the updates from all the 1966 resources and aggregate them correctly into a single presence 1967 document. Although this is just "XML processing" task, the amount of 1968 updates that the presence server may get, the need to keep the 1969 presence document aligned with its schema and the need to notify the 1970 users as soon as possible create a significant processing burden on 1971 the presence server 1973 4.2. Partial Publish and Notify 1975 Drafts [15], [16] define a way for the watcher to request getting 1976 only what was changed in the presence document and for the publisher 1977 of presence information to publish only what was changed in the 1978 presence document since the last publish. Although these 1979 optimizations help in reducing the amount of the data that is sent 1980 from/to the presence server, these optimizations create additional 1981 processing burden on the presence server. 1983 When a partial publish is arriving to the presence server, the 1984 presence server has to be able to process the partial publish, change 1985 only what is indicated in the partial publish while keeping the 1986 presence document in a well formed shape according to the schema. 1988 In partial notify the processing is even more complex since each 1989 watcher needs to get the partial update based on the last update that 1990 was received by that watcher. Therefore [15] specifies a versioning 1991 mechanism that enables the watcher to get the updates based on the 1992 previous state that it has seen. This versioning mechanism has to be 1993 maintained by the presence server for each watcher that is subscribed 1994 to a presentity and requires partial notify. 1996 4.3. Filtering 1998 Filtering as defined in RFCs [10], [11] enables a watcher to request 1999 to be notified only when the presence document fulfills certain 2000 conditions. Although this is a very convenient feature for watchers, 2001 the burden that is put on the presence server is quite big. For each 2002 change in the presence document, the presence server needs to compute 2003 the filtering expressions which can be very complex, decide whether 2004 and what to send to the watcher that have requested filtering. 2006 4.4. Authorization 2008 Draft [17] defines presence authorization rules that can be used by 2009 presentities to define who can see what from their presence 2010 documents. The processing that the presence server has to do here is 2011 very similar to filtering. When there is a change to any presence 2012 document that has privacy defined for it, the presence server needs 2013 to create different notification for different watchers according to 2014 what is defined in the authorization rules. 2016 4.5. Resource List Service 2018 RFC [12] defines a way to subscribe on a single URI while that URI is 2019 actually a list of resources that are being subscribed to by a single 2020 subscription. Although this is quite useful mechanism and it 2021 significantly saves on the number of sessions between the watcher and 2022 the presence server (as we show in the calculations of messages), 2023 this feature has the potential to make the scalability issue of 2024 presence systems harder and more complex. 2026 The reasons that resource lists may make the scalability problem of 2027 the presence server even more complex are: 2029 o Subscriptions and state - The resource list may contain reference 2030 to many other presence servers in many other domains. This 2031 requires the RLS to create subscriptions to other presence servers 2032 and buffer the state of all presentities in order to be able to 2033 provide the full state of the presentities in the list when 2034 needed. So in the overall system, the subscriptions that were 2035 saved between the watcher and the presence server are moved to the 2036 backend system while state has been duplicated between the various 2037 presence servers that serve the various presentities and the RLSs. 2038 This issue could have been mitigated if there was a way for the 2039 RLS to retrieve the presence information for many watchers while 2040 adhering to privacy when sending the actual notifications to the 2041 watchers. 2042 o Interlinkage - The resource list subscription will reach one RLS 2043 that will open it and send it to many presence servers and to 2044 other RLSs (if there is a subgroup inside the list). This way a 2045 complex linkage between the state of many components is created. 2046 This linkage makes state management and other maintenance of a 2047 presence systems quite complex. 2048 o Big lists are easy - There are two types of groups that may be 2049 used with this feature, private groups that are defined by/for 2050 each watcher and public groups that are defined in the system and 2051 can be used by any watcher. Although we should expect IT 2052 administrators to take caution when creating public groups, this 2053 may be not the case in real life. The connection between the size 2054 of the public group and the load on the presence server system may 2055 not apparent to everyone. Furthermore many public groups that are 2056 used in presence systems may have been created for other purposes 2057 as email systems (where the size of the lists was not so 2058 important) and are taken as they are to presence systems. So for 2059 example we may very easily find that a public group that actually 2060 covers all the users in the enterprise are used by many users in 2061 the enterprise thus creating unbearable load on the presence 2062 server. Note that this issue is not a protocol or design issue 2063 but more a usage issue that may have a real impact on the presence 2064 system. 2065 o Stopping notifications - A watcher may accidentally subscribe to a 2066 very big list and be overwhelmed by the amount of notifies that it 2067 receives from the presence server. There is no current way to 2068 stop this stream of notifies and even canceling the subscription 2069 may take time until being affective. 2071 The issues mentioned above are one example of an optimization that 2072 helps in one part of the system but creates even bigger problems in 2073 the overall system. There is a need to think about the problems 2074 listed above but more then that there is a need to make sure that 2075 when an optimization is introduced it does not create issues in other 2076 places. 2078 5. Current Optimizations 2080 This section lists and discusses several optimizations that are 2081 either already part of the SIP protocol or they have been suggested 2082 in various drafts. Several other optimizations that have been 2083 suggested but have not been discussed in any working group yet are 2084 summarized in [22] and in [24]. Note that trials with batched 2085 notifies optimization that is describes in [22], showed an 2086 improvement of 117% in the whole throughput of presence traffic. 2088 o Subnot-etags - Draft [20]. This draft suggests ways to suppress 2089 the sending of unnecessary notifies when for example a 2090 subscription is refreshed. This suggestion seems to be an 2091 efficient optimization since it saves both the number of messages 2092 sent and on the processing time of the presence server. 2093 o Resource List Service - [12] enable creating a single subscription 2094 session between the watcher and the presence server for 2095 subscribing on a list of users. This saves the amount of sessions 2096 that are created between watchers and presence servers. On the 2097 other hand, this mechanism enables creating very large amount of 2098 subscriptions in the presence server/RLS system thus enabling the 2099 creation of a very large number of subscriptions between presence 2100 servers and RLSs with relatively few clients especially if large 2101 public groups are used. It seems that in order to really optimize 2102 in this area, the usage of large public groups should not be 2103 considered as BCP and there should be a way for an RLS to create a 2104 single subscription for multiple occurrences of the same resource 2105 in resource lists. See consolidates subscriptions below. 2106 o Partial notify/publish - Drafts [15], [16] define a way for the 2107 subscriber to request getting only what was changed in the 2108 presence document and for the publisher of presence information to 2109 publish only what was changed in the presence document since the 2110 last publish. Although these optimizations help in reducing the 2111 amount of actual data that is sent from/to the presence server, 2112 these optimizations create additional processing burden on the 2113 presence server as was discussed above. 2114 o Filtering as defined in RFCs [10], [11] enables a watcher to 2115 request to be notified only when the presence document fulfills 2116 certain conditions. Although this optimization enables saving on 2117 the amount of messages that are sent from the presence server to 2118 the watcher, this optimization puts more burden on the processing 2119 time of the presence server as was discussed above. 2121 o Throttling [23] defines a mechanism in which a watcher requires to 2122 be updated only in certain intervals. Although this mechanism may 2123 give some extra load on the processing time of the presence 2124 server, that load is negligible and the reduction on the amount of 2125 messages sent from the presence server to the watchers is 2126 significant. This optimization is even more important with 2127 resource lists where there can be many resources in the resource 2128 lists and if the traffic of updates on resource list is not 2129 regulated, the watcher may get very large amount of notifications. 2130 o Presence specific sigcomp dictionary [18] defines a SIGCOMP [3] 2131 dictionary for presence. This optimization will enable to reduce 2132 the number of bytes that are transferred in presence systems by 2133 compressing the textual SIP messages and using the specialized 2134 presence dictionary the compression may be more significant then 2135 just using SIGCOMP as is. Note that number of actual messages 2136 will remain the same and a calculation of the amount of bytes that 2137 will be saved may be useful here. 2138 o Content Indirection [9] enables sending only the URI of the 2139 presence document to the watcher thus offloading the presence 2140 server from sending the presence document to the watcher. This 2141 optimization may be useful in some cases especially where there is 2142 a big number of users that get the same presence document. 2144 6. Summary 2146 Following is a summary of the various calculations. This is repeated 2147 here in order to ease the understanding of the conclusions that are 2148 listed below. 2150 The following table summarizes the various constants that are used in 2151 ALL calculations. 2153 (C01) Subscription lifetime (hours)...........................8 2154 (C03) Subscription refresh interval / hour....................1 2155 (C05) Number of dialogs to maintain per watcher = Number of 2156 federated presentities when dialog optimization is 2157 not used and to 1 when dialog optimization is used. 2158 (C07) SUBSCRIBE message size in bytes.......................450 2159 (C08) 200 OK for SUBSCRIBE message size in bytes............370 2160 (C09) NOTIFY message size not including presence doc........500 2161 (C10) 200 OK for NOTIFY message size in bytes...............370 2162 (C11) Size of an average presence document..........350 or 3000 2163 Calculations are done for both sizes 2164 (C12) Size of an average partial presence document..........200 2165 (C13) Additional data per document in RLMI..................160 2166 (C14) Multiparty boundary in RLMI document..................144 2167 (C15) XML root node in RLMI document........................144 2169 Figure 13: Constants in ALL calculations 2171 The following table summarizes the results of various optimization 2172 factors for the basic use case. 2174 C02 Presence state changes / hour.............................3 2175 C04 Total federated presentities per watcher..................4 2176 C06 Total # of watchers in the federated domains.........40,000 2178 No optimizations are applied 2180 B01 Total of messages between domains................12,800,000 2181 Total of bytes between domains (PD=350).........7,232,000,000 2182 Total of bytes between domains (PD=3000).......20,376,000,000 2183 B02 Total number of messages / second.......................444 2184 Total of bytes per second (PD=350)....................251,111 2185 Total of bytes per second (PD=3000)...................707,500 2186 B03 Total number of by msgs per user/day....................320 2187 Total number of bytes per user/day (PD=350)...........180,800 2188 Total number of bytes per user/day (PD=3000)..........509,400 2190 Dialog optimization is applied 2192 B01 Total of messages between domains.................8,480,000 2193 Total of bytes between domains (PD=350).........7,394,880,000 2194 Total of bytes between domains (PD=3000).......20,220,880,000 2195 B02 Total number of messages / second.......................294 2196 Total of bytes per second (PD=350)....................256,767 2197 Total of bytes per second (PD=3000)...................702,114 2198 B03 Total number of by msgs per user/day....................212 2199 Total number of bytes per user/day (PD=350)...........184,872 2200 Total number of bytes per user/day (PD=3000)..........505,522 2202 Notify optimization is applied 2204 B01 Total of messages between domains................10,240,000 2205 Total of bytes between domains (PD=350).........5,670,400,000 2206 Total of bytes between domains (PD=3000).......15,422,400,000 2207 B02 Total number of messages / second.......................356 2208 Total of bytes per second (PD=350)....................196,889 2209 Total of bytes per second (PD=3000)...................535,500 2210 B03 Total number of by msgs per user/day....................256 2211 Total number of bytes per user/day (PD=350)...........141,760 2212 Total number of bytes per user/day (PD=3000)..........385,560 2214 Dialog and notify optimizations are applied 2216 B01 Total of messages between domains.................7,840,000 2217 Total of bytes between domains (PD=350).........6,311,760,000 2218 Total of bytes between domains (PD=3000).......16,063,760,000 2219 B02 Total number of messages / second.......................272 2220 Total of bytes per second (PD=350)....................219,158 2221 Total of bytes per second (PD=3000)...................557,769 2222 B03 Total number of by msgs per user/day....................196 2223 Total number of bytes per user/day (PD=350)...........157,794 2224 Total number of bytes per user/day (PD=3000)..........401,594 2226 Figure 14: Basic use case 2228 The following table summarizes the results of various optimization 2229 factors for the widely distributed inter domain use case. 2231 C02 Presence state changes / hour.............................3 2232 C04 Total federated presentities per watcher.................20 2233 C06 Total # of watchers in the federated domains.........40,000 2235 No optimizations are applied 2237 B01 Total of messages between domains................64,000,000 2238 Total of bytes between domains (PD=350)........36,160,000,000 2239 Total of bytes between domains (PD=3000)......101,880,000,000 2240 B02 Total number of messages / second.....................2,222 2241 Total of bytes per second (PD=350)..................1,255,556 2242 Total of bytes per second (PD=3000).................3,537,500 2243 B03 Total number of by msgs per user/day..................1,600 2244 Total number of bytes per user/day (PD=350)...........904,000 2245 Total number of bytes per user/day (PD=3000)........2,547,000 2247 Dialog and notify optimizations are applied 2249 B01 Total of messages between domains................36,000,000 2250 Total of bytes between domains (PD=350)........30,215,760,000 2251 Total of bytes between domains (PD=3000).......78,975,760,000 2252 B02 Total number of messages / second.....................1,250 2253 Total of bytes per second (PD=350)..................1,049,158 2254 Total of bytes per second (PD=3000).................2,742,214 2255 B03 Total number of by msgs per user/day....................900 2256 Total number of bytes per user/day (PD=350)...........755,394 2257 Total number of bytes per user/day (PD=3000)........1,974,394 2259 Figure 15: Widely distributed inter-domain 2261 The following table summarizes the results of various optimization 2262 factors for the intra-domain peering use case. 2264 C02 Presence state changes / hour.............................3 2265 C04 Total federated presentities per watcher.................10 2266 C06 Total # of watchers in the federated domains........120,000 2268 No optimizations are applied 2270 B01 Total of messages between domains................96,000,000 2271 Total of bytes between domains (PD=350)........54,240,000,000 2272 Total of bytes between domains (PD=3000)......152,820,000,000 2273 B02 Total number of messages / second.....................3,333 2274 Total of bytes per second (PD=350)..................1,883,333 2275 Total of bytes per second (PD=3000).................5,306,250 2276 B03 Total number of by msgs per user/day....................800 2277 Total number of bytes per user/day (PD=350)...........452,000 2278 Total number of bytes per user/day (PD=3000)........1,273,500 2280 Dialog and notify optimizations are applied 2282 B01 Total of messages between domains................55,200,000 2283 Total of bytes between domains (PD=350)........45,827,280,000 2284 Total of bytes between domains (PD=3000)......118,967,280,000 2285 B02 Total number of messages / second.....................1,917 2286 Total of bytes per second (PD=350)..................1,591,225 2287 Total of bytes per second (PD=3000).................4,130,808 2288 B03 Total number of by msgs per user/day....................460 2289 Total number of bytes per user/day (PD=350)...........381,894 2290 Total number of bytes per user/day (PD=3000)..........991,394 2292 Figure 16: Inter-domain peering 2294 The following table summarizes the results of various optimization 2295 factors for the very large scale peering networks use case. 2297 C02 Presence state changes / hour.............................6 2298 C04 Total federated presentities per watcher.................10 2299 C06 Total # of watchers in the federated domains.....20,000,000 2301 No optimizations are applied 2303 B01 Total of messages between domains............25,600,000,000 2304 Total of bytes between domains (PD=350)....14,896,000,000,000 2305 Total of bytes between domains (PD=3000)...44,046,000,000,000 2306 B02 Total number of messages / second...................888,889 2307 Total of bytes per second (PD=350)................517,222,222 2308 Total of bytes per second (PD=3000).............1,529,375,000 2309 B03 Total number of by msgs per user/day..................1,280 2310 Total number of bytes per user/day (PD=350)...........744,800 2311 Total number of bytes per user/day (PD=3000)........2,202,300 2313 Dialog and notify optimizations are applied 2315 B01 Total of messages between domains............18,800,000,000 2316 Total of bytes between domains (PD=350)....15,644,400,000,000 2317 Total of bytes between domains (PD=3000)...40,554,280,000,000 2318 B02 Total number of messages / second...................652,778 2319 Total of bytes per second (PD=350)................543,208,333 2320 Total of bytes per second (PD=3000).............1,408,134,722 2321 B03 Total number of by msgs per user/day....................940 2322 Total number of bytes per user/day (PD=350)...........782,220 2323 Total number of bytes per user/day (PD=3000)........2,027,714 2325 Partial and notify optimizations are applied 2327 B01 Total of messages between domains............22,400,000,000 2328 Total of bytes between domains (PD=350)....11,564,000,000,000 2329 Total of bytes between domains (PD=3000)...12,094,000,000,000 2330 B02 Total number of messages / second...................777,778 2331 Total of bytes per second (PD=350)................401,527,778 2332 Total of bytes per second (PD=3000)...............419,930,556 2333 B03 Total number of by msgs per user/day..................1,120 2334 Total number of bytes per user/day (PD=350)...........578,200 2335 Total number of bytes per user/day (PD=3000)..........604,700 2337 Calculation for other protocols 2339 B01 Total of messages between domains.............9,800,000,000 2340 Total of bytes between domains (PD=50)......1,940,000,000,000 2341 Total of bytes between domains (PD=350).....4,760,000,000,000 2342 Total of bytes between domains (PD=3000)...29,670,000,000,000 2343 B02 Total number of messages / second...................340,278 2344 Total of bytes per second (PD=50)..................67,361,111 2345 Total of bytes per second (PD=350)................165,277,778 2346 Total of bytes per second (PD=3000).............1,030,208,333 2347 B03 Total number of by msgs per user/day....................490 2348 Total number of bytes per user/day (PD=50).............97,000 2349 Total number of bytes per user/day (PD=350)...........238,000 2350 Total number of bytes per user/day (PD=3000)........1,483,500 2352 Figure 17: Very large scale peering networks 2354 7. Conclusions 2356 The following conclusions can be drawn from the above numbers: 2358 o Due to the overhead of RLMI (that was not included in the previous 2359 version of this document), the dialog optimization does not help 2360 in reducing the number of bytes nor in the number of the messages. 2361 It seems to be more important from the point of view of the 2362 convenience of the user since it enables the user to manage his/ 2363 hers watch list. 2364 o The notify optimization optimizes both the number of messages and 2365 the number of bytes. 2366 o Partial notification saves a lot in the number of bytes especially 2367 when the presence document is a rich presence document which is 2368 relatively big. 2369 o Comparing to protocols that do not have the overhead of SIP (e.g. 2370 XMPP) shows that the number of messages is less by about a half. 2371 The number of bytes is also reduced by about a half. It is 2372 interesting to see that when the presence document is big (3000 2373 bytes) and partial and notify optimizations are applied, the 2374 number of bytes is smaller in SIP! 2375 o When looking at the numbers from the perspective of the number of 2376 bytes that a user "consumes" per day the numbers may not look so 2377 big. Nevertheless, we should remember that the overall affect on 2378 the network may be quite big since the network will have to convey 2379 dozens of Giga bytes per day for the modest use cases that are 2380 described in this document for presence traffic only. Recalling 2381 that presence is only an enabler for other media these numbers are 2382 not so easy to handle. 2384 The document analyzes the scalability of presence systems and of the 2385 SIP based in particular. It is apparent that the scalability of 2386 these systems is far from being trivial from several perspectives: 2387 number of messages, network bandwidth, state management and CPU load. 2389 As part of the analysis we have analyzed several optimizations and 2390 showed the effect of these optimizations on the number of messages 2391 and the number of bytes that are sent between the federating domains. 2393 We have also computed the number of messages and bytes for a very 2394 large scale peering network while assuming a protocol that has much 2395 less overhead then SIP. Even in that protocol we got relatively high 2396 numbers. 2398 It is very possible that the issues that are described in this 2399 document are inherent to presence systems in general and not specific 2400 to the SIMPLE protocol. Organizations need to be prepared to invest 2401 a lot in network and hardware in order to create real big systems. 2402 However, it is apparent that not all the possible optimizations were 2403 done yet and further work is needed in the IETF in order to provide 2404 better scalability 2405 Nevertheless, we should remember that SIP was originally designed for 2406 end to end session creation and number and size of messages are of 2407 secondary importance for end to end session negotiation. For large 2408 scale and especially for very large scale presence the number of 2409 messages that are needed and the size of each message are of extreme 2410 importance. It seems that we need to think about the problem in a 2411 different way. We need to think about scalability as part of the 2412 protocol design. The IETF tends not to think about actual 2413 deployments when designing a protocol but in this case it seems that 2414 if we do not think about scalability with the protocol design it will 2415 be very hard to scale. 2417 We should also consider whether using the same protocol between 2418 clients and servers and between servers is a good choice with this 2419 problem? It may be that in interdomain or even between servers in 2420 the same domain (as between RLSs and presence servers) there is a 2421 need to have a different protocol that will be very optimized for the 2422 load and can assume some assumptions about the network (e.g. do not 2423 use unreliable protocol as UDP but only TCP). 2425 When servers is connecting to another server using current protocol, 2426 there will be an extreme number of redundant messages due to the 2427 overhead of supporting UDP and to the need to send multiple presence 2428 documents for the same watched user due to privacy issue. A server 2429 to server protocol will have to address these issues. Some initial 2430 work to address these issues can be found in: [22], [24] and [25] 2432 Another issue that is more concerning protocol design is whether 2433 NOTIFY messages should not be considered as media as audio, video and 2434 even text messaging are considered? The SUBSCRIBE can be extended to 2435 do similar three way handshake as INVITE and negotiate where the 2436 notify messages should go, rate and other parameters. This way the 2437 load can be offloaded to a specialized NOTIFY "relays" thus not 2438 loading the control path of SIP. One of the possible ideas (Marc 2439 Willekens) is to use the SIP stack for the client/server NOTIFY but 2440 make use of a more optimized and controllable protocol for the 2441 server-to-server interface. Another possibility is to use the MSRP 2442 [13], [14]protocol for the notifies. 2444 8. Security Considerations 2446 This document discusses scalability issues with the existing SIP/ 2447 SIMPLE presence protocol and model. Therefore, there are no security 2448 considerations to be considered for this document. However, a lot of 2449 the possible optimizations that should emerge as a result of this 2450 document will have security implications that will need to be solved. 2452 9. Changes from Previous Versions 2454 9.1. Changes in version 03 2456 o Added some input from real life deployments and input on a test 2457 with batched notifies. 2458 o Added Calculations of messages and bytes per user. 2459 o Calculations are now done both for minimal size of presence 2460 document and for an average size of rich presence document. 2461 o Comparison with other protocol is now done using small, tiny and 2462 rich presence document sizes. 2463 o Removed dialog optimization with partial notification since it is 2464 not relevant 2465 o Fixed a few issues in calculations that were found by Victoria 2466 Beltran-Martinez. 2467 * Added overhead for RLMI for dialog optimizations (list 2468 subscription). This calculation fix actually shows that dialog 2469 optimization is not a real optimization from the point of view 2470 of bytes and number of messages. 2471 * When NOTIFY optimizations are applied no need for final NOTIFY 2472 * The usage of RLS between domains was clarified. 2473 o Significantly enhanced the conclusions section 2474 o Several typo fixes 2476 9.2. Changes in version 02 2478 o Fixed a bug in the calculations. Thanks to Marc Willekens for 2479 finding the bug. 2481 9.3. Changes in version 01 2483 o Clarifications and corrections of the computation model and the 2484 computations. 2485 o Added several more computations to show the influence of different 2486 optimizations. 2487 o The requirements were moved to [21] 2488 o The new suggestions for optimizations were moved to [22] 2490 10. Acknowledgments 2492 We would like to thank Jonathan Rosenberg, Ben Campbell, Markus 2493 Isomaki Piotr Boni, David Viamonte and Aki Niemi for ideas and input. 2494 Special thanks to Marc Willekens and Victoria Beltran-Martinez for 2495 finding issues in the calculations. 2497 11. References 2498 11.1. Normative References 2500 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2501 Levels", BCP 14, RFC 2119, March 1997. 2503 11.2. Informational References 2505 [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 2506 Notification", RFC 3265, June 2002. 2508 [3] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, 2509 Z., and J. Rosenberg, "Signaling Compression (SigComp)", 2510 RFC 3320, January 2003. 2512 [4] Rosenberg, J., "A Watcher Information Event Template-Package 2513 for the Session Initiation Protocol (SIP)", RFC 3857, 2514 August 2004. 2516 [5] Rosenberg, J., "An Extensible Markup Language (XML) Based 2517 Format for Watcher Information", RFC 3858, August 2004. 2519 [6] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and 2520 J. Peterson, "Presence Information Data Format (PIDF)", 2521 RFC 3863, August 2004. 2523 [7] Saint-Andre, P., "End-to-End Signing and Object Encryption for 2524 the Extensible Messaging and Presence Protocol (XMPP)", 2525 RFC 3923, October 2004. 2527 [8] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, 2528 "RPID: Rich Presence Extensions to the Presence Information 2529 Data Format (PIDF)", RFC 4480, July 2006. 2531 [9] Burger, E., "A Mechanism for Content Indirection in Session 2532 Initiation Protocol (SIP) Messages", RFC 4483, May 2006. 2534 [10] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 2535 Requena, "Functional Description of Event Notification 2536 Filtering", RFC 4660, September 2006. 2538 [11] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 2539 Requena, "An Extensible Markup Language (XML)-Based Format for 2540 Event Notification Filtering", RFC 4661, September 2006. 2542 [12] Roach, A., Campbell, B., and J. Rosenberg, "A Session 2543 Initiation Protocol (SIP) Event Notification Extension for 2544 Resource Lists", RFC 4662, August 2006. 2546 [13] Campbell, B., Mahy, R., and C. Jennings, "The Message Session 2547 Relay Protocol (MSRP)", RFC 4975, September 2007. 2549 [14] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the 2550 Message Sessions Relay Protocol (MSRP)", RFC 4976, 2551 September 2007. 2553 [15] Lonnfors, M., "Session Initiation Protocol (SIP) extension for 2554 Partial Notification of Presence Information", 2555 draft-ietf-simple-partial-notify-09 (work in progress), 2556 February 2007. 2558 [16] Lonnfors, M., "Publication of Partial Presence Information", 2559 draft-ietf-simple-partial-publish-06 (work in progress), 2560 February 2007. 2562 [17] Rosenberg, J., "Presence Authorization Rules", 2563 draft-ietf-simple-presence-rules-10 (work in progress), 2564 July 2007. 2566 [18] Garcia-Martin, M., "The Presence-Specific Static Dictionary for 2567 Signaling Compression (Sigcomp)", 2568 draft-garcia-simple-presence-dictionary-06 (work in progress), 2569 August 2007. 2571 [19] Camarillo, G., "Subscriptions to Request-Contained Resource 2572 Lists in the Session Initiation Protocol (SIP)", 2573 draft-ietf-sipping-uri-list-subscribe-05 (work in progress), 2574 May 2006. 2576 [20] Niemi, A., "An Extension to Session Initiation Protocol (SIP) 2577 Events for Conditional Event Notification", 2578 draft-ietf-sip-subnot-etags-01 (work in progress), August 2007. 2580 [21] Houri, A., "Scaling Requirements for Presence in SIP/SIMPLE", 2581 draft-houri-sipping-presence-scaling-requirements-01 (work in 2582 progress), November 2007. 2584 [22] Houri, A., "Scaling Optimizations for Presence in SIP/SIMPLE", 2585 draft-houri-simple-interdomain-scaling-optimizations-00 (work 2586 in progress), July 2007. 2588 [23] Niemi, A., "Session Initiation Protocol (SIP) Event 2589 Notification Extension for Notification Throttling", 2590 draft-niemi-sipping-event-throttle-05 (work in progress), 2591 March 2007. 2593 [24] Rosenberg, J., Donovan, S., and K. McMurry, "Optimizing 2594 Federated Presence with View Sharing", 2595 draft-rosenberg-simple-view-sharing-00 (work in progress), 2596 November 2007. 2598 [25] Rosenberg, J., "Models for Intra-Domain Presence Federation", 2599 draft-rosenberg-simple-intradomain-federation-00 (work in 2600 progress), November 2007. 2602 Authors' Addresses 2604 Avshalom Houri 2605 IBM 2606 Science Park Building 18/D 2607 Rehovot, 2608 Israel 2610 Email: avshalom@il.ibm.com 2612 Edwin Aoki 2613 AOL LLC 2614 360 W. Caribbean Drive 2615 Sunnyvale, CA 94089 2616 USA 2618 Email: aoki@aol.net 2620 Sriram Parameswar 2621 Microsoft Corporation 2622 One Microsoft Way 2623 Redmond, WA 98052 2624 USA 2626 Email: Sriram.Parameswar@microsoft.com 2628 Tim Rang 2629 Microsoft Corporation 2630 One Microsoft Way 2631 Redmond, WA 98052 2632 USA 2634 Email: timrang@microsoft.com 2635 Vishal Singh 2636 Columbia University 2637 Department of Computer Science 2638 450 Computer Science Building 2639 New York, NY 10027 2640 US 2642 Email: vs2140@cs.columbia.edu 2643 URI: http://www.cs.columbia.edu/~vs2140 2645 Henning Schulzrinne 2646 Columbia University 2647 Department of Computer Science 2648 450 Computer Science Building 2649 New York, NY 10027 2650 US 2652 Phone: +1 212 939 7004 2653 Email: hgs+ecrit@cs.columbia.edu 2654 URI: http://www.cs.columbia.edu/~hgs 2656 Full Copyright Statement 2658 Copyright (C) The IETF Trust (2007). 2660 This document is subject to the rights, licenses and restrictions 2661 contained in BCP 78, and except as set forth therein, the authors 2662 retain all their rights. 2664 This document and the information contained herein are provided on an 2665 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2666 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2667 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2668 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2669 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2670 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2672 Intellectual Property 2674 The IETF takes no position regarding the validity or scope of any 2675 Intellectual Property Rights or other rights that might be claimed to 2676 pertain to the implementation or use of the technology described in 2677 this document or the extent to which any license under such rights 2678 might or might not be available; nor does it represent that it has 2679 made any independent effort to identify any such rights. Information 2680 on the procedures with respect to rights in RFC documents can be 2681 found in BCP 78 and BCP 79. 2683 Copies of IPR disclosures made to the IETF Secretariat and any 2684 assurances of licenses to be made available, or the result of an 2685 attempt made to obtain a general license or permission for the use of 2686 such proprietary rights by implementers or users of this 2687 specification can be obtained from the IETF on-line IPR repository at 2688 http://www.ietf.org/ipr. 2690 The IETF invites any interested party to bring to its attention any 2691 copyrights, patents or patent applications, or other proprietary 2692 rights that may cover technology that may be required to implement 2693 this standard. Please address the information to the IETF at 2694 ietf-ipr@ietf.org. 2696 Acknowledgment 2698 Funding for the RFC Editor function is provided by the IETF 2699 Administrative Support Activity (IASA).