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