idnits 2.17.1 draft-ietf-simple-interdomain-scaling-analysis-02.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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2226. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2237. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2244. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2250. 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 (October 29, 2007) is 6014 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 2088, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 2093, 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 (-06) exists of draft-garcia-simple-presence-dictionary-05 == Outdated reference: A later version (-03) exists of draft-ietf-sip-subnot-etags-00 == Outdated reference: A later version (-01) exists of draft-houri-sipping-presence-scaling-requirements-00 == Outdated reference: A later version (-08) exists of draft-niemi-sipping-event-throttle-05 Summary: 2 errors (**), 0 flaws (~~), 9 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 T. Rang 5 Expires: January 25, 2008 Microsoft Corporation 6 E. Aoki 7 AOL LLC 8 V. Singh 9 H. Schulzrinne 10 Columbia U. 11 October 29, 2007 13 Presence Interdomain Scaling Analysis for SIP/SIMPLE 14 draft-ietf-simple-interdomain-scaling-analysis-02.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on January 25, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 The document analyses the traffic that is generated due to presence 48 subscriptions between domains. It is shown that the amount of 49 traffic can be extremely big. In addition to the very large traffic 50 the document also analyses the affects of a large presence system on 51 the memory footprint and the CPU load. Current approved and in work 52 optimizations to the SIMPLE protocol are analysed with the possible 53 impact on the load. Separate documents contain the requirements for 54 optimizations and suggestions for new optimizations. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Message Load . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.1. Known Optimizations . . . . . . . . . . . . . . . . . . . 5 61 2.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.3. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.3.1. Constants . . . . . . . . . . . . . . . . . . . . . . 7 64 2.3.2. Initial Messages . . . . . . . . . . . . . . . . . . . 8 65 2.3.3. Steady State Messages . . . . . . . . . . . . . . . . 9 66 2.3.4. Termination Messages . . . . . . . . . . . . . . . . . 10 67 2.3.5. Bottom Line . . . . . . . . . . . . . . . . . . . . . 10 68 2.3.6. Rush Hour Calculations . . . . . . . . . . . . . . . . 10 69 2.4. SIMPLE with no optimizations . . . . . . . . . . . . . . . 11 70 2.5. SIMPLE with dialog optimization . . . . . . . . . . . . . 13 71 2.6. SIMPLE with NOTIFY optimization . . . . . . . . . . . . . 15 72 2.7. SIMPLE with Dialog & NOTIFY optimizations . . . . . . . . 17 73 2.8. Presence Federations . . . . . . . . . . . . . . . . . . . 19 74 2.8.1. Widely distributed inter-domain presence . . . . . . . 19 75 2.8.2. Associated inter-domain presence . . . . . . . . . . . 23 76 2.8.3. Very large network peering . . . . . . . . . . . . . . 24 77 2.8.4. Intra-domain peering . . . . . . . . . . . . . . . . . 28 78 2.9. Partial Notifications Optimization . . . . . . . . . . . . 32 79 2.10. Other Protocols . . . . . . . . . . . . . . . . . . . . . 34 80 3. State Management . . . . . . . . . . . . . . . . . . . . . . . 37 81 3.1. State Size Calculations . . . . . . . . . . . . . . . . . 38 82 3.1.1. Tiny System . . . . . . . . . . . . . . . . . . . . . 38 83 3.1.2. Medium System . . . . . . . . . . . . . . . . . . . . 38 84 3.1.3. Large System . . . . . . . . . . . . . . . . . . . . . 38 85 3.1.4. Very Large System . . . . . . . . . . . . . . . . . . 38 86 4. Processing complexities . . . . . . . . . . . . . . . . . . . 39 87 4.1. Aggregation . . . . . . . . . . . . . . . . . . . . . . . 40 88 4.2. Partial Publish and Notify . . . . . . . . . . . . . . . . 40 89 4.3. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 40 90 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 41 91 4.5. Resource List Service . . . . . . . . . . . . . . . . . . 41 92 5. Current Optimizations . . . . . . . . . . . . . . . . . . . . 42 93 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 43 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 44 95 8. Changes from Previous Versions . . . . . . . . . . . . . . . . 45 96 8.1. Changes in version 02 . . . . . . . . . . . . . . . . . . 45 97 8.2. Changes in version 01 . . . . . . . . . . . . . . . . . . 45 98 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45 99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 100 10.1. Normative References . . . . . . . . . . . . . . . . . . . 45 101 10.2. Informational References . . . . . . . . . . . . . . . . . 45 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 103 Intellectual Property and Copyright Statements . . . . . . . . . . 49 105 1. Introduction 107 The document analyses the traffic that is generated due to presence 108 subscriptions between domains. It is shown that the amount of 109 traffic can be extremely big. In addition to the very large traffic 110 the document also analyses the affects of a large presence system on 111 the memory footprint and the CPU load. Current approved and in work 112 optimizations to the SIMPLE protocol are analysed with the possible 113 impact on the load. Separate documents contain the requirements for 114 optimizations [17] and suggestions for new optimizations [18]. 116 This document is intended to be used by the SIMPLE WG in order to 117 work on possible solutions that will make the deployment of a 118 presence server more reasonable task. Note that the document does 119 not try to compare the SIP based presence server to other types of 120 presence servers but only analyses the SIP based presence server. It 121 is very likely that similar scalability issues are inherent to the 122 deployment of presence systems and not to a certain protocol. 124 The document discusses the following areas. In each area we try to 125 show the complexity and the load that the presence server has to 126 handle in order to provide its service. 128 o Messages load - By computing the number of messages that are 129 required for connecting presence systems the document shows that 130 the number of messages is very big and it is quite obvious that 131 some optimizations are needed. In addition we also show that the 132 bandwidth required is also very big. 133 o State management - Due to the nature of the service that the 134 presence server provides, the presence server has to manage a 135 relatively big and complex state and some computations are 136 provided in the document. 137 o Processing complexities - The presence server maintains many small 138 objects and has to do frequent operations on these objects. We 139 show that these operations and especially the optimizations that 140 are intended to save on the amount of data that is being sent 141 between watchers and presence servers, are not so simple and may 142 create a very heavy processing load on the presence server. 143 o Groups - Resource List Servers [10] optimize the number of 144 sessions that are created between the watchers and the presence 145 server. On the other hand, this optimization may create an 146 exponential size of subscription due to the unbearable ease of 147 subscribing to large groups. 149 The term presence domain or presence system appears in the document 150 several time. By this term we refer to a presence server that 151 provides presence subscription and notification services to its 152 users. The system can be a system that is deployed in a small 153 enterprise or in a very large consumer network. 155 2. Message Load 157 Even though some optimizations are approved or are being defined, we 158 show in this section that a very large number of messages & large 159 bandwidth are needed in order to establish federation between 160 presence systems of large communities. Further thinking is needed in 161 order to make large deployment of presence systems less resource 162 demanding. 164 Note that even though this document talks about inter domain traffic, 165 the introduction of resource list servers (RLSs) [10] introduce very 166 similar traffic pattern within a domain as between domains. See 167 detailed discussion on resource lists in Section 4.5. 169 2.1. Known Optimizations 171 The current optimizations that are approved or are approved as 172 working group items in the SIMPLE working group can be divided into 173 two categories: 175 o Dialogs saving optimization - Here we refer to optimizations as 176 the resource list RFC [10] or to the Uri list subscriptions draft 177 [15]. These documents define ways to reduce the number of dialogs 178 that are required between the subscriber and the presence system. 179 o Notification optimizations - Here we refer to the optimizations 180 that are suggested in the subnot-etags draft [16]. This draft 181 suggests ways to suppress the sending of unnecessary notifies when 182 for example a subscription is refreshed. There are other drafts 183 that reduce the size of messages as partial notifies or filtering 184 but in this document we mostly care about the amount of messages & 185 bandwidth so the partial optimizations can help a bit in the 186 bandwidth but will not help in the number of messages. 188 2.2. Assumptions 190 In the document we have several assumptions regarding size of 191 messages, rate of presence change and more. It should be noted that 192 these assumptions are not directly based on rigorous statistics that 193 was done on actual SIP based messages but more from experience on 194 other types of presence based systems. 196 Even though the assumptions in this document are not based on 197 rigorous statistical data the target here is not to analyse specific 198 system but show that even with VERY moderate assumptions, the number 199 of messages, the network bandwidth, the required state management and 200 the load on the CPU is very high. Real life systems should have a 201 much bigger scalability requirements. for example the presence state 202 change that we assumed (one presence state change per hour) is maybe 203 one of the most moderate assumptions that we have taken. Experience 204 from consumer networks show that the frequency here is much bigger 205 and especially with the younger generation. In an environment where 206 a user may have several devices and other resources for presence 207 information as geographical location and calendar the frequency of 208 presence state changes will be much higher. 210 It is very hard to measure presence load since the behavior of users 211 is very different. Some users will have a very small number of 212 presentities in their watch list while others may have hundreds. 213 Some users will change their state a lot and have many sources of 214 presence information while others may have very small number of 215 changes during the day. In addition the "rush hour" calculation of 216 when the day starts and ends was not included yet in this document 217 yet (to be added). Rush hour differs between different enterprises 218 and is still different in the consumer presence systems. It is very 219 hard if not impossible to take into a static model all the possible 220 combinations. 222 Saying the above, there are still several things to be done to create 223 a more complete picture: 225 o Get rigorous statistical data that can be formally published from 226 real presence systems. 227 o Add to the model the possibility of having multiple sources of 228 presence data per presentity and change calculations accordingly 229 o Add "rush hour" calculations for the end and the beginning of the 230 day 232 The authors will especially appreciate any input in this area that 233 will help us to create a more real life model. We intend to try and 234 gather more data and improve the assumptions and the model in the 235 next revisions of this document. 237 2.3. Analysis 239 The basic SIMPLE subscription dialog involves the following message- 240 transfer: 242 o SUBSCRIBE/200 243 o Initial NOTIFY/200 244 o (j) NOTIFY/200 where 'j' is the number of presence changes seen by 245 the watcher 247 o (k) SUBSCRIBE/200 where 'k' is the number of subscription dialog 248 refresh periods 249 o SUBSCRIBE/200 with Expires = 0 to terminate the dialog 250 o NOTIFY/200 ending the dialog 252 An individual watcher will generate X number of SIMPLE subscription 253 dialogs corresponding to the number of presentities it chooses to 254 watch. The amount of traffic generated is significantly affected by 255 several factors: 257 o Number of watchers connected to the system 258 o Number of presentities connected to the system 259 o Frequency of changes to presence information 261 This document contains several calculations that show the expected 262 message rate and bandwidth between presence domains. The following 263 sections explain the assumptions and methods behind the calculations. 265 2.3.1. Constants 267 The following are number of "constants" that we use in the 268 calculations. Some of the constants are used throughout the 269 calculation while other change between use cases 271 o (C01) Subscription lifetime (hours)- The assumed lifetime of a 272 subscription in hours. We assume 8 hours for all calculations. 273 o (C02) Presence state changes / hour - The average time that a 274 presentity changes his/hers status in one hour. We assumed 3 275 times per hour for most calculations. Note that for some users in 276 consumer messaging systems, the actual number of changes is likely 277 to be much higher. 278 o (C03) Subscription refresh interval / hour - The duration of the 279 SUBSCRIBE session after which it needs to be refreshed. We 280 assumed that the duration is one hour. 281 o (C04) Total federated presentities per watcher - The number of 282 presentities that the watcher is watching. The number here 283 changes in this document according to the type of the specific 284 deployment. 285 o (C05) Number of dialogs to maintain per watcher - The number of 286 the SUBSCRIBE dialogs that are maintained per watcher. if a dialog 287 optimization is not assumed this number is equal to A04, otherwise 288 it is 1. 289 o (C06) Total number of watchers in the federated presence domains. 290 The number here is the number of all watchers in all the federated 291 domains. 292 o (C07) SUBSCRIBE message size in bytes. We assume 450 bytes in all 293 calculations. The size is based on a typical SUBSCIRBE taken from 294 RFCs. 296 o (C08) 200 OK for SUBSCRIBE message size in bytes. We assume 370 297 bytes in all calculations. The size is based on a typical 200 OK 298 taken from RFCs. 299 o (C09) NOTIFY message size not including the presence document. 300 The size of this message for a single presentity is assumed to be 301 500 bytes for the NOTIFY message itself (based on sizes from 302 examples in RFCs). 303 o (C10) 200 OK for NOTIFY message size in bytes. We assume 370 304 bytes in all calculations. The size is based on a typical 200 OK 305 taken from RFCs. 306 o (C11) Size of an average presence document. The size is assumed 307 to be 3000 bytes based on sizes from examples in RFCs. Note that 308 assuming 3000 bytes for presence document is relatively modest if 309 we take into account multiple devices and location information. 310 When there will be multiple presentities in the same NOTIFY as in 311 the initial NOTIFY for a resource list [10] or there is less 312 information in the presence document due to partial notifications 313 these factors will be taken into account. 315 2.3.2. Initial Messages 317 The following are the calculations for the messages in the initial 318 phase of the establishment of the subscriptions. The calculations 319 contain both number of messages and the number of bytes. 321 o (I01) Number of initial SUBSCRIBE messages per watcher = C05. 322 o (I02) Number of initial 200 OK messages for SUBSCRIBE messages per 323 watcher = C05. 324 o (I03) Number of initial NOTIFY messages per watcher = C05. 325 o (I04) Number of initial 200 OK messages for NOTIFY messages per 326 watcher = C05. 327 o (I05) Total number and bytes of initial SUBSCRIBE messages for all 328 watchers = Number - I01*C06, Bytes - I01*C06*C07. 329 o (I06) Total number and bytes of initial 200 OK for SUBSCRIBE 330 messages for all watchers = Number - I01*C06, Bytes - I01*C06*C08. 331 o (I07) Total number and bytes of initial NOTIFY messages for all 332 watchers = Number - I01*C06, Bytes - (I03*C06*C09)+((C04/ 333 C05)*C11). The calculation of the size is a bit complicates since 334 it takes into account the case where the optimization of resource 335 lists is used and there is a single NOTIFY with all the 336 presentities for the single subscription. 337 o (I08) Total number and bytes of initial 200 OK for NOTIFY messages 338 for all watchers = Number - I04*C06, Bytes - I04*C06*C10. 339 o (I09) Total number and bytes of initial messages per day = Number 340 - numbers in I05+I06+I07+I08, Size -sizes in I05+I06+I07+I08. 342 2.3.3. Steady State Messages 344 Here we describe the calculations for the steady state messages. In 345 steady state we mean the time between the initial subscription and 346 the tear down of the subscription. It contains the notifies due to 347 state change and the subscription refreshes. 349 o (S01) NOTIFY messages due to state change per watched presentity 350 per day (less 2 since the NOTIFY for initial and terminating state 351 is calculated in the initial and terminating calculations) = 352 (C02*C01-2). 353 o (S02) 200 (for NOTIFY due to state change) messages per watched 354 presentity per day (less 2 since the NOTIFY for initial and 355 terminating state is calculated in the initial and terminating 356 calculations) = (C02*C01-2). 357 o (S03) Total number and size of messages due to state change per 358 day = Number - (S01+S02)*C06*C04, Bytes - ((S01*C06*C04*(C09+C11)) 359 + (S02*C06* C04*C10)). 360 o (S04) Number of SUBSCRIBE messages for refreshes per watcher per 361 day = ((C01/C03)-1)*C05. One is subtracted since the termination 362 is calculated separately. for example if there are 8 hours in the 363 day and a refresh should occur every hour, there are 7 refreshes 364 during the day and not 8. 365 o (S05) Number of 200 OK messages for SUBSCRIBE messages for 366 refreshes per watcher per day = ((C01/C03)-1)*C05. 367 o (S06) Number of NOTIFY messages for refreshes per watcher per day 368 = ((C01/C03)-1)*C05. 369 o (S07) Number of 200 OK messages for NOTIFY messages for refreshes 370 per watcher per day = ((C01/C03)-1)*C05. 371 o (S08) Total number and size of messages due to SUBSCRIBE refreshes 372 per day = Number - (S04+S05+S06+S07)*C06, Size - SUBSCIRBE bytes 373 (S04*C06*C07) + OK for SUBSCRIBE bytes (S05*C06*C08) + NOTIFY 374 bytes (S06*C06*(C09+((C04/C05)*C11))) + OK for NOTIFY 375 (S07*C06*C08). The calculation of the size is a bit complicates 376 since it takes into account the case where the optimization of 377 resource lists is used and there is a single NOTIFY with all the 378 presentities for the single subscription. Note that a full state 379 should be given in SUBSCRIBE refreshes in resource lists. See 380 section 4.5 in [10]. The fact that the full state needs to be 381 returned in a NOTIFY response to refresh makes the NOTIFY 382 optimization more efficient in conjunction with the dialog 383 optimization. 384 o (S09) Total number and bytes of steady messages per day = Number - 385 numbers in S03+S08, Bytes - sizes in S03+S08. 387 2.3.4. Termination Messages 389 The following are the calculations for the messages in the 390 termination phase of the of the subscriptions. The calculations 391 contain both number of messages and the number of bytes. 393 o (T01) Number of terminating SUBSCRIBE messages per watcher = C05. 394 o (T02) Number of terminating 200 OK messages for SUBSCRIBE messages 395 per watcher = C05. 396 o (T03) Number of terminating NOTIFY messages per watcher = C05. 397 o (T04) Number of terminating 200 OK messages for NOTIFY messages 398 per watcher = C05. 399 o (T05) Total number and bytes of terminating SUBSCRIBE messages for 400 all watchers = Number - T01*C06, Bytes - T01*C06*C07. 401 o (T06) Total number and bytes of terminating 200 OK for SUBSCRIBE 402 messages for all watchers = Number - T01*C06, Bytes - T01*C06*C08. 403 o (T07) Total number and bytes of terminating NOTIFY messages for 404 all watchers = Number - T01*C06, Bytes - (T03*C06*(C09+C11). It 405 is assumed that there will be a single presence document in the 406 terminating NOTIFY. 407 o (T08) Total number and bytes of terminating 200 OK for NOTIFY 408 messages for all watchers = Number - T04*C06, Bytes - T04*C06*C10. 409 o (T09) Total number and bytes of terminating messages per day = 410 Number - numbers in T05+T06+T07+T08, Size -sizes in T05+T06+T07+ 411 T08. 413 2.3.5. Bottom Line 415 The following are the calculations of the total number of messages 416 and bytes per day and per second that will be sent on the link 417 between the federating domains. 419 o (B01) Total number of message and bytes during the day = Number - 420 numbers in I09+S09+T09, Bytes - sizes in I09+S09+T09. 421 o (B02) Total number of message and bytes per second = Number - 422 number in B01/(C01*3600) Bytes - size in B01/(C01*3600). 424 2.3.6. Rush Hour Calculations 426 The way that the calculations are built it is relatively easy to see 427 the affect of rush hours at the beginning and the end of the day. for 428 the beginning of the day we should look at the numbers of "(I09) 429 Total number and bytes of initial messages per day" and for the end 430 of the day we should look at the number of "(T09) Total number and 431 bytes of terminating messages per day". Taking these numbers with 432 some assumed percentage of the numbers of users that log in at the 433 same hour should give good indication for the rush hour load. 435 2.4. SIMPLE with no optimizations 437 The following table uses some common presence characteristics to 438 demonstrate the effect these factors have on state and message rate 439 within a presence domain using base SIMPLE protocols without any 440 proposed optimizations. In this example, there are two presence 441 domains with total of 40,000 federating users with an average of 4 442 contacts in the peer domain 444 ** Constants 445 (C01) Subscription lifetime (hours)...........................8 446 (C02) Presence state changes / hour...........................3 447 (C03) Subscription refresh interval / hour....................1 448 (C04) Total federated presentities per watcher................4 449 (C05) Number of dialogs to maintain per watcher...............4 450 (C06) Total number of watchers in domains................40,000 451 (C07) SUBSCRIBE message size in bytes.......................450 452 (C08) 200 OK for SUBSCRIBE message size in bytes............370 453 (C09) NOTIFY message size not including presence doc........500 454 (C10) 200 OK for NOTIFY message size in bytes...............370 455 (C11) Size of an average presence document................3,000 457 ** Initial Messages 458 (I01) Initial SUBSCRIBE msgs per watcher......................4 459 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............4 460 (I03) Initial NOTIFY msgs per watcher.........................4 461 (I04) Initial 200 OK msgs (NOTIFY) per watcher................4 462 (I05) Total number & bytes of initial SUBSCRIBE msgs 463 Number of msgs for all watchers...............160,000 464 Bytes for all watchers.....................72,000,000 465 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 466 Number of msgs for all watchers...............160,000 467 Bytes for all watchers.....................59,200,000 468 (I07) Total number & bytes of initial NOTIFY msgs 469 Number of msgs for all watchers...............160,000 470 Bytes for all watchers....................560,000,000 471 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 472 Number of msgs for all watchers...............160,000 473 Bytes for all watchers.....................59,200,000 474 (I09) Total number & bytes of initial messages per day 475 Number of msgs for all watchers...............640,000 476 Bytes for all watchers....................750,400,000 478 ** Steady State Messages 479 (S01) NOTIFY msgs due to state change 480 per watched presentity per day.....................22 481 (S02) 200 (for NOTIFY due to state change) msgs 482 per watched presentity per day.....................22 484 (S03) Total number and size of msgs due to state change per day 485 Number of msgs for all watchers.............7,040,000 486 Bytes for all watchers.................13,622,400,000 487 (S04) Number of SUBSCRIBE msgs for refreshes 488 per watcher per day................................28 489 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 490 per watcher per day................................28 491 (S06) Number of NOTIFY msgs for refreshes 492 per watcher per day................................28 493 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 494 per watcher per day................................28 495 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 496 Number of msgs for all watchers per day.....4,480,000 497 Bytes for all watchers per day..........5,252,800,000 498 (S09) Total number & bytes of steady messages per day 499 Number of msgs for all watchers............11,520,000 500 Bytes for all watchers.................18,875,200,000 502 ** Termination Messages 503 (T01) Terminating SUBSCRIBE msgs per watcher..................4 504 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........4 505 (T03) Terminating NOTIFY msgs per watcher.....................4 506 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............4 507 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 508 Number of msgs for all watchers.............. 160,000 509 Bytes for all watchers.....................72,000,000 510 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 511 Number of msgs for all watchers...............160,000 512 Bytes for all watchers.....................59,200,000 513 (T07) Total number & bytes of terminating NOTIFY msgs 514 Number of msgs for all watchers...............160,000 515 Bytes for all watchers....................560,000,000 516 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 517 Number of msgs for all watchers...............160,000 518 Bytes for all watchers.....................59,200,000 519 (T09) Total number & bytes of terminating messages per day 520 Number of msgs for all watchers...............640,000 521 Bytes for all watchers....................750,400,000 523 ** Bottom Line 524 (B01) Total number of message & bytes during the day 525 Number of msgs.............................12,800,000 526 Bytes..................................20,376,000,000 527 (B02) Total number of message & bytes per second 528 Number of msgs....................................444 529 Bytes.........................................707,500 531 Figure 1: SIMPLE with no optimizations 533 2.5. SIMPLE with dialog optimization 535 The same analysis provided above is repeated here with the assumption 536 that the dialog optimization is applied. Note that while the sign-in 537 (ramp up) and sign-out messages flows are positively affected, the 538 steady state rates are not. 540 ** Constants 541 (C01) Subscription lifetime (hours)...........................8 542 (C02) Presence state changes / hour...........................3 543 (C03) Subscription refresh interval / hour....................1 544 (C04) Total federated presentities per watcher................4 545 (C05) Number of dialogs to maintain per watcher...............1 546 (C06) Total number of watchers in domains................40,000 547 (C07) SUBSCRIBE message size in bytes.......................450 548 (C08) 200 OK for SUBSCRIBE message size in bytes............370 549 (C09) NOTIFY message size not including presence doc........500 550 (C10) 200 OK for NOTIFY message size in bytes...............370 551 (C11) Size of an average presence document................3,000 553 ** Initial Messages 554 (I01) Initial SUBSCRIBE msgs per watcher......................1 555 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1 556 (I03) Initial NOTIFY msgs per watcher.........................1 557 (I04) Initial 200 OK msgs (NOTIFY) per watcher................1 558 (I05) Total number & bytes of initial SUBSCRIBE msgs 559 Number of msgs for all watchers................40,000 560 Bytes for all watchers.....................18,000,000 561 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 562 Number of msgs for all watchers................40,000 563 Bytes for all watchers.....................14,800,000 564 (I07) Total number & bytes of initial NOTIFY msgs 565 Number of msgs for all watchers................40,000 566 Bytes for all watchers....................500,000,000 567 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 568 Number of msgs for all watchers................40,000 569 Bytes for all watchers.....................14,800,000 570 (I09) Total number & bytes of initial messages per day 571 Number of msgs for all watchers...............160,000 572 Bytes for all watchers....................547,600,000 574 ** Steady State Messages 575 (S01) NOTIFY msgs due to state change 576 per watched presentity per day.....................22 577 (S02) 200 (for NOTIFY due to state change) msgs 578 per watched presentity per day.....................22 579 (S03) Total number and size of msgs due to state change per day 580 Number of msgs for all watchers.............7,040,000 581 Bytes for all watchers.................13,622,400,000 582 (S04) Number of SUBSCRIBE msgs for refreshes 583 per watcher per day.................................7 584 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 585 per watcher per day.................................7 586 (S06) Number of NOTIFY msgs for refreshes 587 per watcher per day.................................7 588 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 589 per watcher per day.................................7 590 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 591 Number of msgs for all watchers per day.....1,120,000 592 Bytes for all watchers per day..........3,833,200,000 593 (S09) Total number & bytes of steady messages per day 594 Number of msgs for all watchers.............8,160,000 595 Bytes for all watchers.................17,455,600,000 597 ** Termination Messages 598 (T01) Terminating SUBSCRIBE msgs per watcher..................1 599 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1 600 (T03) Terminating NOTIFY msgs per watcher.....................1 601 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............1 602 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 603 Number of msgs for all watchers................40,000 604 Bytes for all watchers.....................18,000,000 605 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 606 Number of msgs for all watchers................40,000 607 Bytes for all watchers.....................14,800,000 608 (T07) Total number & bytes of terminating NOTIFY msgs 609 Number of msgs for all watchers................40,000 610 Bytes for all watchers....................140,000,000 611 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 612 Number of msgs for all watchers................40,000 613 Bytes for all watchers.....................14,800,000 614 (T09) Total number & bytes of terminating messages per day 615 Number of msgs for all watchers...............160,000 616 Bytes for all watchers....................187,600,000 618 ** Bottom Line 619 (B01) Total number of message & bytes during the day 620 Number of msgs..............................8,480,000 621 Bytes..................................18,190,800,000 622 (B02) Total number of message & bytes per second 623 Number of msgs....................................294 624 Bytes.........................................631,625 626 Figure 2: SIMPLE with Dialog optimizations 628 2.6. SIMPLE with NOTIFY optimization 630 The initial analysis of analysis provided in Figure 1 is repeated 631 here with the assumption that the notify optimization is applied. 632 The optimization saves the need for NOTIFY upon refreshing a 633 SUBSCRIBE if there was no change since the last NOTIFY. It is 634 assumed here that there will be no NOTIFY message for a SUBSCRIBE 635 refreshes. As should be expected this optimization affects the 636 steady state and does not affect the initial and termination 637 messages. 639 ** Constants 640 (C01) Subscription lifetime (hours)...........................8 641 (C02) Presence state changes / hour...........................3 642 (C03) Subscription refresh interval / hour....................1 643 (C04) Total federated presentities per watcher................4 644 (C05) Number of dialogs to maintain per watcher...............4 645 (C06) Total number of watchers in domains................40,000 646 (C07) SUBSCRIBE message size in bytes.......................450 647 (C08) 200 OK for SUBSCRIBE message size in bytes............370 648 (C09) NOTIFY message size not including presence doc........500 649 (C10) 200 OK for NOTIFY message size in bytes...............370 650 (C11) Size of an average presence document................3,000 652 ** Initial Messages 653 (I01) Initial SUBSCRIBE msgs per watcher......................4 654 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............4 655 (I03) Initial NOTIFY msgs per watcher.........................4 656 (I04) Initial 200 OK msgs (NOTIFY) per watcher................4 657 (I05) Total number & bytes of initial SUBSCRIBE msgs 658 Number of msgs for all watchers...............160,000 659 Bytes for all watchers.....................72,000,000 660 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 661 Number of msgs for all watchers...............160,000 662 Bytes for all watchers.....................59,200,000 663 (I07) Total number & bytes of initial NOTIFY msgs 664 Number of msgs for all watchers...............160,000 665 Bytes for all watchers....................560,000,000 666 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 667 Number of msgs for all watchers...............160,000 668 Bytes for all watchers.....................59,200,000 669 (I09) Total number & bytes of initial messages per day 670 Number of msgs for all watchers...............640,000 671 Bytes for all watchers....................750,400,000 673 ** Steady State Messages 674 (S01) NOTIFY msgs due to state change 675 per watched presentity per day.....................22 677 (S02) 200 (for NOTIFY due to state change) msgs 678 per watched presentity per day.....................22 679 (S03) Total number and size of msgs due to state change per day 680 Number of msgs for all watchers.............7,040,000 681 Bytes for all watchers.................13,622,400,000 682 (S04) Number of SUBSCRIBE msgs for refreshes 683 per watcher per day................................28 684 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 685 per watcher per day................................28 686 (S06) Number of NOTIFY msgs for refreshes 687 per watcher per day.................................0 688 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 689 per watcher per day.................................0 690 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 691 Number of msgs for all watchers per day.....2,240,000 692 Bytes for all watchers per day............918,400,000 693 (S09) Total number & bytes of steady messages per day 694 Number of msgs for all watchers.............9,280,000 695 Bytes for all watchers.................14,540,800,000 697 ** Termination Messages 698 (T01) Terminating SUBSCRIBE msgs per watcher..................4 699 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........4 700 (T03) Terminating NOTIFY msgs per watcher.....................4 701 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............4 702 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 703 Number of msgs for all watchers.............. 160,000 704 Bytes for all watchers.....................72,000,000 705 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 706 Number of msgs for all watchers...............160,000 707 Bytes for all watchers.....................59,200,000 708 (T07) Total number & bytes of terminating NOTIFY msgs 709 Number of msgs for all watchers...............160,000 710 Bytes for all watchers....................560,000,000 711 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 712 Number of msgs for all watchers...............160,000 713 Bytes for all watchers.....................59,200,000 714 (T09) Total number & bytes of terminating messages per day 715 Number of msgs for all watchers...............640,000 716 Bytes for all watchers....................750,400,000 718 ** Bottom Line 719 (B01) Total number of message & bytes during the day 720 Number of msgs.............................10,560,000 721 Bytes..................................16,041,600,000 722 (B02) Total number of message & bytes per second 723 Number of msgs....................................367 724 Bytes.........................................557,000 725 Figure 3: SIMPLE with NOTIFY optimizations 727 2.7. SIMPLE with Dialog & NOTIFY optimizations 729 Here both optimizations are combined. In all the other use cases we 730 will show only the analysis with no optimizations and with both 731 optimizations combined. 733 ** Constants 734 (C01) Subscription lifetime (hours)...........................8 735 (C02) Presence state changes / hour...........................3 736 (C03) Subscription refresh interval / hour....................1 737 (C04) Total federated presentities per watcher................4 738 (C05) Number of dialogs to maintain per watcher...............1 739 (C06) Total number of watchers in domains................40,000 740 (C07) SUBSCRIBE message size in bytes.......................450 741 (C08) 200 OK for SUBSCRIBE message size in bytes............370 742 (C09) NOTIFY message size not including presence doc........500 743 (C10) 200 OK for NOTIFY message size in bytes...............370 744 (C11) Size of an average presence document................3,000 746 ** Initial Messages 747 (I01) Initial SUBSCRIBE msgs per watcher......................1 748 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1 749 (I03) Initial NOTIFY msgs per watcher.........................1 750 (I04) Initial 200 OK msgs (NOTIFY) per watcher................1 751 (I05) Total number & bytes of initial SUBSCRIBE msgs 752 Number of msgs for all watchers................40,000 753 Bytes for all watchers.....................18,000,000 754 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 755 Number of msgs for all watchers................40,000 756 Bytes for all watchers.....................14,800,000 757 (I07) Total number & bytes of initial NOTIFY msgs 758 Number of msgs for all watchers................40,000 759 Bytes for all watchers....................500,000,000 760 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 761 Number of msgs for all watchers................40,000 762 Bytes for all watchers.....................14,800,000 763 (I09) Total number & bytes of initial messages per day 764 Number of msgs for all watchers...............160,000 765 Bytes for all watchers....................547,600,000 767 ** Steady State Messages 768 (S01) NOTIFY msgs due to state change 769 per watched presentity per day.....................22 770 (S02) 200 (for NOTIFY due to state change) msgs 771 per watched presentity per day.....................22 772 (S03) Total number and size of msgs due to state change per day 773 Number of msgs for all watchers.............7,040,000 774 Bytes for all watchers.................13,622,400,000 775 (S04) Number of SUBSCRIBE msgs for refreshes 776 per watcher per day.................................7 777 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 778 per watcher per day.................................7 779 (S06) Number of NOTIFY msgs for refreshes 780 per watcher per day.................................0 781 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 782 per watcher per day.................................0 783 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 784 Number of msgs for all watchers per day.......560,000 785 Bytes for all watchers per day............229,600,000 786 (S09) Total number & bytes of steady messages per day 787 Number of msgs for all watchers.............7,600,000 788 Bytes for all watchers.................13,852,000,000 790 ** Termination Messages 791 (T01) Terminating SUBSCRIBE msgs per watcher..................1 792 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1 793 (T03) Terminating NOTIFY msgs per watcher.....................1 794 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............1 795 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 796 Number of msgs for all watchers................40,000 797 Bytes for all watchers.....................18,000,000 798 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 799 Number of msgs for all watchers................40,000 800 Bytes for all watchers.....................14,800,000 801 (T07) Total number & bytes of terminating NOTIFY msgs 802 Number of msgs for all watchers................40,000 803 Bytes for all watchers....................140,000,000 804 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 805 Number of msgs for all watchers................40,000 806 Bytes for all watchers.....................14,800,000 807 (T09) Total number & bytes of terminating messages per day 808 Number of msgs for all watchers...............160,000 809 Bytes for all watchers....................187,600,000 811 ** Bottom Line 812 (B01) Total number of message & bytes during the day 813 Number of msgs..............................7,920,000 814 Bytes..................................14,587,200,000 815 (B02) Total number of message & bytes per second 816 Number of msgs....................................275 817 Bytes.........................................506,500 819 Figure 4: SIMPLE with Dialog & NOTIFY optimizations 821 2.8. Presence Federations 823 While these scalability issues exist in any large deployment, certain 824 characteristics make the deployment conducive to the existing 825 resource- list optimizations, and others have characteristics that 826 cannot be exploited with the existing SIMPLE model. Following is a 827 list of federation relationships that have varying usage 828 characteristics. For each, a message rate and bandwidth table is 829 provided reflecting typical changes message rates. Those 830 characteristics can alter the overall effectiveness of existing 831 optimizations. 833 2.8.1. Widely distributed inter-domain presence 835 In some environments presence federation may be very common, perhaps 836 even more common than intra-domain presence. An example of this type 837 of environment is a small ISV or public server. Users in that small 838 ISV are not likely to subscribe to the presence of other users in the 839 their server since they do not necessarily have any relationship with 840 each other aside from receiving service from the same provider. They 841 are much more likely to be subscribed to the presence of users in one 842 of the federated domains (whether in consumer domains, academic, 843 other ISVs, etc). Common characteristics of this deployment are: 845 o Federated subscriptions are the majority of subscription traffic 846 o Individual users are likely to subscribe to multiple users in any 847 one domain 848 o The intersection of users in the deployment watching the same 849 presentities is quite small (i.e., probability that watchers in 850 the domain subscribe to the same presentity is low) 852 To account for the extraordinarily high percentage of federation 853 traffic, the number of federated presentities is increased to 20. 854 The number of watchers in the domain could also be adjusted to 855 account for an expected larger community of users being peered with, 856 it is omitted here for simplification 858 The first table below provides the calculations without optimizations 859 the second table provides the calculations with optimization. Note 860 that the number of messages per second decreases by a quarter with 861 the optimizations but it is still quite big. It is interesting to 862 see that the bandwidth is almost the quarter of the bandwidth when 863 optimizations are applied. 865 ** Constants 866 (C01) Subscription lifetime (hours)...........................8 867 (C02) Presence state changes / hour...........................3 868 (C03) Subscription refresh interval / hour....................1 869 (C04) Total federated presentities per watcher...............20 870 (C05) Number of dialogs to maintain per watcher..............20 871 (C06) Total number of watchers in domains................40,000 872 (C07) SUBSCRIBE message size in bytes.......................450 873 (C08) 200 OK for SUBSCRIBE message size in bytes............370 874 (C09) NOTIFY message size not including presence doc........500 875 (C10) 200 OK for NOTIFY message size in bytes...............370 876 (C11) Size of an average presence document................3,000 878 ** Initial Messages 879 (I01) Initial SUBSCRIBE msgs per watcher.....................20 880 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher............20 881 (I03) Initial NOTIFY msgs per watcher........................20 882 (I04) Initial 200 OK msgs (NOTIFY) per watcher...............20 883 (I05) Total number & bytes of initial SUBSCRIBE msgs 884 Number of msgs for all watchers...............800,000 885 Bytes for all watchers....................360,000,000 886 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 887 Number of msgs for all watchers...............800,000 888 Bytes for all watchers....................296,000,000 889 (I07) Total number & bytes of initial NOTIFY msgs 890 Number of msgs for all watchers...............800,000 891 Bytes for all watchers..................2,800,000,000 892 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 893 Number of msgs for all watchers...............800,000 894 Bytes for all watchers....................296,000,000 895 (I09) Total number & bytes of initial messages per day 896 Number of msgs for all watchers.............3,200,000 897 Bytes for all watchers..................3,752,000,000 899 ** Steady State Messages 900 (S01) NOTIFY msgs due to state change 901 per watched presentity per day.....................22 902 (S02) 200 (for NOTIFY due to state change) msgs 903 per watched presentity per day.....................22 904 (S03) Total number and size of msgs due to state change per day 905 Number of msgs for all watchers............35,200,000 906 Bytes for all watchers.................68,112,000,000 907 (S04) Number of SUBSCRIBE msgs for refreshes 908 per watcher per day...............................140 909 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 910 per watcher per day...............................140 911 (S06) Number of NOTIFY msgs for refreshes 912 per watcher per day...............................140 913 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 914 per watcher per day...............................140 915 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 916 Number of msgs for all watchers per day....22,400,000 917 Bytes for all watchers per day.........26,264,000,000 918 (S09) Total number & bytes of steady messages per day 919 Number of msgs for all watchers............57,600,000 920 Bytes for all watchers.................94,376,000,000 922 ** Termination Messages 923 (T01) Terminating SUBSCRIBE msgs per watcher.................20 924 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........20 925 (T03) Terminating NOTIFY msgs per watcher....................20 926 (T04) Terminating 200 OK msgs (NOTIFY) per watcher...........20 927 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 928 Number of msgs for all watchers...............800,000 929 Bytes for all watchers....................360,000,000 930 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 931 Number of msgs for all watchers...............800,000 932 Bytes for all watchers....................296,000,000 933 (T07) Total number & bytes of terminating NOTIFY msgs 934 Number of msgs for all watchers...............800,000 935 Bytes for all watchers..................2,800,000,000 936 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 937 Number of msgs for all watchers...............800,000 938 Bytes for all watchers....................296,000,000 939 (T09) Total number & bytes of terminating messages per day 940 Number of msgs for all watchers.............3,200,000 941 Bytes for all watchers..................3,752,000,000 943 ** Bottom Line 944 (B01) Total number of message & bytes during the day 945 Number of msgs.............................65,000,000 946 Bytes.................................101,880,000,000 947 (B02) Total number of message & bytes per second 948 Number of msgs..................................2,222 949 Bytes.......................................3,537,500 951 Figure 5: Widely distributed inter-domain with no optimizations 953 ** Constants 954 (C01) Subscription lifetime (hours)...........................8 955 (C02) Presence state changes / hour...........................3 956 (C03) Subscription refresh interval / hour....................1 957 (C04) Total federated presentities per watcher...............20 958 (C05) Number of dialogs to maintain per watcher...............1 959 (C06) Total number of watchers in domains................40,000 960 (C07) SUBSCRIBE message size in bytes.......................450 961 (C08) 200 OK for SUBSCRIBE message size in bytes............370 962 (C09) NOTIFY message size not including presence doc........500 963 (C10) 200 OK for NOTIFY message size in bytes...............370 964 (C11) Size of an average presence document................3,000 966 ** Initial Messages 967 (I01) Initial SUBSCRIBE msgs per watcher......................1 968 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1 969 (I03) Initial NOTIFY msgs per watcher.........................1 970 (I04) Initial 200 OK msgs (NOTIFY) per watcher................1 971 (I05) Total number & bytes of initial SUBSCRIBE msgs 972 Number of msgs for all watchers................40,000 973 Bytes for all watchers.....................18,000,000 974 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 975 Number of msgs for all watchers................40,000 976 Bytes for all watchers.....................14,800,000 977 (I07) Total number & bytes of initial NOTIFY msgs 978 Number of msgs for all watchers................40,000 979 Bytes for all watchers..................2,420,000,000 980 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 981 Number of msgs for all watchers................40,000 982 Bytes for all watchers.....................14,800,000 983 (I09) Total number & bytes of initial messages per day 984 Number of msgs for all watchers...............160,000 985 Bytes for all watchers..................2,467,600,000 987 ** Steady State Messages 988 (S01) NOTIFY msgs due to state change 989 per watched presentity per day.....................22 990 (S02) 200 (for NOTIFY due to state change) msgs 991 per watched presentity per day.....................22 992 (S03) Total number and size of msgs due to state change per day 993 Number of msgs for all watchers............35,200,000 994 Bytes for all watchers.................68,112,000,000 995 (S04) Number of SUBSCRIBE msgs for refreshes 996 per watcher per day.................................7 997 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 998 per watcher per day.................................7 999 (S06) Number of NOTIFY msgs for refreshes 1000 per watcher per day.................................0 1001 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1002 per watcher per day.................................0 1003 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1004 Number of msgs for all watchers per day.......560,000 1005 Bytes for all watchers per day............229,600,000 1006 (S09) Total number & bytes of steady messages per day 1007 Number of msgs for all watchers............35,760,000 1008 Bytes for all watchers.................68,341,600,000 1010 ** Termination Messages 1011 (T01) Terminating SUBSCRIBE msgs per watcher..................1 1012 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1 1013 (T03) Terminating NOTIFY msgs per watcher.....................1 1014 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............1 1015 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1016 Number of msgs for all watchers................40,000 1017 Bytes for all watchers.....................18,000,000 1018 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1019 Number of msgs for all watchers................40,000 1020 Bytes for all watchers.....................14,800,000 1021 (T07) Total number & bytes of terminating NOTIFY msgs 1022 Number of msgs for all watchers................40,000 1023 Bytes for all watchers....................140,000,000 1024 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 1025 Number of msgs for all watchers................40,000 1026 Bytes for all watchers.....................14,800,000 1027 (T09) Total number & bytes of terminating messages per day 1028 Number of msgs for all watchers...............160,000 1029 Bytes for all watchers....................187,600,000 1031 ** Bottom Line 1032 (B01) Total number of message & bytes during the day 1033 Number of msgs.............................36,080,000 1034 Bytes..................................70,996,800,000 1035 (B02) Total number of message & bytes per second 1036 Number of msgs..................................1,253 1037 Bytes.......................................2,465,167 1039 Figure 6: Widely distributed inter-domain with optimizations 1041 2.8.2. Associated inter-domain presence 1043 In this type of environment, the domain is a collection of associated 1044 users such as an enterprise. Here, federation is once again very 1045 common. However, there is also a strong association between some 1046 users in the deployment. These associations make it somewhat more 1047 likely that users in that domain will be watchers of the same 1048 presentity. This can occur because of business relationships (e.g. 1049 two co-workers on a project federating with a partner company). 1051 Common characteristics of this deployment are: 1053 o Federated subscriptions are large minority or small majority of 1054 subscription traffic 1055 o Individual users are likely to subscribe to multiple users in any 1056 one domain, especially their own 1057 o The intersection of users in the deployment watching the same 1058 presentities increases 1060 This federation type has traffic rates similar to the previous 1061 examples but with different levels of association of the users. 1063 2.8.3. Very large network peering 1065 In this environment, two or more very large networks create a peering 1066 relationship allowing their users to subscribe to presence in the 1067 other domains. Where as the number of users in other deployment 1068 types ranges from hundreds to several hundred thousand, these large 1069 networks host up to hundreds of millions of users. Examples of these 1070 networks are large wireless carriers and consumer IM networks. 1072 Common characteristics of this deployment are: 1074 o As users become accustomed to network boundaries disappearing, 1075 federated subscriptions become as common as subscriptions within 1076 the same domain 1077 o Individual users are highly likely to want to see presence of 1078 multiple presentities in the peer network 1079 o The intersection of users in the deployment watching the same 1080 presentities is very high (i.e., two or more users in network A 1081 are extremely likely to be watching a same user in network B) 1082 o Status changes increase greatly due to typical observed consumer 1083 behavior 1085 The first table below provides the calculations without optimizations 1086 the second table provides the calculations with optimizations. Even 1087 though the optimizations help a lot (almost cut the number of 1088 messages by half), the numbers are still very high. Note also that 1089 the bandwidth required is very high (almost 1GB per second). 1091 ** Constants 1092 (C01) Subscription lifetime (hours)...........................8 1093 (C02) Presence state changes / hour...........................6 1094 (C03) Subscription refresh interval / hour....................1 1095 (C04) Total federated presentities per watcher...............10 1096 (C05) Number of dialogs to maintain per watcher..............10 1097 (C06) Total number of watchers in domains............20,000,000 1098 (C07) SUBSCRIBE message size in bytes.......................450 1099 (C08) 200 OK for SUBSCRIBE message size in bytes............370 1100 (C09) NOTIFY message size not including presence doc........500 1101 (C10) 200 OK for NOTIFY message size in bytes...............370 1102 (C11) Size of an average presence document................3,000 1104 ** Initial Messages 1105 (I01) Initial SUBSCRIBE msgs per watcher.....................10 1106 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher............10 1107 (I03) Initial NOTIFY msgs per watcher........................10 1108 (I04) Initial 200 OK msgs (NOTIFY) per watcher...............10 1109 (I05) Total number & bytes of initial SUBSCRIBE msgs 1110 Number of msgs for all watchers...........200,000,000 1111 Bytes for all watchers.................90,000,000,000 1112 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 1113 Number of msgs for all watchers...........200,000,000 1114 Bytes for all watchers.................74,000,000,000 1115 (I07) Total number & bytes of initial NOTIFY msgs 1116 Number of msgs for all watchers...........200,000,000 1117 Bytes for all watchers................700,000,000,000 1118 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 1119 Number of msgs for all watchers...........200,000,000 1120 Bytes for all watchers.................74,000,000,000 1121 (I09) Total number & bytes of initial messages per day 1122 Number of msgs for all watchers...........800,000,000 1123 Bytes for all watchers................938,000,000,000 1125 ** Steady State Messages 1126 (S01) NOTIFY msgs due to state change 1127 per watched presentity per day.....................46 1128 (S02) 200 (for NOTIFY due to state change) msgs 1129 per watched presentity per day.....................46 1130 (S03) Total number and size of msgs due to state change per day 1131 Number of msgs for all watchers........18,400,000,000 1132 Bytes for all watchers.............35,604,000,000,000 1133 (S04) Number of SUBSCRIBE msgs for refreshes 1134 per watcher per day................................70 1135 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 1136 per watcher per day................................70 1137 (S06) Number of NOTIFY msgs for refreshes 1138 per watcher per day................................70 1139 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1140 per watcher per day................................70 1141 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1142 Number of msgs for all watchers per day.5,600,000,000 1143 Bytes for all watchers per day......6,566,000,000,000 1144 (S09) Total number & bytes of steady messages per day 1145 Number of msgs for all watchers........24,000,000,000 1146 Bytes for all watchers.............42,170,000,000,000 1148 ** Termination Messages 1149 (T01) Terminating SUBSCRIBE msgs per watcher.................10 1150 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........10 1151 (T03) Terminating NOTIFY msgs per watcher....................10 1152 (T04) Terminating 200 OK msgs (NOTIFY) per watcher...........10 1153 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1154 Number of msgs for all watchers...........200,000,000 1155 Bytes for all watchers.................90,000,000,000 1157 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1158 Number of msgs for all watchers...........200,000,000 1159 Bytes for all watchers.................74,000,000,000 1160 (T07) Total number & bytes of terminating NOTIFY msgs 1161 Number of msgs for all watchers...........200,000,000 1162 Bytes for all watchers................700,000,000,000 1163 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 1164 Number of msgs for all watchers...........200,000,000 1165 Bytes for all watchers.................74,000,000,000 1166 (T09) Total number & bytes of terminating messages per day 1167 Number of msgs for all watchers...........800,000,000 1168 Bytes for all watchers................938,002,000,000 1170 ** Bottom Line 1171 (B01) Total number of message & bytes during the day 1172 Number of msgs.........................25,600,000,000 1173 Bytes..............................44,046,000,000,000 1174 (B02) Total number of message & bytes per second 1175 Number of msgs................................888,889 1176 Bytes...................................1,529,375,333 1178 Figure 7: Very large network peering with no optimizations 1180 ** Constants 1181 (C01) Subscription lifetime (hours)...........................8 1182 (C02) Presence state changes / hour...........................6 1183 (C03) Subscription refresh interval / hour....................1 1184 (C04) Total federated presentities per watcher...............10 1185 (C05) Number of dialogs to maintain per watcher...............1 1186 (C06) Total number of watchers in domains............20,000,000 1187 (C07) SUBSCRIBE message size in bytes.......................450 1188 (C08) 200 OK for SUBSCRIBE message size in bytes............370 1189 (C09) NOTIFY message size not including presence doc........500 1190 (C10) 200 OK for NOTIFY message size in bytes...............370 1191 (C11) Size of an average presence document................3,000 1193 ** Initial Messages 1194 (I01) Initial SUBSCRIBE msgs per watcher......................1 1195 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1 1196 (I03) Initial NOTIFY msgs per watcher.........................1 1197 (I04) Initial 200 OK msgs (NOTIFY) per watcher................1 1198 (I05) Total number & bytes of initial SUBSCRIBE msgs 1199 Number of msgs for all watchers............20,000,000 1200 Bytes for all watchers..................9,000,000,000 1201 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 1202 Number of msgs for all watchers............20,000,000 1203 Bytes for all watchers..................7,400,000,000 1205 (I07) Total number & bytes of initial NOTIFY msgs 1206 Number of msgs for all watchers............20,000,000 1207 Bytes for all watchers................610,000,000,000 1208 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 1209 Number of msgs for all watchers............20,000,000 1210 Bytes for all watchers..................7,400,000,000 1211 (I09) Total number & bytes of initial messages per day 1212 Number of msgs for all watchers............80,000,000 1213 Bytes for all watchers................663,800,000,000 1215 ** Steady State Messages 1216 (S01) NOTIFY msgs due to state change 1217 per watched presentity per day.....................46 1218 (S02) 200 (for NOTIFY due to state change) msgs 1219 per watched presentity per day.....................46 1220 (S03) Total number and size of msgs due to state change per day 1221 Number of msgs for all watchers........18,400,000,000 1222 Bytes for all watchers.............35,604,000,000,000 1223 (S04) Number of SUBSCRIBE msgs for refreshes 1224 per watcher per day.................................7 1225 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 1226 per watcher per day.................................7 1227 (S06) Number of NOTIFY msgs for refreshes 1228 per watcher per day.................................0 1229 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1230 per watcher per day.................................0 1231 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1232 Number of msgs for all watchers per day...280,000,000 1233 Bytes for all watchers per day........114,800,000,000 1234 (S09) Total number & bytes of steady messages per day 1235 Number of msgs for all watchers........18,680,000,000 1236 Bytes for all watchers.............35,718,800,000,000 1238 ** Termination Messages 1239 (T01) Terminating SUBSCRIBE msgs per watcher..................1 1240 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1 1241 (T03) Terminating NOTIFY msgs per watcher.....................1 1242 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............1 1243 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1244 Number of msgs for all watchers............20,000,000 1245 Bytes for all watchers..................9,000,000,000 1246 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1247 Number of msgs for all watchers............20,000,000 1248 Bytes for all watchers..................7,400,000,000 1249 (T07) Total number & bytes of terminating NOTIFY msgs 1250 Number of msgs for all watchers............20,000,000 1251 Bytes for all watchers.................70,000,000,000 1252 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 1253 Number of msgs for all watchers............20,000,000 1254 Bytes for all watchers..................7,400,000,000 1255 (T09) Total number & bytes of terminating messages per day 1256 Number of msgs for all watchers............80,000,000 1257 Bytes for all watchers.................93,800,000,000 1259 ** Bottom Line 1260 (B01) Total number of message & bytes during the day 1261 Number of msgs.........................18,840,000,000 1262 Bytes..............................36,446,400,000,000 1263 (B02) Total number of message & bytes per second 1264 Number of msgs................................654,167 1265 Bytes...................................1,265,500,000 1267 Figure 8: Very large network peering with optimizations 1269 2.8.4. Intra-domain peering 1271 Within a particular domain, multiple presence infrastructures are 1272 deployed with users split between the two. This scenario is unique 1273 in that federated messages do not pass outside the administrative 1274 domain's network. The two infrastructures peer directly inside the 1275 domain. A common example of this is an enterprise IT system with 1276 multiple independent vendor presence solutions deployed(e.g., a 1277 presence solution for desktop messaging deployed alongside a presence 1278 solution for IP telephony). 1280 Common characteristics of this deployment are 1282 o The difference between subscriptions to presentities in one system 1283 vs. the other are completely arbitrary. Any one presentity is as 1284 likely to be homed on one infrastructure as the other 1285 o Active users are almost guaranteed of subscribing to many users in 1286 the peer infrastructure 1287 o The level of intersection of presentities is extremely high 1289 The first table below provides the calculations without optimizations 1290 the second table provides the calculations with optimization. Even 1291 though the relatively conservative numbers are used, the amount of 1292 messages is still very high even though optimization may cut the 1293 traffic by more then half 1295 ** Constants 1296 (C01) Subscription lifetime (hours)...........................8 1297 (C02) Presence state changes / hour...........................3 1298 (C03) Subscription refresh interval / hour....................1 1299 (C04) Total federated presentities per watcher...............10 1300 (C05) Number of dialogs to maintain per watcher..............10 1301 (C06) Total number of watchers in domains...............120,000 1302 (C07) SUBSCRIBE message size in bytes.......................450 1303 (C08) 200 OK for SUBSCRIBE message size in bytes............370 1304 (C09) NOTIFY message size not including presence doc........500 1305 (C10) 200 OK for NOTIFY message size in bytes...............370 1306 (C11) Size of an average presence document................3,000 1308 ** Initial Messages 1309 (I01) Initial SUBSCRIBE msgs per watcher.....................10 1310 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher............10 1311 (I03) Initial NOTIFY msgs per watcher........................10 1312 (I04) Initial 200 OK msgs (NOTIFY) per watcher...............10 1313 (I05) Total number & bytes of initial SUBSCRIBE msgs 1314 Number of msgs for all watchers.............1,200,000 1315 Bytes for all watchers....................540,000,000 1316 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 1317 Number of msgs for all watchers.............1,200,000 1318 Bytes for all watchers....................444,000,000 1319 (I07) Total number & bytes of initial NOTIFY msgs 1320 Number of msgs for all watchers.............1,200,000 1321 Bytes for all watchers..................4,200,000,000 1322 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 1323 Number of msgs for all watchers.............1,200,000 1324 Bytes for all watchers....................444,000,000 1325 (I09) Total number & bytes of initial messages per day 1326 Number of msgs for all watchers.............4,800,000 1327 Bytes for all watchers..................5,628,000,000 1329 ** Steady State Messages 1330 (S01) NOTIFY msgs due to state change 1331 per watched presentity per day.....................22 1332 (S02) 200 (for NOTIFY due to state change) msgs 1333 per watched presentity per day.....................22 1334 (S03) Total number and size of msgs due to state change per day 1335 Number of msgs for all watchers............52,800,000 1336 Bytes for all watchers................102,168,000,000 1337 (S04) Number of SUBSCRIBE msgs for refreshes 1338 per watcher per day................................70 1339 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 1340 per watcher per day................................70 1341 (S06) Number of NOTIFY msgs for refreshes 1342 per watcher per day................................70 1343 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1344 per watcher per day................................70 1345 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1346 Number of msgs for all watchers per day....33,600,000 1347 Bytes for all watchers per day.........39,396,000,000 1348 (S09) Total number & bytes of steady messages per day 1349 Number of msgs for all watchers............86,400,000 1350 Bytes for all watchers................141,564,000,000 1352 ** Termination Messages 1353 (T01) Terminating SUBSCRIBE msgs per watcher.................10 1354 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........10 1355 (T03) Terminating NOTIFY msgs per watcher....................10 1356 (T04) Terminating 200 OK msgs (NOTIFY) per watcher...........10 1357 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1358 Number of msgs for all watchers.............1,200,000 1359 Bytes for all watchers....................540,000,000 1360 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1361 Number of msgs for all watchers.............1,200,000 1362 Bytes for all watchers....................444,000,000 1363 (T07) Total number & bytes of terminating NOTIFY msgs 1364 Number of msgs for all watchers.............1,200,000 1365 Bytes for all watchers..................4,200,000,000 1366 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 1367 Number of msgs for all watchers.............1,200,000 1368 Bytes for all watchers....................444,000,000 1369 (T09) Total number & bytes of terminating messages per day 1370 Number of msgs for all watchers.............4,800,000 1371 Bytes for all watchers..................5,628,000,000 1373 ** Bottom Line 1374 (B01) Total number of message & bytes during the day 1375 Number of msgs.............................96,000,000 1376 Bytes.................................152,820,000,000 1377 (B02) Total number of message & bytes per second 1378 Number of msgs..................................3,333 1379 Bytes.......................................5,306,250 1381 Figure 9: Inter-domain peering with no optimizations 1383 ** Constants 1384 (C01) Subscription lifetime (hours)...........................8 1385 (C02) Presence state changes / hour...........................3 1386 (C03) Subscription refresh interval / hour....................1 1387 (C04) Total federated presentities per watcher...............10 1388 (C05) Number of dialogs to maintain per watcher...............1 1389 (C06) Total number of watchers in domains...............120,000 1390 (C07) SUBSCRIBE message size in bytes.......................450 1391 (C08) 200 OK for SUBSCRIBE message size in bytes............370 1392 (C09) NOTIFY message size not including presence doc........500 1393 (C10) 200 OK for NOTIFY message size in bytes...............370 1394 (C11) Size of an average presence document................3,000 1395 ** Initial Messages 1396 (I01) Initial SUBSCRIBE msgs per watcher......................1 1397 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1 1398 (I03) Initial NOTIFY msgs per watcher.........................1 1399 (I04) Initial 200 OK msgs (NOTIFY) per watcher................1 1400 (I05) Total number & bytes of initial SUBSCRIBE msgs 1401 Number of msgs for all watchers...............120,000 1402 Bytes for all watchers.....................54,000,000 1403 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 1404 Number of msgs for all watchers...............120,000 1405 Bytes for all watchers.....................44,400,000 1406 (I07) Total number & bytes of initial NOTIFY msgs 1407 Number of msgs for all watchers...............120,000 1408 Bytes for all watchers..................3,660,000,000 1409 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 1410 Number of msgs for all watchers...............120,000 1411 Bytes for all watchers.....................44,400,000 1412 (I09) Total number & bytes of initial messages per day 1413 Number of msgs for all watchers...............480,000 1414 Bytes for all watchers..................3,802,800,000 1416 ** Steady State Messages 1417 (S01) NOTIFY msgs due to state change 1418 per watched presentity per day.....................22 1419 (S02) 200 (for NOTIFY due to state change) msgs 1420 per watched presentity per day.....................22 1421 (S03) Total number and size of msgs due to state change per day 1422 Number of msgs for all watchers............52,800,000 1423 Bytes for all watchers................102,168,000,000 1424 (S04) Number of SUBSCRIBE msgs for refreshes 1425 per watcher per day.................................7 1426 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 1427 per watcher per day.................................7 1428 (S06) Number of NOTIFY msgs for refreshes 1429 per watcher per day.................................0 1430 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1431 per watcher per day.................................0 1432 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1433 Number of msgs for all watchers per day.....1,680,000 1434 Bytes for all watchers per day............668,800,000 1435 (S09) Total number & bytes of steady messages per day 1436 Number of msgs for all watchers............54,480,000 1437 Bytes for all watchers................102,856,800,000 1439 ** Termination Messages 1440 (T01) Terminating SUBSCRIBE msgs per watcher..................1 1441 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1 1442 (T03) Terminating NOTIFY msgs per watcher.....................1 1443 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............1 1444 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1445 Number of msgs for all watchers...............120,000 1446 Bytes for all watchers.....................54,000,000 1447 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1448 Number of msgs for all watchers...............120,000 1449 Bytes for all watchers.....................44,400,000 1450 (T07) Total number & bytes of terminating NOTIFY msgs 1451 Number of msgs for all watchers...............120,000 1452 Bytes for all watchers....................420,000,000 1453 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 1454 Number of msgs for all watchers...............120,000 1455 Bytes for all watchers.....................44,400,000 1456 (T09) Total number & bytes of terminating messages per day 1457 Number of msgs for all watchers...............480,000 1458 Bytes for all watchers....................562.800,000 1460 ** Bottom Line 1461 (B01) Total number of message & bytes during the day 1462 Number of msgs.............................55,440,000 1463 Bytes.................................107,222,400,000 1464 (B02) Total number of message & bytes per second 1465 Number of msgs..................................1,925 1466 Bytes.......................................3,723,417 1468 Figure 10: Inter-domain peering with optimizations 1470 2.9. Partial Notifications Optimization 1472 Draft [11] define a way for the watcher to request getting only what 1473 was changed in the presence document. The following is a calculation 1474 of the bandwidth that is saved in the very large peering network 1475 case, when we add the partial notification optimization to the dialog 1476 and NOTIFY optimization. It is assumed that except for the initial 1477 NOTIFY all the other NOTIFY messages will be partial and the size of 1478 the partial presence document is 200 bytes 1480 ** Constants 1481 (C01) Subscription lifetime (hours)...........................8 1482 (C02) Presence state changes / hour...........................6 1483 (C03) Subscription refresh interval / hour....................1 1484 (C04) Total federated presentities per watcher...............10 1485 (C05) Number of dialogs to maintain per watcher...............1 1486 (C06) Total number of watchers in domains............20,000,000 1487 (C07) SUBSCRIBE message size in bytes.......................450 1488 (C08) 200 OK for SUBSCRIBE message size in bytes............370 1489 (C09) NOTIFY message size not including presence doc........500 1490 (C10) 200 OK for NOTIFY message size in bytes...............370 1491 (C11) Size of an average presence document................3,000 1492 (C12) Size of an average partial presence document..........200 1494 ** Initial Messages 1495 (I01) Initial SUBSCRIBE msgs per watcher......................1 1496 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1 1497 (I03) Initial NOTIFY msgs per watcher.........................1 1498 (I04) Initial 200 OK msgs (NOTIFY) per watcher................1 1499 (I05) Total number & bytes of initial SUBSCRIBE msgs 1500 Number of msgs for all watchers............20,000,000 1501 Bytes for all watchers..................9,000,000,000 1502 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 1503 Number of msgs for all watchers............20,000,000 1504 Bytes for all watchers..................7,400,000,000 1505 (I07) Total number & bytes of initial NOTIFY msgs 1506 Number of msgs for all watchers............20,000,000 1507 Bytes for all watchers................610,000,000,000 1508 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 1509 Number of msgs for all watchers............20,000,000 1510 Bytes for all watchers..................7,400,000,000 1511 (I09) Total number & bytes of initial messages per day 1512 Number of msgs for all watchers............80,000,000 1513 Bytes for all watchers................663,800,000,000 1515 ** Steady State Messages 1516 (S01) NOTIFY msgs due to state change 1517 per watched presentity per day.....................46 1518 (S02) 200 (for NOTIFY due to state change) msgs 1519 per watched presentity per day.....................46 1520 (S03) Total number and size of msgs due to state change per day 1521 Number of msgs for all watchers........18,400,000,000 1522 Bytes for all watchers..............9,844,000,000,000 1523 (S04) Number of SUBSCRIBE msgs for refreshes 1524 per watcher per day.................................7 1525 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 1526 per watcher per day.................................7 1527 (S06) Number of NOTIFY msgs for refreshes 1528 per watcher per day.................................0 1529 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1530 per watcher per day.................................0 1531 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1532 Number of msgs for all watchers per day...280,000,000 1533 Bytes for all watchers per day........114,800,000,000 1534 (S09) Total number & bytes of steady messages per day 1535 Number of msgs for all watchers........18,680,000,000 1536 Bytes for all watchers..............9,958,800,000,000 1538 ** Termination Messages 1539 (T01) Terminating SUBSCRIBE msgs per watcher..................1 1540 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1 1541 (T03) Terminating NOTIFY msgs per watcher.....................1 1542 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............1 1543 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1544 Number of msgs for all watchers............20,000,000 1545 Bytes for all watchers..................9,000,000,000 1546 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1547 Number of msgs for all watchers............20,000,000 1548 Bytes for all watchers..................7,400,000,000 1549 (T07) Total number & bytes of terminating NOTIFY msgs 1550 Number of msgs for all watchers............20,000,000 1551 Bytes for all watchers.................70,000,000,000 1552 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 1553 Number of msgs for all watchers............20,000,000 1554 Bytes for all watchers..................7,400,000,000 1555 (T09) Total number & bytes of terminating messages per day 1556 Number of msgs for all watchers............80,000,000 1557 Bytes for all watchers.................93,800,000,000 1559 ** Bottom Line 1560 (B01) Total number of message & bytes during the day 1561 Number of msgs.........................18,840,000,000 1562 Bytes..............................10,630,400,000,000 1563 (B02) Total number of message & bytes per second 1564 Number of msgs................................654,167 1565 Bytes.....................................369,111,111 1567 Figure 11: Very large networks peering with dialog, NOTIFY and 1568 partial optimizations 1570 Compared to the numbers we got for optimized very large peering 1571 networks (36,446,400,000,000 bytes per day, it seems that the partial 1572 notify can save a lot in the bandwidth. 1574 2.10. Other Protocols 1576 In SIP there are several differences from other protocols of presence 1577 as XMPP [6] and the proprietary protocols of the consumer domains. 1578 The differences are: 1580 o There is no 200 OK for each message. These protocols support only 1581 TCP and they do not compensate for network issues. 1582 o There is no refresh for subscription. 1583 o There is no NOTIFY upon termination of SUBSCRIPTION 1584 o The size of each message of these protocol is smaller since they 1585 are either binary and/or there is no need for the various headers 1586 that SIP uses for routing etc. So we need to assume smaller 1587 message sizes while we will keep the size of the presence document 1588 the same. 1590 The following is an analysis of the very large networks peering 1591 assuming all the changes in other protocols with respect to SIP. 1593 ** Constants 1594 (C01) Subscription lifetime (hours)...........................8 1595 (C02) Presence state changes / hour...........................6 1596 (C03) Subscription refresh interval / hour....................0 1597 (C04) Total federated presentities per watcher...............10 1598 (C05) Number of dialogs to maintain per watcher..............10 1599 (C06) Total number of watchers in domains............20,000,000 1600 (C07) SUBSCRIBE message size in bytes.......................150 1601 (C08) 200 OK for SUBSCRIBE message size in bytes..............0 1602 (C09) NOTIFY message size not including presence doc........150 1603 (C10) 200 OK for NOTIFY message size in bytes.................0 1604 (C11) Size of an average presence document................3,000 1606 ** Initial Messages 1607 (I01) Initial SUBSCRIBE msgs per watcher.....................10 1608 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............0 1609 (I03) Initial NOTIFY msgs per watcher........................10 1610 (I04) Initial 200 OK msgs (NOTIFY) per watcher................0 1611 (I05) Total number & bytes of initial SUBSCRIBE msgs 1612 Number of msgs for all watchers...........200,000,000 1613 Bytes for all watchers.................30,000,000,000 1614 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 1615 Number of msgs for all watchers.....................0 1616 Bytes for all watchers..............................0 1617 (I07) Total number & bytes of initial NOTIFY msgs 1618 Number of msgs for all watchers...........200,000,000 1619 Bytes for all watchers....................630,000,000 1620 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 1621 Number of msgs for all watchers.....................0 1622 Bytes for all watchers..............................0 1623 (I09) Total number & bytes of initial messages per day 1624 Number of msgs for all watchers...........400,000,000 1625 Bytes for all watchers.................660,00,000,000 1627 ** Steady State Messages 1628 (S01) NOTIFY msgs due to state change 1629 per watched presentity per day.....................46 1630 (S02) 200 (for NOTIFY due to state change) msgs 1631 per watched presentity per day......................0 1632 (S03) Total number and size of msgs due to state change per day 1633 Number of msgs for all watchers.........9,200,000,000 1634 Bytes for all watchers.............28,980,000,000,000 1636 (S04) Number of SUBSCRIBE msgs for refreshes 1637 per watcher per day.................................0 1638 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 1639 per watcher per day.................................0 1640 (S06) Number of NOTIFY msgs for refreshes 1641 per watcher per day.................................0 1642 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 1643 per watcher per day.................................0 1644 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 1645 Number of msgs for all watchers per day.............0 1646 Bytes for all watchers per day......................0 1647 (S09) Total number & bytes of steady messages per day 1648 Number of msgs for all watchers.........9,200,480,000 1649 Bytes for all watchers.............28,980,000,000,000 1651 ** Termination Messages 1652 (T01) Terminating SUBSCRIBE msgs per watcher.................10 1653 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........0 1654 (T03) Terminating NOTIFY msgs per watcher.....................0 1655 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............0 1656 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 1657 Number of msgs for all watchers...........200,000,000 1658 Bytes for all watchers.................30,000,000,000 1659 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 1660 Number of msgs for all watchers.....................0 1661 Bytes for all watchers..............................0 1662 (T07) Total number & bytes of terminating NOTIFY msgs 1663 Number of msgs for all watchers.....................0 1664 Bytes for all watchers..............................0 1665 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 1666 Number of msgs for all watchers.....................0 1667 Bytes for all watchers..............................0 1668 (T09) Total number & bytes of terminating messages per day 1669 Number of msgs for all watchers...........200,000,000 1670 Bytes for all watchers.................30,000,000,000 1672 ** Bottom Line 1673 (B01) Total number of message & bytes during the day 1674 Number of msgs..........................9,800,000,000 1675 Bytes..............................29,670,000,000,000 1676 (B02) Total number of message & bytes per second 1677 Number of msgs................................340,278 1678 Bytes...................................1,030,208,333 1680 Figure 12: Very large networks peering in other protocols 1682 Compared to the numbers we got for optimized very large peering 1683 networks (18,840,000,000 messages per day and 10,630,400,000,000 1684 bytes per day, the numbers of message with other protocols are only 1685 about half and with due to the partial notification optimization we 1686 get even less bytes per day. It seems that this shows that the 1687 scalability issue of presence is less due to some protocol choice but 1688 more an inherent issue with presence. 1690 3. State Management 1692 In previous sections we have discussed the big amount of messages 1693 that need to be sent to/from a presence server In this section the 1694 state that needs to be maintained by a presence server will be 1695 analysed and shown to be far from trivial. 1697 The presence server has two parallel tasks. 1699 1. Maintain the state of the presentities to which watchers 1700 subscribe. 1701 2. Maintain the state of the subscriptions of watchers and provide 1702 timely updates to the watchers. 1704 For a single subscription from a single watcher on a presentity, the 1705 presence server has to maintain the following state: 1707 o Subscription state including all the parameters that are needed in 1708 order to maintain the subscription as timers. 1709 o Optional filtering information that was requested by the watcher. 1710 This includes enough information that is needed for doing the 1711 filtering. In addition additional information has to be 1712 maintained if partial notification is being supported for the 1713 subscription 1714 o Optional rate management information as throttling 1715 o Watcher information [4], [5] that is the result of the 1716 subscription in order to enable watched presentities to see who is 1717 watching them. 1719 For each presentity that has been subscribed to in the presence 1720 server, the presence server has to maintain the following state: 1722 o A list of the subscriptions for the presentity. Note that this is 1723 already taken care of from the size calculation point of view by 1724 the subscription state above. 1725 o Authorization information for the presentity. 1727 For each presentity for which there was any publication and the 1728 presentity has a state other then a default value, the presence 1729 server has to maintain the current value of the presentity. 1731 3.1. State Size Calculations 1733 Lets assume the following sizes: 1735 o Subscription size - 2K bytes. This includes watcher information 1736 that need to be created by the presence server for each 1737 subscription. 1738 o Subscribed to resource - 1K bytes (for privacy information and 1739 other management info). The subscriptions themselves are already 1740 calculated in the previous bullet. 1741 o Resource with a state - 6K bytes. This is a moderate assumption 1742 if we take into account the amount of data that is being put in a 1743 presence document as multiple devices, calendar and geographical 1744 information. 1746 3.1.1. Tiny System 1748 o 10K subscriptions = 19M bytes. 1749 o 5K subscribed to presentities = 5M bytes. 1750 o 10K presentities with state = 58M bytes. 1752 Total is 82M bytes. 1754 3.1.2. Medium System 1756 o 100K subscriptions = 195M bytes. 1757 o 50K subscribed to presentities = 49M bytes. 1758 o 100K presentities with state = 586M bytes. 1760 Total is 830M bytes. 1762 3.1.3. Large System 1764 o 6M subscriptions = 11,718M bytes. 1765 o 3M subscribed to presentities = 2,929M bytes. 1766 o 4M presentities with state = 23437M bytes. 1768 Total is 38G bytes. 1770 3.1.4. Very Large System 1772 o 150M subscriptions = 292,969M bytes. 1773 o 75M subscribed to presentities = 73,242M bytes. 1774 o 100M presentities with state = 585,937M bytes. 1776 Total is 952G bytes which is a very big number for a very dynamic 1777 storage as needed by the presence server. 1779 Although the numbers above may seem moderate enough for the sizes 1780 that the presence server is handling we should consider the 1781 following: 1783 o Dynamic state - Although the state may seem not so big for 1784 databases even for the very large system, we need to remember that 1785 this state is a very dynamic state. Subscriptions come and go all 1786 the time, the status of presentities is being updated and so 1787 forth. This means that the presence server has to manage its 1788 state in a medium that is very dynamic and for such large sizes 1789 this task is not trivial. 1790 o Interlinked state - The subscriptions and the subscribed to 1791 presentities are dependent on each other. There needs to be a 1792 link from the presentity to the subscriptions and vice versa. See 1793 Section 4.5 about the interlinkage that is created due to resource 1794 lists. 1795 o Moderate assumptions - The size assumptions that were made above 1796 are quite moderate. As presence is becoming more a core 1797 middleware functionality that holds a lot of data on the user. In 1798 real-life the numbers above may be even higher and the presence 1799 server can have additional overhead as managing the SIP sessions, 1800 networking and more. 1802 Although the calculations above do not show that there is a real 1803 issue with state management of presence in medium systems or even in 1804 big systems since it should be possible to divide the state between 1805 different machines, the state size is still very big. A bigger issue 1806 with the state is more when resource lists are involved and create an 1807 interlinked state between many servers. In that case the division of 1808 very big state to multiple servers becomes less trivial... 1810 4. Processing complexities 1812 The basic presence paradigm consists from a watcher and a presentity 1813 to which the watcher watches. It sounds simple enough but there are 1814 many additions and extensions that the presence server has to manage 1815 that make the processing of the presence server very complex. 1817 In this section we show that in addition to the large amount of 1818 messages and the big state that the presence server has to handle, it 1819 has also to handle quite intensive processing for aggregation, 1820 partial notify and publish, filtering and privacy. This adds another 1821 complexity to the presence server in the CPU front in addition to the 1822 network and memory fronts that were described before. 1824 4.1. Aggregation 1826 A presence document may contain multiple resources. These resources 1827 can be devices of the presentity, information that is received form 1828 external providers of presence information for the presentity as 1829 geographical and calendar information and more. 1831 The presence server needs to be able to get the updates from all the 1832 resources and aggregate them correctly into a single presence 1833 document. Although this is just "XML processing" task, the amount of 1834 updates that the presence server may get, the need to keep the 1835 presence document aligned with its schema and the need to notify the 1836 users as soon as possible create a significant processing burden on 1837 the presence server 1839 4.2. Partial Publish and Notify 1841 Drafts [11], [12] define a way for the watcher to request getting 1842 only what was changed in the presence document and for the publisher 1843 of presence information to publish only what was changed in the 1844 presence document since the last publish. Although these 1845 optimizations help in reducing the amount of the data that is sent 1846 from/to the presence server, these optimizations create additional 1847 processing burden on the presence server. 1849 When a partial publish is arriving to the presence server, the 1850 presence server has to be able to process the partial publish, change 1851 only what is indicated in the partial publish while keeping the 1852 presence document in a well formed shape according to the schema. 1854 In partial notify the processing is even more complex since each 1855 watcher needs to get the partial update based on the last update that 1856 was received by that watcher. Therefore [11] specifies a versioning 1857 mechanism that enables the watcher to get the updates based on the 1858 previous state that it has seen. This versioning mechanism has to be 1859 maintained by the presence server for each watcher that is subscribed 1860 to a presentity and requires partial notify. 1862 4.3. Filtering 1864 Filtering as defined in RFCs [8], [9] enables a watcher to request to 1865 be notified only when the presence document fulfills certain 1866 conditions. Although this is a very convenient feature for watchers, 1867 the burden that is put on the presence server is quite big. For each 1868 change in the presence document, the presence server needs to compute 1869 the filtering expressions which can be very complex, decide whether 1870 and what to send to the watcher that have requested filtering. 1872 4.4. Authorization 1874 Draft [13] defines presence authorization rules that can be used by 1875 presentities to define who can see what from their presence 1876 documents. The processing that the presence server has to do here is 1877 very similar to filtering. When there is a change to any presence 1878 document that has privacy defined for it, the presence server needs 1879 to create different notification for different watchers according to 1880 what is defined in the authorization rules. 1882 4.5. Resource List Service 1884 RFC [10] defines a way to subscribe on a single URI while that URI is 1885 actually a list of resources that are being subscribed to by a single 1886 subscription. Although this is quite useful mechanism and it 1887 significantly saves on the number of sessions between the watcher and 1888 the presence server (as we show in the calculations of messages), 1889 this feature has the potential to make the scalability issue of 1890 presence systems harder and more complex. 1892 The reasons that resource lists may make the scalability problem of 1893 the presence server even more complex are: 1895 o Subscriptions and state - The resource list may contain reference 1896 to many other presence servers in many other domains. This 1897 requires the RLS to create subscriptions to other presence servers 1898 and buffer the state of all presentities in order to be able to 1899 provide the full state of the presentities in the list when 1900 needed. So in the overall system, the subscriptions that were 1901 saved between the watcher and the presence server are moved to the 1902 backend system while state has been duplicated between the various 1903 presence servers that serve the various presentities and the RLSs. 1904 This issue could have been mitigated if there was a way for the 1905 RLS to retrieve the presence information for many watchers while 1906 adhering to privacy when sending the actual notifications to the 1907 watchers. 1908 o Interlinkage - The resource list subscription will reach one RLS 1909 that will open it and send it to many presence servers and to 1910 other RLSs (if there is a subgroup inside the list). This way a 1911 complex linkage between the state of many components is created. 1912 This linkage makes state management and other maintenance of a 1913 presence systems quite complex. 1914 o Big lists are easy - There are two types of groups that may be 1915 used with this feature, private groups that are defined by/for 1916 each watcher and public groups that are defined in the system and 1917 can be used by any watcher. Although we should expect IT 1918 administrators to take caution when creating public groups, this 1919 may be not the case in real life. The connection between the size 1920 of the public group and the load on the presence server system may 1921 not apparent to everyone. Furthermore many public groups that are 1922 used in presence systems may have been created for other purposes 1923 as email systems (where the size of the lists was not so 1924 important) and are taken as they are to presence systems. So for 1925 example we may very easily find that a public group that actually 1926 covers all the users in the enterprise are used by many users in 1927 the enterprise thus creating unbearable load on the presence 1928 server. Note that this issue is not a protocol or design issue 1929 but more a usage issue that may have a real impact on the presence 1930 system. 1931 o Stopping notifications - A watcher may accidentally subscribe to a 1932 very big list and be overwhelmed by the amount of notifies that it 1933 receives from the presence server. There is no current way to 1934 stop this stream of notifies and even canceling the subscription 1935 may take time until being affective. 1937 The issues mentioned above are one example of an optimization that 1938 helps in one part of the system but creates even bigger problems in 1939 the overall system. There is a need to think about the problems 1940 listed above but more then that there is a need to make sure that 1941 when an optimization is introduced it does not create issues in other 1942 places. 1944 5. Current Optimizations 1946 This section lists and discusses several optimizations that are 1947 either already part of the SIP protocol or they have been suggested 1948 in various drafts. Several other optimizations that have been 1949 suggested but have not been discussed in the working group yet are 1950 summarized in [18]. 1952 o Subnot-etags - Draft [16]. This draft suggests ways to suppress 1953 the sending of unnecessary notifies when for example a 1954 subscription is refreshed. This suggestion seems to be an 1955 efficient optimization since it saves both the number of messages 1956 sent and on the processing time of the presence server. 1957 o Resource List Service - [10] enable creating a single subscription 1958 session between the watcher and the presence server for 1959 subscribing on a list of users. This saves the amount of sessions 1960 that are created between watchers and presence servers. On the 1961 other hand, this mechanism enables creating very large amount of 1962 subscriptions in the presence server/RLS system thus enabling the 1963 creation of a very large number of subscriptions between presence 1964 servers and RLSs with relatively few clients especially if large 1965 public groups are used. It seems that in order to really optimize 1966 in this area, the usage of large public groups should not be 1967 considered as BCP and there should be a way for an RLS to create a 1968 single subscription for multiple occurrences of the same resource 1969 in resource lists. See consolidates subscriptions below. 1970 o Partial notify/publish - Drafts [11], [12] define a way for the 1971 subscriber to request getting only what was changed in the 1972 presence document and for the publisher of presence information to 1973 publish only what was changed in the presence document since the 1974 last publish. Although these optimizations help in reducing the 1975 amount of actual data that is sent from/to the presence server, 1976 these optimizations create additional processing burden on the 1977 presence server as was discussed above. 1978 o Filtering as defined in RFCs [8], [9] enables a watcher to request 1979 to be notified only when the presence document fulfills certain 1980 conditions. Although this optimization enables saving on the 1981 amount of messages that are sent from the presence server to the 1982 watcher, this optimization puts more burden on the processing time 1983 of the presence server as was discussed above. 1984 o Throttling [19] defines a mechanism in which a watcher requires to 1985 be updated only in certain intervals. Although this mechanism may 1986 give some extra load on the processing time of the presence 1987 server, that load is negligible and the reduction on the amount of 1988 messages sent from the presence server to the watchers is 1989 significant. This optimization is even more important with 1990 resource lists where there can be many resources in the resource 1991 lists and if the traffic of updates on resource list is not 1992 regulated, the watcher may get very large amount of notifications. 1993 o Presence specific sigcomp dictionary [14] defines a SIGCOMP [3] 1994 dictionary for presence. This optimization will enable to reduce 1995 the number of bytes that are transferred in presence systems by 1996 compressing the textual SIP messages and using the specialized 1997 presence dictionary the compression may be more significant then 1998 just using SIGCOMP as is. Note that number of actual messages 1999 will remain the same and a calculation of the amount of bytes that 2000 will be saved may be useful here. 2001 o Content Indirection [7] enables sending only the URI of the 2002 presence document to the watcher thus offloading the presence 2003 server from sending the presence document to the watcher. This 2004 optimization may be useful in some cases especially where there is 2005 a big number of users that get the same presence document. 2007 6. Conclusions 2009 The document analyses the scalability of presence systems and of the 2010 SIP based in particular. It is apparent that the scalability of 2011 these systems is far from being trivial from several perspectives: 2012 number of messages, network bandwidth, state management and CPU load. 2014 As part of the analysis we have analysed several optimizations and 2015 showed the effect of these optimizations on the number of messages 2016 and the number of bytes that are sent between the federating domains. 2018 We have also computed the number of messages and bytes for a very 2019 large number while assuming a protocol that has much less "overhead" 2020 then SIP. Even in that protocol we got relatively high numbers. 2022 It is very possible that the issues that are described in this 2023 document are inherent to presence systems in general and not specific 2024 to the SIMPLE protocol. Organizations need to be prepared to invest 2025 a lot in network and hardware in order to create real big systems. 2026 However, it is apparent that not all the possible optimizations were 2027 done yet and further work is needed in the IETF in order to provide 2028 better scalability 2030 It seems that we need to think about the problem in a different way. 2031 We need to think about scalability as part of the protocol design. 2032 The IETF tends not to think about actual deployments when designing a 2033 protocol but in this case it seems that if we do not think about 2034 scalability with the protocol design it will not be very hard to 2035 scale. 2037 We should also consider whether using the same protocol between 2038 clients and servers and between servers is a good choice with this 2039 problem? It may be that in interdomain or even between servers in 2040 the same domain (as between RLSs and presence servers) there is a 2041 need to have a different protocol that will be very optimized for the 2042 load and can assume some assumptions about the network (e.g. do not 2043 use unreliable protocol as UDP but only TCP). 2045 Another issue that is more concerning protocol design is whether 2046 NOTIFY messages should not be considered as media as the audio, video 2047 and even text messaging are considered? The SUBSCRIBE can be 2048 extended to do similar three way handshake as INVITE and negotiate 2049 where the notify messages should go, rate and other parameters. This 2050 way the load can be offloaded to specialized NOTIFY "relays" thus not 2051 loading the control path of SIP. 2053 7. Security Considerations 2055 This document discusses scalability issues with the existing SIP/ 2056 SIMPLE presence protocol and model. Therefore, there are no security 2057 considerations to be considered for this document. However, a lot of 2058 the possible optimizations that should emerge as a result of this 2059 document will have security implications that will need to be solved. 2061 8. Changes from Previous Versions 2063 8.1. Changes in version 02 2065 o Fixed a bug in the calculations. Thanks to Marc Willekens for 2066 finding the bug. 2068 8.2. Changes in version 01 2070 o Clarifications and corrections of the computation model and the 2071 computations. 2072 o Added several more computations to show the influence of different 2073 optimizations. 2074 o The requirements were moved to [17] 2075 o The new suggestions for optimizations were moved to [18] 2077 9. Acknowledgments 2079 We would like to thank Jonathan Rosenberg, Ben Campbell, Markus 2080 Isomaki Piotr Boni, David Viamonte and Aki Niemi for ideas and input. 2081 Special thanks to Marc Willekens for finding a bug in the 2082 calculations. 2084 10. References 2086 10.1. Normative References 2088 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2089 Levels", BCP 14, RFC 2119, March 1997. 2091 10.2. Informational References 2093 [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 2094 Notification", RFC 3265, June 2002. 2096 [3] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, 2097 Z., and J. Rosenberg, "Signaling Compression (SigComp)", 2098 RFC 3320, January 2003. 2100 [4] Rosenberg, J., "A Watcher Information Event Template-Package 2101 for the Session Initiation Protocol (SIP)", RFC 3857, 2102 August 2004. 2104 [5] Rosenberg, J., "An Extensible Markup Language (XML) Based 2105 Format for Watcher Information", RFC 3858, August 2004. 2107 [6] Saint-Andre, P., "End-to-End Signing and Object Encryption for 2108 the Extensible Messaging and Presence Protocol (XMPP)", 2109 RFC 3923, October 2004. 2111 [7] Burger, E., "A Mechanism for Content Indirection in Session 2112 Initiation Protocol (SIP) Messages", RFC 4483, May 2006. 2114 [8] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 2115 Requena, "Functional Description of Event Notification 2116 Filtering", RFC 4660, September 2006. 2118 [9] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 2119 Requena, "An Extensible Markup Language (XML)-Based Format for 2120 Event Notification Filtering", RFC 4661, September 2006. 2122 [10] Roach, A., Campbell, B., and J. Rosenberg, "A Session 2123 Initiation Protocol (SIP) Event Notification Extension for 2124 Resource Lists", RFC 4662, August 2006. 2126 [11] Lonnfors, M., "Session Initiation Protocol (SIP) extension for 2127 Partial Notification of Presence Information", 2128 draft-ietf-simple-partial-notify-09 (work in progress), 2129 February 2007. 2131 [12] Lonnfors, M., "Publication of Partial Presence Information", 2132 draft-ietf-simple-partial-publish-06 (work in progress), 2133 February 2007. 2135 [13] Rosenberg, J., "Presence Authorization Rules", 2136 draft-ietf-simple-presence-rules-10 (work in progress), 2137 July 2007. 2139 [14] Garcia-Martin, M., "The Presence-Specific Static Dictionary for 2140 Signaling Compression (Sigcomp)", 2141 draft-garcia-simple-presence-dictionary-05 (work in progress), 2142 May 2007. 2144 [15] Camarillo, G., "Subscriptions to Request-Contained Resource 2145 Lists in the Session Initiation Protocol (SIP)", 2146 draft-ietf-sipping-uri-list-subscribe-05 (work in progress), 2147 May 2006. 2149 [16] Niemi, A., "An Extension to Session Initiation Protocol (SIP) 2150 Events for Conditional Event Notification", 2151 draft-ietf-sip-subnot-etags-00 (work in progress), May 2007. 2153 [17] Houri, A., "Scaling Requirements for Presence in SIP/SIMPLE", 2154 draft-houri-sipping-presence-scaling-requirements-00 (work in 2155 progress), July 2007. 2157 [18] Houri, A., "Scaling Optimizations for Presence in SIP/SIMPLE", 2158 draft-houri-simple-interdomain-scaling-optimizations-00 (work 2159 in progress), July 2007. 2161 [19] Niemi, A., "Session Initiation Protocol (SIP) Event 2162 Notification Extension for Notification Throttling", 2163 draft-niemi-sipping-event-throttle-05 (work in progress), 2164 March 2007. 2166 Authors' Addresses 2168 Avshalom Houri 2169 IBM 2170 Science Park Building 18/D 2171 Rehovot, 2172 Israel 2174 Email: avshalom@il.ibm.com 2176 Tim Rang 2177 Microsoft Corporation 2178 One Microsoft Way 2179 Redmond, WA 98052 2180 USA 2182 Email: timrang@microsoft.com 2184 Edwin Aoki 2185 AOL LLC 2186 360 W. Caribbean Drive 2187 Sunnyvale, CA 94089 2188 USA 2190 Email: aoki@aol.net 2191 Vishal Singh 2192 Columbia University 2193 Department of Computer Science 2194 450 Computer Science Building 2195 New York, NY 10027 2196 US 2198 Email: vs2140@cs.columbia.edu 2199 URI: http://www.cs.columbia.edu/~vs2140 2201 Henning Schulzrinne 2202 Columbia University 2203 Department of Computer Science 2204 450 Computer Science Building 2205 New York, NY 10027 2206 US 2208 Phone: +1 212 939 7004 2209 Email: hgs+ecrit@cs.columbia.edu 2210 URI: http://www.cs.columbia.edu/~hgs 2212 Full Copyright Statement 2214 Copyright (C) The IETF Trust (2007). 2216 This document is subject to the rights, licenses and restrictions 2217 contained in BCP 78, and except as set forth therein, the authors 2218 retain all their rights. 2220 This document and the information contained herein are provided on an 2221 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2222 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2223 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2224 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2225 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2226 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2228 Intellectual Property 2230 The IETF takes no position regarding the validity or scope of any 2231 Intellectual Property Rights or other rights that might be claimed to 2232 pertain to the implementation or use of the technology described in 2233 this document or the extent to which any license under such rights 2234 might or might not be available; nor does it represent that it has 2235 made any independent effort to identify any such rights. Information 2236 on the procedures with respect to rights in RFC documents can be 2237 found in BCP 78 and BCP 79. 2239 Copies of IPR disclosures made to the IETF Secretariat and any 2240 assurances of licenses to be made available, or the result of an 2241 attempt made to obtain a general license or permission for the use of 2242 such proprietary rights by implementers or users of this 2243 specification can be obtained from the IETF on-line IPR repository at 2244 http://www.ietf.org/ipr. 2246 The IETF invites any interested party to bring to its attention any 2247 copyrights, patents or patent applications, or other proprietary 2248 rights that may cover technology that may be required to implement 2249 this standard. Please address the information to the IETF at 2250 ietf-ipr@ietf.org. 2252 Acknowledgment 2254 Funding for the RFC Editor function is provided by the IETF 2255 Administrative Support Activity (IASA).