idnits 2.17.1 draft-ietf-simple-interdomain-scaling-analysis-00.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 1941. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1952. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1959. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1965. 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 (February 26, 2007) is 6240 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '4' is defined on line 1810, 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-08 == 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-08 == Outdated reference: A later version (-04) exists of draft-ietf-simple-xml-patch-ops-02 == Outdated reference: A later version (-06) exists of draft-garcia-simple-presence-dictionary-01 == Outdated reference: A later version (-03) exists of draft-ietf-sip-uri-list-message-01 == Outdated reference: A later version (-03) exists of draft-niemi-sip-subnot-etags-02 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE WG A. Houri 3 Internet-Draft IBM 4 Intended status: Standards Track T. Rang 5 Expires: August 30, 2007 Microsoft Corporation 6 E. Aoki 7 AOL LLC 8 V. Singh 9 H. Schulzrinne 10 Columbia U. 11 February 26, 2007 13 Problem Statement for SIP/SIMPLE 14 draft-ietf-simple-interdomain-scaling-analysis-00.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 August 30, 2007. 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. Several suggested 52 optimization to the SIMPLE protocol are analysed with the possible 53 impact on the load. 55 Table of Contents 57 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Message Load . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 3.1. Known Optimizations . . . . . . . . . . . . . . . . . . . 7 61 3.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7 62 3.3. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 3.4. SIMPLE with no optimizations . . . . . . . . . . . . . . . 10 64 3.5. SIMPLE with suggested optimizations . . . . . . . . . . . 11 65 3.6. Presence Federations . . . . . . . . . . . . . . . . . . . 12 66 3.6.1. Widely distributed inter-domain presence . . . . . . . 12 67 3.6.2. Associated inter-domain presence . . . . . . . . . . . 14 68 3.6.3. Very large network peering . . . . . . . . . . . . . . 15 69 3.6.4. Intra-domain peering . . . . . . . . . . . . . . . . . 17 70 4. Resource List Service . . . . . . . . . . . . . . . . . . . . 20 71 5. State Management . . . . . . . . . . . . . . . . . . . . . . . 22 72 5.1. State Size Calculations . . . . . . . . . . . . . . . . . 23 73 5.1.1. Tiny System . . . . . . . . . . . . . . . . . . . . . 23 74 5.1.2. Medium System . . . . . . . . . . . . . . . . . . . . 23 75 5.1.3. Large System . . . . . . . . . . . . . . . . . . . . . 23 76 5.1.4. Very Large System . . . . . . . . . . . . . . . . . . 24 77 6. Processing complexities . . . . . . . . . . . . . . . . . . . 25 78 6.1. Aggregation . . . . . . . . . . . . . . . . . . . . . . . 25 79 6.2. Partial Publish and Notify . . . . . . . . . . . . . . . . 25 80 6.3. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 26 81 6.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 26 82 7. Possible Optimizations . . . . . . . . . . . . . . . . . . . . 27 83 7.1. Common NOTIFY for multiple watchers . . . . . . . . . . . 27 84 7.1.1. Privacy filtering . . . . . . . . . . . . . . . . . . 27 85 7.1.2. NOTIFY failure aggregation . . . . . . . . . . . . . . 28 86 7.1.3. Transferring the watcher list . . . . . . . . . . . . 28 87 7.1.4. Message flow example . . . . . . . . . . . . . . . . . 29 88 7.1.5. SIP message examples for common NOTIFY . . . . . . . . 31 89 7.2. Aggregation of NOTIFY messages (Batched notification) . . 32 90 7.2.1. Extracting and sending individual NOTIFY using 91 Aggregated NOTIFY message body . . . . . . . . . . . . 32 93 7.2.2. Subscription termination and failure indication in 94 NOTIFY delivery . . . . . . . . . . . . . . . . . . . 33 95 7.2.3. Message flow example . . . . . . . . . . . . . . . . . 33 96 7.2.4. SIP message flow example for batched notification . . 35 97 7.3. Timed presence . . . . . . . . . . . . . . . . . . . . . . 37 98 7.4. On-Demand presence (Fetch or Pull Model) . . . . . . . . . 38 99 7.5. Adapting the subscription rate . . . . . . . . . . . . . . 38 100 7.6. Other Optimizations . . . . . . . . . . . . . . . . . . . 38 101 8. Extremely Optimized Model . . . . . . . . . . . . . . . . . . 41 102 9. Suggested Requirements . . . . . . . . . . . . . . . . . . . . 43 103 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 45 104 11. Security Considerations . . . . . . . . . . . . . . . . . . . 46 105 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47 106 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 107 13.1. Normative References . . . . . . . . . . . . . . . . . . . 48 108 13.2. Informational References . . . . . . . . . . . . . . . . . 48 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 110 Intellectual Property and Copyright Statements . . . . . . . . . . 52 112 1. Requirements notation 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [1]. 118 2. Introduction 120 The document analyses the traffic that is generated due to presence 121 subscriptions between domains. It is shown that the amount of 122 traffic can be extremely big. In addition to the very large traffic 123 the document also analyses the affects of a large presence system on 124 the memory footprint and the CPU load. Several suggested 125 optimization to the SIMPLE protocol are analysed with the possible 126 impact on the load. 128 Although this document is an analysis document and not a BCP 129 document, several possible optimizations and directions are listed in 130 addition to an initial set of requirements for what should be the 131 characteristic of the solution to the problem stated in the document 133 This document is intended to be used by the SIMPLE WG in order to 134 work on possible solutions that will make the deployment of a 135 presence server more reasonable task. Note that the document does 136 not try to compare the SIP based presence server to other types of 137 presence servers but only analyses the SIP based presence server. It 138 is very likely that similar scalability issues are inherent to the 139 deployment of presence systems and not to a certain protocol. 141 The document discusses the following areas. In each area we try to 142 show the complexity and the load that the presence server has to 143 handle in order to provide its service. 145 o Messages load - By computing the number of messages that are 146 required for connecting presence systems the document shows that 147 the number of messages is very big and it is quite obvious that 148 some optimizations are needed. In addition we also show that the 149 bandwidth required is also very big. 151 o State management - Due to the nature of the service that the 152 presence server provides, the presence server has to manage a 153 relatively big and complex state and some computations are 154 provided in the document. 156 o Processing complexities - The presence server maintains many small 157 objects and has to do frequent operations on these objects. We 158 show that these operations and especially the optimizations that 159 are intended to save on the amount of data that is being sent 160 between watchers and presence servers, are not so simple and may 161 create a very heavy processing load on the presence server. 163 o Groups - Resource List Servers [12] optimize the number of 164 sessions that are created between the watchers and the presence 165 server. On the other hand, this optimization may create an 166 exponential size of subscription due to the unbearable ease of 167 subscribing to large groups. 169 The term presence domain or presence system appears in the document 170 several time. By this term we refer to a presence server that 171 provides presence subscription and notification services to its 172 users. The system can be a system that is deployed in a small 173 enterprise or in a very large consumer network. 175 3. Message Load 177 Even though some optimizations are approved or are being defined, we 178 show in this section that a very large number of messages & large 179 bandwidth are needed in order to establish federation between 180 presence systems of large communities. Further thinking is needed in 181 order to make large deployment of presence systems less resource 182 demanding. 184 Note that even though this document talks about inter domain traffic, 185 the introduction of resource list servers (RLSs) [12] introduce very 186 similar traffic pattern within a domain as between domains. See 187 detailed discussion on resource lists in section Section 4. 189 3.1. Known Optimizations 191 The current optimizations that are approved or considered in the 192 SIMPLE group can be divided into two categories: 194 o Dialogs saving optimization - Here we refer to optimizations as 195 the resource list RFC [12] or to the Uri list subscriptions draft 196 [18]. These documents define ways to reduce the number of dialogs 197 that are required between the subscriber and the presence system. 199 o Notification optimizations - Here we refer to the optimizations 200 that are suggested in the subnot-etags draft [20]. This draft 201 suggests ways to suppress the sending of unnecessary notifies when 202 for example a subscription is refreshed. There are other drafts 203 that reduce the size of messages as partial notifies or filtering 204 but in this document we mostly care about the amount of messages & 205 bandwidth. 207 3.2. Assumptions 209 In the document we have several assumptions regarding size of 210 messages, rate of presence change and more. It should be noted that 211 these assumptions are not directly based on rigorous statistics that 212 was done on actual SIP based messages but more from experience on 213 other types of presence based systems. 215 Even though the assumptions in this document are not based on 216 rigorous statistical data the target here is not to analyse specific 217 system but show that even with VERY moderate assumptions, the number 218 of messages, the network bandwidth, the required state management and 219 the load on the CPU is very high. Real life systems should have a 220 much bigger scalability requirements. for example the presence state 221 change that we assumed (one presence state change per hour) is maybe 222 one of the most moderate assumptions that we have taken. Experience 223 from consumer networks show that the frequency here is much bigger 224 and especially with the younger generation. In an environment where 225 a user may have several devices and other resources for presence 226 information as geographical location and calendar the frequency of 227 presence state changes will be much higher. 229 It is very hard to measure presence load since the behavior of users 230 is very different. Some users will have a very small number of 231 presentities in their watch list while others may have hundreds. 232 Some users will change their state a lot and have many sources of 233 presence information while other may have very small number of 234 changes during the day. In addition there that "rush hour" 235 calculation that was not included in this document yet (to be added). 236 Rush hour differs between different enterprises and is still 237 different in the consumer presence systems. It is very hard if not 238 impossible to take into a static model all the possible combinations. 240 Saying the above, there are still several things to be done to create 241 a more complete picture: 243 o Get rigorous statistical data that can be formally published from 244 real presence systems 246 o Add to the model the possibility of having multiple sources of 247 presence data per presentity and change calculations accordingly 249 o Add "rush hour" calculations for the end and the beginning of the 250 day 252 The authors will especially appreciate any input in this area that 253 will help us to create a more real life model. We intend to try and 254 gather more data and improve the assumptions and the model in the 255 next revisions of this document. 257 3.3. Analysis 259 The basic SIMPLE subscription dialog involves the following message- 260 transfer: 262 o SUBSCRIBE/200 264 o Initial NOTIFY/200 266 o (j) NOTIFY/200 where 'j' is the number of presence changes seen by 267 the watcher 269 o (k) SUBSCRIBE/200 where 'k' is the number of subscription dialog 270 refresh periods 272 o SUBSCRIBE/200 with Expires = 0 to terminate the dialog 274 o NOTIFY/200 ending the dialog 276 An individual watcher will generate X number of SIMPLE subscription 277 dialogs corresponding to the number of presentities it chooses to 278 watch. The amount of traffic generated is significantly affected by 279 several factors: 281 o Number of watchers connected to the system 283 o Number of presentities connected to the system 285 o Frequency of changes to presence information 287 This document contains several calculations that show the expected 288 message rate and bandwidth between presence domains. The following 289 explains the assumptions and methods behind the calculations: 291 o (A01) Subscription lifetime (hours)- The assumed lifetime of a 292 subscription in hours. Here we assume 8 hours for all 293 calculations. 295 o (A02) Presence state changes / hour - The average time that a 296 presentity changes his/hers status in one hour. We assumed 3 297 times per hour for most calculations. Note that for some users in 298 consumer messaging systems, the actual number of changes is likely 299 to be much higher. 301 o (A03) Subscription refresh interval / hour - The duration of the 302 SUBSCRIBE session after which it needs to be refreshed. We 303 assumed that the duration is one hour. 305 o (A04) Total federated presentities per watcher - The number of 306 presentities that the watcher is watching. The number here 307 changes in this document according to the type of the specific 308 deployment 310 o (A05) Number of dialogs to maintain per watcher - The number of 311 the SUBSCRIBE dialogs that are maintained per watcher. if a dialog 312 optimization is not assumed this number is equal to A04, otherwise 313 it is 1 315 o (A06) Number of watchers in a federated presence domain - The 316 number of watchers in one presence domain that watch presentities 317 in the other domain. The number here varies according to the 318 assumptions for a specific deployment 320 o (A07) Initial SUBSCRIBE/200 per watcher = A05*2 (message and an OK 322 o (A08) Initial NOTIFY/200 per watcher = A05*2 (message and an OK) 324 o (A09) Total initial messages = (A07+A08)*A06 326 o (A10) NOTIFY/200 per watched presentity = (A02*A01*A04*2) (message 327 and an OK) 329 o (A11) SUBSCRIBE/200 refreshes = (A01/A03)*A05*2 (message and an 330 OK) 332 o (A12) NOTIFY/200 due to subscribe refresh - In a deployment where 333 the notification optimization is not deployed this number will be 334 ((A01/A03)*A05), otherwise it is 0 336 o (A13) Number of steady state messages = (A10+A11+A12)*A06 338 o (A14) SUBSCRIBE termination = A05*2 (message and an OK) 340 o (A15) NOTIFY terminated = A05*2 (message and an OK) 342 o (A16) Number of sign-out messages = (A14+A15)*A06 344 o (A17) Total messages between domains (both directions where users 345 from domain A subscribe to users from domain B and vice versa)= 346 (A09+A13+A16)*2 348 o (A18) Total number of messages / second = A17/A01/3600 (seconds in 349 hour) 351 o (A19) Total number of K bytes per second. Assuming 1K bytes per 352 SUBSCRIBE/200 pair and 4K bytes per NOTIFY/200 pair. Note that in 353 reality the NOTIFY size may be much bigger but using partial 354 NOTIFY should reduce the size considerably 356 3.4. SIMPLE with no optimizations 358 The following table uses some common presence characteristics to 359 demonstrate the effect these factors have on state and message rate 360 within a presence domain using base SIMPLE protocols without any 361 proposed optimizations. In this example, there are two presence 362 domains, each with 20,000 federating users with an average of 4 363 contacts in the peer domain 364 (A01) Subscription lifetime (hours)...........................8 365 (A02) Presence state changes / hour...........................3 366 (A03) Subscription refresh interval / hour....................1 367 (A04) Total federated presentities per watcher................4 368 (A05) Number of dialogs to maintain per watcher...............4 369 (A06) Number of watchers in a federated presence domain..20,000 371 (A07) Initial SUBSCRIBE/200 per watcher.......................8 372 (A08) Initial NOTIFY/200 per watcher..........................8 373 (A09) Total initial messages............................320,000 375 (A10) NOTIFY/200 per watched presentity.....................192 376 (A11) SUBSCRIBE/200 refreshes................................64 377 (A12) NOTIFY/200 due to subscribe refresh....................64 378 (A13) Number of steady state messages.................6,400,000 380 (A14) SUBSCRIBE termination...................................8 381 (A15) NOTIFY terminated.......................................8 382 (A16) Number of sign-out messages.......................320,000 384 (A17) Total messages between domains.................14,080,000 385 (A18) Total number of messages / second.....................489 386 (A19) Total number of bytes / second on the wire..........830KB 388 Figure 1: SIMPLE with no optimizations 390 3.5. SIMPLE with suggested optimizations 392 The same analysis provided above is repeated here with the assumption 393 that both the dialog and the notification optimizations are applied. 394 Note that while the sign-in (ramp up) and sign-out messages flows are 395 positively affected, the steady state rates are not. 397 The optimizations enable the creation of a single dialog to the other 398 domain from each watcher for the set of presentities it is watching. 399 The optimizations also enable that there will be no need for a NOTIFY 400 upon refreshing a SUBSCRIBE since the NOTIFY should not be sent in 401 the refresh since it should be the same one that was sent when there 402 was a state change for the presentity. 404 (A01) Subscription lifetime (hours)...........................8 405 (A02) Presence state changes /hour............................3 406 (A03) Subscription refresh interval / hour....................1 407 (A04) Total federated presentities per watcher................4 408 (A05) Number of dialogs to maintain per watcher...............1 409 (A06) Number of watchers in a federated presence domain..20,000 411 (A07) Initial SUBSCRIBE/200 per watcher.......................2 412 (A08) Initial NOTIFY/200 per watcher..........................2 413 (A09) Total initial messages.............................80,000 415 (A10) NOTIFY/200 per watched presentity.....................192 416 (A11) SUBSCRIBE/200 refreshes................................16 417 (A12) NOTIFY/200 due to subscribe refresh.....................0 418 (A13) Number of steady state messages.................4,160,000 420 (A14) SUBSCRIBE termination...................................2 421 (A15) NOTIFY terminated.......................................2 422 (A16) Number of sign-out messages........................80,000 424 (A17) Total messages between domains..................8,640,000 425 (A18) Total number of messages / second.....................300 426 (A19) Total number of bytes / second on the wire..........571KB 428 Figure 2: SIMPLE with optimizations 430 3.6. Presence Federations 432 While these scalability issues exist in any large deployment, certain 433 characteristics make the deployment conducive to the existing 434 resource- list optimizations, and others have characteristics that 435 cannot be exploited with the existing SIMPLE model. Following is a 436 list of federation relationships that have varying usage 437 characteristics. For each, a message rate and bandwidth table is 438 provided reflecting typical changes message rates. Those 439 characteristics can alter the overall effectiveness of existing 440 optimizations. 442 3.6.1. Widely distributed inter-domain presence 444 In some environments presence federation may be very common, perhaps 445 even more common than intra-domain presence. An example of this type 446 of environment is a small ISV or public server. Users in that small 447 ISV are not likely to subscribe to the presence of other users in the 448 their server since they do not necessarily have any relationship with 449 each other aside from receiving service from the same provider. They 450 are much more likely to be subscribed to the presence of users in one 451 of the federated domains (whether in consumer domains, academic, 452 other ISVs, etc). Common characteristics of this deployment are: 454 o Federated subscriptions are the majority of subscription traffic 456 o Individual users are likely to subscribe to multiple users in any 457 one domain 459 o The intersection of users in the deployment watching the same 460 presentities is quite small (i.e., probability that watchers in 461 the domain subscribe to the same presentity is low) 463 To account for the extraordinarily high percentage of federation 464 traffic, the number of federated presentities is increased to 20. 465 The number of watchers in the domain could also be adjusted to 466 account for an expected larger community of users being peered with, 467 it is omitted here for simplification 469 The first table below provides the calculations without optimizations 470 the second table provides the calculations with optimization. Note 471 that the number of messages per second decreases by a quarter with 472 the optimizations but it is still quite big. It is interesting to 473 see that the bandwidth is almost the quarter of the bandwidth when 474 optimizations are applied. 476 (A01) Subscription lifetime (hours)...........................8 477 (A02) Presence state changes / hour...........................3 478 (A03) Subscription refresh interval / hour....................1 479 (A04) Total federated presentities per watcher...............20 480 (A05) Number of dialogs to maintain per watcher..............20 481 (A06) Number of watchers in a federated presence domain..20,000 483 (A07) Initial SUBSCRIBE/200 per watcher......................40 484 (A08) Initial NOTIFY/200 per watcher.........................40 485 (A09) Total initial messages..........................1,600,000 487 (A10) NOTIFY/200 per watched presentity.....................960 488 (A11) SUBSCRIBE/200 refreshes...............................320 489 (A12) NOTIFY/200 due to subscribe refresh...................320 490 (A13) Number of steady state messages................32,000,000 492 (A14) SUBSCRIBE termination..................................40 493 (A15) NOTIFY terminated......................................40 494 (A16) Number of sign-out messages.....................1,600,000 496 (A17) Total messages between domains.................70,400,000 497 (A18) Total number of messages / second...................2,444 498 (A19) Total number of bytes / second on the wire.........1968KB 499 Figure 3: Widely distributed inter-domain with no optimizations 501 (A01) Subscription lifetime (hours)...........................8 502 (A02) Presence state changes / hour...........................3 503 (A03) Subscription refresh interval / hour....................1 504 (A04) Total federated presentities per watcher...............20 505 (A05) Number of dialogs to maintain per watcher...............1 506 (A06) Number of watchers in a federated presence domain..20,000 508 (A07) Initial SUBSCRIBE/200 per watcher.......................2 509 (A08) Initial NOTIFY/200 per watcher..........................2 510 (A09) Total initial messages.............................80,000 512 (A10) NOTIFY/200 per watched presentity.....................960 513 (A11) SUBSCRIBE/200 refreshes................................16 514 (A12) NOTIFY/200 due to subscribe refresh.....................0 515 (A13) Number of steady state messages................19,520,000 517 (A14) SUBSCRIBE termination...................................2 518 (A15) NOTIFY terminated.......................................2 519 (A16) Number of sign-out messages........................80,000 521 (A17) Total messages between domains.................39,360,000 522 (A18) Total number of messages / second...................1,367 523 (A19) Total number of bytes / second on the wire..........571KB 525 Figure 4: Widely distributed inter-domain with optimizations 527 3.6.2. Associated inter-domain presence 529 In this type of environment, the domain is a collection of associated 530 users such as an enterprise. Here, federation is once again very 531 common. However, there is also a strong association between some 532 users in the deployment. These associations make it somewhat more 533 likely that users in that domain will be watchers of the same 534 presentity. This can occur because of business relationships (e.g. 535 two co-workers on a project federating with a partner company). 537 Common characteristics of this deployment are: 539 o Federated subscriptions are large minority or small majority of 540 subscription traffic 542 o Individual users are likely to subscribe to multiple users in any 543 one domain, especially their own 545 o The intersection of users in the deployment watching the same 546 presentities increases 548 This federation type has traffic rates similar to the previous 549 examples but with different levels of association of the users. 551 3.6.3. Very large network peering 553 In this environment, two or more very large networks create a peering 554 relationship allowing their users to subscribe to presence in the 555 other domains. Where as the number of users in other deployment 556 types ranges from hundreds to several hundred thousand, these large 557 networks host up to hundreds of millions of users. Examples of these 558 networks are large wireless carriers and consumer IM networks. 560 Common characteristics of this deployment are: 562 o As users become accustomed to network boundaries disappearing, 563 federated subscriptions become as common as subscriptions within 564 the same domain 566 o Individual users are highly likely to want to see presence of 567 multiple presentities in the peer network 569 o The intersection of users in the deployment watching the same 570 presentities is very high (i.e., two or more users in network A 571 are extremely likely to be watching a same user in network B) 573 o Status changes increase greatly due to typical observed consumer 574 behavior 576 The first table below provides the calculations without optimizations 577 the second table provides the calculations with optimizations. Even 578 though the optimizations help a lot (almost cut the number of 579 messages by half), the numbers are still very high. Note also that 580 the bandwidth required is very high (almost 1GB per second). 582 (A01) Subscription lifetime (hours)..............................8 583 (A02) Presence state changes / hour..............................6 584 (A03) Subscription refresh interval / hour.......................1 585 (A04) Total federated presentities per watcher..................10 586 (A05) Number of dialogs to maintain per watcher.................10 587 (A06) Number of watchers in a federated presence domain.10,000,000 589 (A07) Initial SUBSCRIBE/200 per watcher.........................20 590 (A08) Initial NOTIFY/200 per watcher............................20 591 (A09) Total initial messages...........................400,000,000 593 (A10) NOTIFY/200 per watched presentity........................960 594 (A11) SUBSCRIBE/200 refreshes..................................160 595 (A12) NOTIFY/200 due to subscribe refresh......................160 596 (A13) Number of steady state messages...............12,800,000,000 598 (A14) SUBSCRIBE termination.....................................20 599 (A15) NOTIFY terminated.........................................20 600 (A16) Number of sign-out messages....................4,000,000,000 602 (A17) Total messages between domains................27,200,000,000 603 (A18) Total number of messages / second....................944,444 604 (A19) Total number of bytes / second on the wire.........880,555KB 606 Figure 5: Very large network peering with no optimizations 608 (A01) Subscription lifetime (hours)..............................8 609 (A02) Presence state changes / hour..............................6 610 (A03) Subscription refresh interval / hour.......................1 611 (A04) Total federated presentities per watcher..................10 612 (A05) Number of dialogs to maintain per watcher..................1 613 (A06) Number of watchers in a federated presence domain.10,000,000 615 (A07) Initial SUBSCRIBE/200 per watcher..........................2 616 (A08) Initial NOTIFY/200 per watcher.............................2 617 (A09) Total initial messages............................40,000,000 619 (A10) NOTIFY/200 per watched presentity........................960 620 (A11) SUBSCRIBE/200 refreshes...................................16 621 (A12) NOTIFY/200 due to subscribe refresh........................0 622 (A13) Number of steady state messages................9,760,000,000 624 (A14) SUBSCRIBE termination......................................2 625 (A15) NOTIFY terminated..........................................2 626 (A16) Number of sign-out messages.......................40,000,000 628 (A17) Total messages between domains................19,680,000,000 629 (A18) Total number of messages / second....................683,333 630 (A19) Total number of bytes / second on the wire.........545,833KB 632 Figure 6: Very large network peering with optimizations 634 3.6.4. Intra-domain peering 636 Within a particular domain, multiple presence infrastructures are 637 deployed with users split between the two. This scenario is unique 638 in that federated messages do not pass outside the administrative 639 domain's network. The two infrastructures peer directly inside the 640 domain. A common example of this is an enterprise IT system with 641 multiple independent vendor presence solutions deployed(e.g., a 642 presence solution for desktop messaging deployed alongside a presence 643 solution for IP telephony). 645 Common characteristics of this deployment are 647 o The difference between subscriptions to presentities in one system 648 vs. the other are completely arbitrary. Any one presentity is as 649 likely to be homed on one infrastructure as the other 651 o Active users are almost guaranteed of subscribing to many users in 652 the peer infrastructure 654 o The level of intersection of presentities is extremely high 656 The first table below provides the calculations without optimizations 657 the second table provides the calculations with optimization. Even 658 though the relatively conservative numbers are used, the amount of 659 messages is still very high even though optimization may cut the 660 traffic by more then half 662 (A01) Subscription lifetime (hours)..............................8 663 (A02) Presence state changes / hour..............................3 664 (A03) Subscription refresh interval / hour.......................1 665 (A04) Total federated presentities per watcher..................10 666 (A05) Number of dialogs to maintain per watcher.................10 667 (A06) Number of watchers in a federated presence domain.....60,000 669 (A07) Initial SUBSCRIBE/200 per watcher.........................20 670 (A08) Initial NOTIFY/200 per watcher............................20 671 (A09) Total initial messages.............................2,400,000 673 (A10) NOTIFY/200 per watched presentity........................480 674 (A11) SUBSCRIBE/200 refreshes..................................160 675 (A12) NOTIFY/200 due to subscribe refresh......................160 676 (A13) Number of steady state messages...................48,400,000 678 (A14) SUBSCRIBE termination.....................................20 679 (A15) NOTIFY terminated.........................................20 680 (A16) Number of sign-out messages........................2,400,000 682 (A17) Total messages between domains...................105,600,000 683 (A18) Total number of messages / second......................3,667 684 (A19) Total number of bytes / second on the wire...........3,683KB 686 Figure 7: Inter-domain peering with no optimizations 688 (A01) Subscription lifetime (hours)..............................8 689 (A02) Presence state changes / hour..............................3 690 (A03) Subscription refresh interval / hour.......................1 691 (A04) Total federated presentities per watcher..................10 692 (A05) Number of dialogs to maintain per watcher..................1 693 (A06) Number of watchers in a federated presence domain.....60,000 695 (A07) Initial SUBSCRIBE/200 per watcher..........................2 696 (A08) Initial NOTIFY/200 per watcher.............................2 697 (A09) Total initial messages...............................240,000 699 (A10) NOTIFY/200 per watched presentity........................480 700 (A11) SUBSCRIBE refreshes.......................................16 701 (A12) NOTIFY/200 due to subscribe refresh........................0 702 (A13) Number of steady state messages...................29,760,000 704 (A14) SUBSCRIBE termination......................................2 705 (A15) NOTIFY terminated..........................................2 706 (A16) Number of sign-out messages..........................240,000 708 (A17) Total messages between domains....................60,480,000 709 (A18) Total number of messages / second......................2,100 710 (A19) Total number of bytes / second on the wire...........1,675KB 712 Figure 8: Inter-domain peering with optimizations 714 4. Resource List Service 716 RFC [12] defines a way to subscribe on a single URI while that URI is 717 actually a list of resources that are being subscribed to by a single 718 subscription. Although this is quite useful mechanism and it 719 significantly saves on the number of sessions between the watcher and 720 the presence server (as we show in the calculations of messages), 721 this feature has the potential to make the scalability issue of 722 presence systems harder and more complex. 724 The reasons that resource lists may make the scalability problem of 725 the presence server even more complex are: 727 o Subscriptions and state - The resource list may contain reference 728 to many other presence servers in many other domains. This 729 requires the RLS to create subscriptions to other presence servers 730 and buffer the state of all presentities in order to be able to 731 provide the full state of the presentities in the list when 732 needed. So in the overall system, the subscriptions that were 733 saved between the watcher and the presence server are moved to the 734 backend system while state has been duplicated between the various 735 presence servers that serve the various presentities and the RLSs. 736 This issue could have been mitigated if there was a way for the 737 RLS to retrieve the presence information for many watchers while 738 adhering to privacy when sending the actual notifications to the 739 watchers. 741 o Interlinkage - The resource list subscription will reach one RLS 742 that will open it and send it to many presence servers and to 743 other RLSs (if there is a subgroup inside the list). This way a 744 complex linkage between the state of many components is created. 745 This linkage makes state management and other maintenance of a 746 presence systems quite complex. 748 o Big lists are easy - There are two types of groups that may be 749 used with this feature, private groups that are defined by/for 750 each watcher and public groups that are defined in the system and 751 can be used by any watcher. Although we should expect IT 752 administrators to take caution when creating public groups, this 753 may be not the case in real life. The connection between the size 754 of the public group and the load on the presence server system may 755 not apparent to everyone. Furthermore many public groups that are 756 used in presence systems may have been created for other purposes 757 as email systems (where the size of the lists was not so 758 important) and are taken as they are to presence systems. So for 759 example we may very easily find that a public group that actually 760 covers all the users in the enterprise are used by many users in 761 the enterprise thus creating unbearable load on the presence 762 server. Note that this issue is not a protocol or design issue 763 but more a usage issue that may have a real impact on the presence 764 system. 766 o Stopping notifications - A watcher may accidentally subscribe to a 767 very big list and be overwhelmed by the amount of notifies that it 768 receives from the presence server. There is no current way to 769 stop this stream of notifies and even canceling the subscription 770 may take time until being affective. 772 The issues mentioned above are one example of an optimization that 773 helps in one part of the system but creates even bigger problems in 774 the overall system. There is a need to think about the problems 775 listed above but more then that there is a need to make sure that 776 when an optimization is introduced it does not create issues in other 777 places. 779 5. State Management 781 In previous section we have discussed the big amount of messages that 782 need to be sent to/from a presence server In this section the state 783 that needs to be maintained by a presence server will be analysed and 784 shown to be far from trivial. 786 The presence server has two parallel tasks. 788 1. Maintain the state of the presentities to which watchers 789 subscribe. 791 2. Maintain the state of the subscriptions of watchers and provide 792 timely updates to the watchers. 794 For a single subscription from a single watcher on a presentity, the 795 presence server has to maintain the following state: 797 o Subscription state including all the parameters that are needed in 798 order to maintain the subscription as timers. 800 o Optional filtering information that was requested by the watcher. 801 This includes enough information that is needed for doing the 802 filtering. In addition additional information has to be 803 maintained if partial notification is being supported for the 804 subscription 806 o Optional rate management information as throttling 808 o Watcher information [5], [7] that is the result of the 809 subscription in order to enable watched presentities to see who is 810 watching them. 812 For each presentity that has been subscribed to in the presence 813 server, the presence server has to maintain the following state: 815 o A list of the subscriptions for the presentity. Note that this is 816 already taken care of from the size calculation point of view by 817 the subscription state above. 819 o Privacy information for the presentity. 821 For each presentity for which there was any publication and the 822 presentity has a state other then a default value, the presence 823 server has to maintain the current value of the presentity. 825 5.1. State Size Calculations 827 Lets assume the following sizes: 829 o Subscription size - 2K bytes. This includes watcher information 830 that need to be created by the presence server for each 831 subscription. 833 o Subscribed to resource - 1K bytes (for privacy information and 834 other management info). The subscriptions themselves are already 835 calculated in the previous bullet. 837 o Resource with a state - 6K bytes. This is a moderate assumption 838 if we take into account the amount of data that is being put in a 839 presence document as multiple devices, calendar and geographical 840 information. 842 5.1.1. Tiny System 844 o 10K subscriptions = 19M bytes. 846 o 5K subscribed to presentities = 5M bytes. 848 o 10K presentities with state = 58M bytes. 850 Total is 82M bytes. 852 5.1.2. Medium System 854 o 100K subscriptions = 195M bytes. 856 o 50K subscribed to presentities = 49M bytes. 858 o 100K presentities with state = 586M bytes. 860 Total is 830M bytes. 862 5.1.3. Large System 864 o 6M subscriptions = 11,718M bytes. 866 o 3M subscribed to presentities = 2,929M bytes. 868 o 4M presentities with state = 23437M bytes. 870 Total is 38G bytes. 872 5.1.4. Very Large System 874 o 150M subscriptions = 292,969M bytes. 876 o 75M subscribed to presentities = 73,242M bytes. 878 o 100M presentities with state = 585,937M bytes. 880 Total is 952G bytes which is a very big number for a very dynamic 881 storage as needed by the presence server. 883 Although the numbers above may seem moderate enough for the sizes 884 that the presence server is handling we should consider the 885 following: 887 o Dynamic state - Although the state may seem not so big for 888 databases even for the very large system, we need to remember that 889 this state is a very dynamic state. Subscriptions come and go all 890 the time, the status of presentities is being updated and so 891 forth. This means that the presence server has to manage its 892 state in a medium that is very dynamic and for such large sizes 893 this task is not trivial. 895 o Interlinked state - The subscriptions and the subscribed to 896 presentities are dependent on each other. There need to be a link 897 from the presentity to the subscriptions and vice versa. See 898 section Section 4 about the interlinkage that is created due to 899 resource lists. 901 o Moderate assumptions - The size assumptions that were made above 902 are quite moderate. As presence is becoming more a core 903 middleware functionality that holds a lot of data on the user. In 904 real-life the numbers above may be even higher and the presence 905 server can have additional overhead as managing the SIP sessions, 906 networking and more. 908 Although the calculations above do not show that there is a real 909 issue with state management of presence in medium systems or even in 910 big systems since it should be possible to divide the state between 911 different machines, the state size is still very big. A bigger issue 912 with the state is more when resource lists are involved and create an 913 interlinked state between many servers. In that case the division of 914 very big state to multiple servers becomes less trivial... 916 6. Processing complexities 918 The basic presence paradigm consists from a watcher and a presentity 919 to which the watcher watches. It sounds simple enough but there are 920 many additions and extensions that the presence server has to manage 921 that make the processing of the presence server very complex. 923 In this section we show that in addition to the large amount of 924 messages and the big state that the presence server has to handle, it 925 has also to handle quite intensive processing for aggregation, 926 partial notify and publish, filtering and privacy. This adds another 927 complexity to the presence server in the CPU front in addition to the 928 network and memory fronts that were described before. 930 6.1. Aggregation 932 A presence document may contain multiple resources. These resources 933 can be devices of the presentity, information that is received form 934 external providers of presence information for the presentity as 935 geographical and calendar information and more. 937 The presence server needs to be able to get the updates from all the 938 resources and aggregate them correctly into a single presence 939 document. Although this is just "XML processing" task, the amount of 940 updates that the presence server may get, the need to keep the 941 presence document aligned with its schema and the need to notify the 942 users as soon as possible create a significant processing burden on 943 the presence server 945 6.2. Partial Publish and Notify 947 Drafts [13], [14] define a way for the watcher to request getting 948 only what was changed in the presence document and for the publisher 949 of presence information to publish only what was changed in the 950 presence document since the last publish. Although these 951 optimizations help in reducing the amount of the data that is sent 952 from/to the presence server, these optimizations create additional 953 processing burden on the presence server. 955 When a partial publish is arriving to the presence server, the 956 presence server has to be able to process the partial publish, change 957 only what is indicated in the partial publish while keeping the 958 presence document in a well formed shape according to the schema. 960 In partial notify the processing is even more complex since each 961 watcher needs to get the partial update based on the last update that 962 was received by that watcher. Therefore [13] specifies a versioning 963 mechanism that enables the watcher to get the updates based on the 964 previous state that it has seen. This versioning mechanism has to be 965 maintained by the presence server for each watcher that is subscribed 966 to a presentity and requires partial notify. 968 6.3. Filtering 970 Filtering as defined in RFCs [10], [11] enables a watcher to request 971 to be notified only when the presence document fulfills certain 972 conditions. Although this is a very convenient feature for watchers, 973 the burden that is put on the presence server is quite big. For each 974 change in the presence document, the presence server needs to compute 975 the filtering expressions which can be very complex, decide whether 976 and what to send to the watcher that have requested filtering. 978 6.4. Privacy 980 Draft [15] defines presence authorization rules that can be used by 981 presentities to define who can see what from their presence 982 documents. The processing that the presence server has to do here is 983 very similar to filtering. When there is a change to any presence 984 document that has privacy defined for it, the presence server needs 985 to create different notification for different watchers according to 986 what is defined in the authorization rules. 988 7. Possible Optimizations 990 This section contains techniques which can be employed by the 991 presence server and clients to reduce presence traffic, specifically, 992 on inter-domain links. Several techniques proposed and briefly 993 described here. The quantitative analysis of these techniques is not 994 fully done yet and will be present in a future version of this 995 document. Protocol mechanisms to employ these techniques are 996 described briefly. This section is intended to help us evaluate and 997 decide if such techniques should become a part of SIMPLE protocol 998 suite. 1000 7.1. Common NOTIFY for multiple watchers 1002 When multiple watchers from a domain (for example, domain B) 1003 SUBSCRIBE to a presentity in another domain (for example, domain A), 1004 a single NOTIFY [2] per presentity in domain B can be sent to domain 1005 B's presence server (PS). The presence server in domain B can then 1006 distribute the NOTIFY messages to each of the watchers. This 1007 eliminates the need to send individual NOTIFY messages from domain 1008 A's presence server to each watcher in domain B. The presence server 1009 and resource list server (RLS) are assumed to be co--located as a 1010 result of which NOTIFY messages are sent to presence server (RLS) in 1011 domain B rather then delivered directly to the watchers of domain B. 1013 The server distributes the NOTIFY message to a list of watchers based 1014 on a single NOTIFY message received from another presence agent. 1015 There are three main issues namely, privacy filtering, failure 1016 aggregation and transfer of watcher list to watcher's domain presence 1017 server to distribute NOTIFY. We discuss these in next subsections. 1019 7.1.1. Privacy filtering 1021 Privacy filtering is typically done by presentity's presence server. 1022 We propose that presentity's privacy filtering task be handled by 1023 watcher domain's presence server, in this case domain B's presence 1024 server. There are two possibilities about privacy filtering rules of 1025 the presentity as described below. 1027 Per domain privacy filters: Presentity in domain A having same 1028 privacy filter rules for all the watchers in domain B. In other 1029 words, there is a domain level privacy filter specified by the 1030 presentity for users from domain B. Privacy filtering can be done by 1031 the presence server in domain A and a single NOTIFY can be sent from 1032 presence server in domain B. 1034 Per watcher privacy filters: Presentity in domain A has different 1035 privacy filter rules for different watchers in domain B. Since, 1036 presentity in domain A has different privacy filtering rules for 1037 watchers from domain B, the privacy filter has to be applied by the 1038 presence server in domain B. Complete presence state information 1039 needs to be sent from the presentity's domain to watcher's domain. 1041 Delegating the task of privacy filtering doesn't compromise any 1042 additional privacy information when compared with normal operations. 1043 The model is very similar to e-mail trust model. Transfer of a 1044 single NOTIFY from presentity's domain to watcher's domain implies 1045 that the presence server in watcher's domain receives that 1046 information and can potentially distribute it to unauthorized 1047 watchers. Thus, presentity implicitly trusts the presence server in 1048 its own domain as well as watcher's domain. The proposed mechanism 1049 extends such a trust to the presence server in domain B so that it 1050 performs the privacy filtering on behalf of presentity in domain A. 1051 One potential issue is when presence server in domain A encrypts the 1052 presence document for each watcher using SMIME in which case the 1053 watcher domain PS cannot perform privacy filtering. Hence, this kind 1054 of privacy filtering requires a layer 8 security negotiation between 1055 the presence servers of the two domains 1057 7.1.2. NOTIFY failure aggregation 1059 The success or failure of NOTIFY message by the server changes the 1060 subscription status of the watcher on the presentity's presence 1061 server. Hence, to update about failure of NOTIFY delivery, domain 1062 B's presence server aggregates the success and failure responses for 1063 each watcher and send it to the presence server in domain A. 1064 Alternatively, application level negative acknowledgement can be 1065 used. 1067 7.1.3. Transferring the watcher list 1069 In order to distribute the NOTIFY message received from domain A, the 1070 watcher domain presence server requires the list of watchers in its 1071 domain for that presentity. We propose the following ways to achieve 1072 this. 1074 o Watcher list sent in NOTIFY message: The watcher list can be sent 1075 from domain A's presence server to domain B's presence server in 1076 each NOTIFY message. The NOTIFY is then distributed to each 1077 watcher in the list. This has a disadvantage when the number of 1078 watcher's from domain B is very large, every NOTIFY message 1079 increases in size proportionately. An alternative could be 1080 sending the complete list initially and sending changes to the 1081 list using the XML-patch operations [16] specified in partial- 1082 publication and maintaining the list on presence server in domain 1083 B. Sending watcher- list and distributing it, is similar to multi 1084 recipient messages i.e., [19], and SUBSCRIBE contained list or 1085 Exploders. 1087 o Watcher list obtained by subscribing to WINFO [5]package: In this 1088 technique, the watcher's domain (domain B) presence server obtains 1089 the watcher list from domain A's PS. It also receives any changes 1090 to the watcher-list from domain A's PS by subscribing to the 1091 presentity with presence.winfo event package. The domain A's PS 1092 maintains and updates the watcher list as a part of its normal 1093 operation. The updates are sent whenever watcher list changes. 1094 They contain information about watchers from domain B only. 1096 o Watcher list created on subscriber's presence server: The watcher 1097 domain presence server maintains and updates the list of watchers 1098 per presentity based on the SUBSCRIBE requests from these 1099 watchers. Such a list is like a resource list of watchers per 1100 presentity in watcher's domain built dynamically based on 1101 SUBSCRIBE request which are not directly sent to presentity's PS. 1103 7.1.4. Message flow example 1105 Below is the message flow diagram of how the system may work. 1107 Watchers Domain B Domain A Presentity 1108 (userB1, B2) (PS + RLS) (PS + RLS) (userA1, A2) 1109 ----------------------------------------------------------- 1110 1 | SUBSCRIBE t:userA1 | | | 1111 2 |--------------------->| | | 1112 3 | f:userB1) | SUBSCRIBE | | 1113 4 |<-------200OK---------|------------------>| | 1114 5 | |<-----200OK -------| | 1115 6 | | | | 1116 7 | | NOTIFY | | 1117 8 | |<------------------| | 1118 9 | NOTIFY (f:userA1 |------200OK------->| | 1119 10 |<---------------------| | | 1120 11 | t:userB1) | | | 1121 12 |---------200 OK------>| XCAP Filter B1 | | 1122 13 | |<-----------------<| | 1123 14 | | | | 1124 15 | SUBSCRIBE t:userA1 | | | 1125 16 |--------------------->| SUBSCRIBE | | 1126 17 | f:userB2) |------------------>| | 1127 18 |<-------200OK---------|<-----200OK -------| | 1128 19 | | | | 1129 20 | | NOTIFY | | 1130 21 | NOTIFY (f:userA1 |<------------------| | 1131 22 |<---------------------|------200OK------->| | 1132 23 | t:userB2) | | | 1133 24 |---------200 OK------>| XCAP Filter B2 | | 1134 25 | |<-----------------<| PUBLISH | 1135 26 | | |<-------------| 1136 27 | | |------200OK ->| 1137 28 | | NOTIFY (f:userA1 | | 1138 29 | |<------------------| | 1139 30 | | t: userB1, UserB2)| | 1140 31 | NOTIFY (f:userA1 |------200OK------->| | 1141 32 |<---------------------| | | 1142 33 | t:userB1) | | | 1143 34 |---------200 OK------>| | | 1144 35 | NOTIFY (f:userA1 | | | 1145 36 |<---------------------| | | 1146 37 | t:userB2) | | PUT XCAP | 1147 38 |---------200 OK------>| |<-------------| 1148 39 | | NOTIFY (filter) 1149 40 | |<------------------| | 1150 41 | |------200OK------->| | 1151 42 | | | | 1152 43 | | XCAP Filter B2 | | 1153 44 | |<-----------------<| | 1154 ----------------------------------------------------------- 1156 Figure 9: Example message flow for common NOTIFY for watchers in a 1157 domain 1159 We can see in figure above that a single NOTIFY from userA1@ 1160 domainA.com is sent to watchers {userB1, userB2}@domainB.com. Also, 1161 we can see that a change in privacy filter rule causes a NOTIFY which 1162 triggers an XCAP-based download of privacy filtering rules by domain 1163 B PS. 1165 7.1.5. SIP message examples for common NOTIFY 1167 The following NOTIFY message contains the list of watchers and the 1168 presence document of the presentity. The RLS /presence server in B 1169 will distribute it to all the watchers in the list. 1170 NOTIFY sip:rlserver.domainB.com SIP/2.0 1171 Via: SIP/2.0/TCP rlsserver.domainA.com;branch=z9hG4bK4EPlfSFQK1 1172 Max-Forwards: 70 1173 From: ;tag=zpNctbZq 1174 To: ;tag=ie4hbb8t 1175 Call-ID: cdB34qLToC@domainA.com 1176 CSeq: 997935769 NOTIFY 1177 Contact: 1178 Event: presence 1179 Subscription-State: active;expires=7200 1180 Content-Type: multipart/related;type="resource-lists+xml"; 1181 start="<2BEI83@rlsserver.domainA.com >"; 1182 boundary=" tuLLl3lDyPZX0GMr2YOo " 1183 Content-Length: 2014 1185 --tuLLl3lDyPZX0GMr2YOo 1186 Content-Transfer-Encoding: binary 1187 Content-ID: <2BEI83@rlsserver.domainA. com> 1188 Content-Type: application/resource-lists+xml; charset="UTF-8" 1189 1190 1192 1193 1194 1195 1196 1198 --tuLLl3lDyPZX0GMr2YOo 1199 Content-Transfer-Encoding: binary 1200 Content-ID: <2BEI83@rlsserver.domainA.example.com > 1201 Content-Type:type="application/pidf+xml;charset="UTF-8" 1202 start=""; 1203 boundary=" TfZxoxgAvLqgj4wRWPDL" 1205 --TfZxoxgAvLqgj4wRWPDL 1207 1208 1210 1211 1212 closed 1213 1214 1215 1217 --TfZxoxgAvLqgj4wRWPDL-- 1219 Figure 10: SIP message examples using common notify technique 1221 7.2. Aggregation of NOTIFY messages (Batched notification) 1223 When a watcher from a domain (for example domain B) SUBSCRIBE to 1224 multiple presentities in another domain (domain A), domain A's 1225 presence server can aggregate the notification messages and send them 1226 together as a single NOTIFY message to the presence server in domain 1227 B. The presence server in domain B can then deliver the message to 1228 the watcher or create individual NOTIFY messages for different 1229 watchers and send it to them. This reduces the number of NOTIFY/ 200 1230 OK messages on the inter-domain link as well as access network. This 1231 aggregation of NOTIFY can be done on per watcher or per domain basis. 1232 The RLS specification describes aggregation and throttling however, 1233 leaves it open to the implementers. 1235 One problem in aggregation is that presence status update for 1236 presentities may not occur simultaneously. Hence, in order to bundle 1237 the NOTIFY messages for each watcher or domain, the presence server 1238 may have to delay some of the NOTIFY messages. One approach to solve 1239 this issue could be that the watcher specifies a tolerable delay for 1240 receiving presence state update of the presentities. The watcher can 1241 specify this delay value using the watcher filtering mechanism or a 1242 SIP-header extension in the SUBSCRIBE message. The presence server 1243 in presentity's domain can hold the NOTIFY message only for the 1244 amount of time specified. 1246 7.2.1. Extracting and sending individual NOTIFY using Aggregated NOTIFY 1247 message body 1249 The aggregation of NOTIFY bodies originating from different 1250 presentities to a single NOTIFY body works on the basis of Multipart 1251 (MIME). Bundling of notification imply aggregating multiple NOTIFY 1252 bodies destined to a single watcher (or watcher domain) into a single 1253 NOTIFY and delivered to watcher domain presence server. If all the 1254 NOTIFY messages are destined to a single watcher, the watcher domain 1255 presence server delivers the message directly. Otherwise, the server 1256 extracts multiple presence bodies (PIDF) from the received NOTIFY 1257 message. Each presence document (PIDF [6]) contains an entity field 1258 which uniquely identifies the presentity; hence, there is no 1259 dependency on SIP headers to construct individual NOTIFY messages for 1260 delivering them to watchers. Delivering bundled NOTIFY messages 1261 reduces the traffic on access network as well. 1263 7.2.2. Subscription termination and failure indication in NOTIFY 1264 delivery 1266 The Subscription-state header in the NOTIFY message is used to 1267 indicate subscription termination to a watcher. Bundled notification 1268 doesn't indicate subscription termination, hence, terminating NOTIFY 1269 messages cannot be sent using this mechanism. Additionally, the 1270 notifier needs to know if the NOTIFY was delivered successfully or 1271 not. The subscription can be terminated if NOTIFY is not delivered 1272 successfully. The presence server in domain B should aggregate and 1273 send to PS in domain A the success or failure of NOTIFY messages. 1274 The advantage is observed when a single watcher subscribes to 1275 multiple presentities from another domain. The delay tolerance 1276 interval specified by the watcher should be good enough so that 1277 multiple NOTIFY messages can be bundled or aggregated. The reduction 1278 in traffic can be seen under two scenarios, i.e., (i) when watcher 1279 logs in and subscribes to all the presentities. The NOTIFY from 1280 multiple presentities can be bundled and delivered as a single 1281 message to the watcher. (ii) In steady state, the gain can be 1282 calculated based on the delay tolerance interval, number of 1283 presentities to which a watcher is subscribed, probability of these 1284 presentities changing state in that interval. With increase in 1285 number of presentities, the probability that presentities will update 1286 presence state within a time difference of delay tolerance interval 1287 will increase and hence the inter domain traffic reduction (gain) 1288 will increase. 1290 7.2.3. Message flow example 1292 The message flow diagram in Figure below assumes watchers in domain B 1293 (userB1, userB2) and presentities in domain A (userA1, userA2). We 1294 can see that when userA1 and userA2 send PUBLISH, a single NOTIFY is 1295 sent from domain A to domain B, which is converted to individual 1296 NOTIFY messages by presence server at domain B. 1298 Watchers Domain B Domain A Presentity 1299 (userB1,B2) (PS + RLS) (PS + RLS) (userA1,A2) 1300 ----------------------------------------------------------- 1301 1 | SUBSCRIBE t:userA1 | | | 1302 2 |--------------------->| | | 1303 3 | f:userB1) | | | 1304 4 |<-------200OK---------| SUBSCRIBE | | 1305 5 | |------------------>| | 1306 6 | |<-----200OK -------| | 1307 7 | | | | 1308 8 | | NOTIFY | | 1309 9 | |<------------------| | 1310 10 | NOTIFY (f:userA1 |------200OK------->| | 1311 11 |<---------------------| | | 1312 12 | t:userB1) | | | 1313 13 |---------200 OK------>| | | 1314 14 | | | | 1315 15 | | | | 1316 16 | SUBSCRIBE t:userA2 | | | 1317 17 |--------------------->| SUBSCRIBE | | 1318 18 | f:userB1) |------------------>| | 1319 19 |<-------200OK---------|<-----200OK -------| | 1320 20 | | | | 1321 21 | | NOTIFY | | 1322 22 | NOTIFY (f:userA2 |<------------------| | 1323 23 |<---------------------|------200OK------->| | 1324 24 | t:userB1) | | | 1325 25 |---------200 OK------>| | PUBLISH | 1326 26 | | userA1|<-------------| 1327 27 | | |------200OK ->| 1328 28 | | | | 1329 29 | | | PUBLISH | 1330 30 | | userA2|<-------------| 1331 31 | | |------200OK ->| 1332 32 | | | | 1333 33 | | NOTIFY (multipart)| | 1334 34 | |<------------------| | 1335 35 | NOTIFY (f:userA1 | (userA1,userA2) | | 1336 36 |<---------------------|------200OK------->| | 1337 37 | t:userB1) | | | 1338 38 |---------200 OK------>| | | 1339 39 | | | | 1340 40 | | | | 1341 41 | NOTIFY (f:userA1 | | | 1342 42 |<---------------------| | | 1343 43 | t:userB1) | | | 1344 44 |---------200 OK------>| | | 1345 ----------------------------------------------------------- 1347 Figure 11: Message flow for aggregation or batched notification 1349 7.2.4. SIP message flow example for batched notification 1351 The following NOTIFY message contains presence documents of multiple 1352 presentities. In the example, all the presence documents are 1353 destined to a single watcher. 1355 NOTIFY sip:rlserver.domainB.com SIP/2.0 1356 Via: SIP/2.0/TCP rlsserver.domainA.example.com;branch=z9hG4bK4EPlfSFQK1 1357 Max-Forwards: 70 1358 From: ;tag=zpNctbZq 1359 To: ;tag=ie4hbb8t 1360 Call-ID: cdB34qLToC@ domainA.com 1361 CSeq: 997935769 NOTIFY 1362 Contact: 1363 Event: presence 1364 Subscription-State: active;expires=7200 1365 Content-Type: multipart/related;type="rlmi+xml"; 1366 start="<2BEI83@rlsserver.domainB.example.com >"; 1367 boundary=" tuLLl3lDyPZX0GMr2YOo " 1368 Content-Length: 2862 1370 --tuLLl3lDyPZX0GMr2YOo 1371 Content-Transfer-Encoding: binary 1372 Content-ID: <2BEI83@rlsserver.domainB.example.com> 1373 Content-Type: application/pidf+xml;charset="UTF-8" 1375 1376 1378 1379 1380 open 1381 1382 sip:joe@stockholm.example.org 1383 1384 1386 --tuLLl3lDyPZX0GMr2YOo 1387 Content-Transfer-Encoding: binary 1388 Content-ID: 1389 Content-Type: application/pidf+xml;charset="UTF-8" 1391 1392 1394 1395 1396 closed 1397 1398 1399 1400 --tuLLl3lDyPZX0GMr2YOo-- 1402 Figure 12: Message Flow for Aggregation or Batched Notification 1404 7.3. Timed presence 1406 Watchers may be interested in general, coarse-grained availability 1407 information of certain presentities rather then getting notification 1408 for every status change of the presentity. For example, a manager 1409 may be interested in knowing if the employees under him are available 1410 or on vacation (calendar/timed-presence) rather then getting 1411 notification about every status change. This can be achieved using 1412 timed-presence [8]. An example of Timed-presence status is below: 1414 1417 1418 1419 open 1420 1421 1423 closed 1424 1425 sip:Vishal@cs.columbia.edu 1426 1427 I'll be in San Diego IETF meeting 1428 1430 Figure 13: Time-presence status example 1432 Thus, timed-presence can be used to automatically switch the 1433 subscription on or off which can lower the presence notification 1434 traffic. However, with current watcher filtering specification it is 1435 not straightforward to automatically enable or disable notifications 1436 based on calendar information from timed-presence. Watchers cannot 1437 specify a watcher filter indicating not to send NOTIFY based on 1438 timed-status as it would require them to know the 'from'/'until' 1439 attribute in before hand. Watcher filtering 1440 specification does not allow watchers to specify filter rules to 1441 disable notifications based on comparison of timestamps. A watcher 1442 application upon obtaining the can specify a watcher 1443 filter using the 'from' and 'until' attribute in the received , indicating the server not to send a NOTIFY unless the 1445 or 'from' or 'until' attribute changes. A watcher 1446 should not blindly un-subscribe for the time specified in the because presentity may update the time-status and watcher may 1448 not be aware of this. Hence, watcher must specify a watcher filter 1449 which triggers a notification upon changes in elements of , after it has received the first . Once the 1451 interval for the received is over, the watcher 1452 application removes the filter and starts receiving notifications in 1453 a normal manner. However, differential notification can be used to 1454 know about changes in the timed-presence. From the above discussion, 1455 it is clear that watcher filtering specification requires 1456 enhancements for timestamp based watcher filters. 1458 7.4. On-Demand presence (Fetch or Pull Model) 1460 Watchers need not be notified about every presence update of all the 1461 contacts at all times. Watchers may be interested in regularly 1462 receiving presence updates for some of their contacts. But for other 1463 contacts, watchers may only want to know their presence information 1464 when they want to start a communication session. This can be labeled 1465 as on-demand presence and can be accomplished by using fetch based 1466 SUBSCRIBE with expiration interval set to zero. This approach 1467 requires a mechanism in the watcher application to enable watchers to 1468 indicate that they are not interested in regular presence updates, 1469 rather they only require presence information when starting a new 1470 session. Examples may include services, where presence status does 1471 not have to be seen or known to a watcher all of the time. For 1472 example, a cell-phone associated watcher may need presence updates 1473 only when the cell-phone application (e.g., phone book) runs in the 1474 foreground on the device. Another example is a presence-based call 1475 routing in telephony, where - before the call is delivered - a 1476 watcher issues a fetch-based SUBSCRIBE to learn whether and where the 1477 callee is available. 1479 7.5. Adapting the subscription rate 1481 The rate of notification can be adjusted based on statistical 1482 information about past multimedia sessions with user's contacts. 1483 This can be initiated by the client or can be automatically done by 1484 the server as server can procure such information based on stored 1485 call and text session information. As a matter of fact, 60-70% of 1486 the calls/IM messages are sent to 20% of the contacts [Reference 1487 required, Observation based on call detail records of friends]. 1488 Nearly 50% of the buddies are called rarely. This may include 1489 buddies from old office, old college, and old city who are present in 1490 the buddy list but are not contacted actively. Based on such 1491 information the presence server or the client can adapt the 1492 subscription rate and use the fetch model for such buddies. 1494 7.6. Other Optimizations 1496 This section lists and discusses several other optimizations either 1497 are already part of the SIMPLE protocol or they have been suggested 1498 in various drafts. the current protocol optimizations that have been 1499 defined, are being worked on or are suggested. 1501 o Subnot-etags - Draft [20]. This draft suggests ways to suppress 1502 the sending of unnecessary notifies when for example a 1503 subscription is refreshed. This suggestion seems to be an 1504 efficient optimization since it saves both the number of messages 1505 sent and on the processing time of the presence server. 1507 o Resource List Service - [12] enable creating a single subscription 1508 session between the watcher and the presence server for 1509 subscribing on a list of users. This saves the amount of sessions 1510 that are created between watchers and presence servers. On the 1511 other hand, this mechanism enables creating very large amount of 1512 subscriptions in the presence server/RLS system thus enabling the 1513 creation of a very large number of subscriptions between presence 1514 servers and RLSs with relatively few clients especially if large 1515 public groups are used. It seems that in order to really optimize 1516 in this area, the usage of large public groups should not be 1517 considered as BCP and there should be a way for an RLS to create a 1518 single subscription for multiple occurrences of the same resource 1519 in resource lists. See consolidates subscriptions below. 1521 o Partial notify/publish - Drafts [13], [14] define a way for the 1522 subscriber to request getting only what was changed in the 1523 presence document and for the publisher of presence information to 1524 publish only what was changed in the presence document since the 1525 last publish. Although these optimizations help in reducing the 1526 amount of actual data that is sent from/to the presence server, 1527 these optimizations create additional processing burden on the 1528 presence server as was discussed above. 1530 o Filtering as defined in RFCs [10], [11] enables a watcher to 1531 request to be notified only when the presence document fulfills 1532 certain conditions. Although this optimization enables saving on 1533 the amount of messages that are sent from the presence server to 1534 the watcher, this optimization puts more burden on the processing 1535 time of the presence server as was discussed above. 1537 o Throttling 1538 [http://tools.ietf.org/html/draft-niemi-sipping-event-throttle-04 1539 - expired at the time of the writing of this document] defines a 1540 mechanism in which a watcher requires to be updated only in 1541 certain intervals. Although this mechanism may give some extra 1542 load on the processing time of the presence server, that load is 1543 negligible and the reduction on the amount of messages sent from 1544 the presence server to the watchers is significant. This 1545 optimization is even more important with resource lists where 1546 there can be many resources in the resource lists and if the 1547 traffic of updates on resource list is not regulated, the watcher 1548 may get very large amount of notifications. 1550 o Presence specific sigcomp dictionary [17] defines a SIGCOMP [3] 1551 dictionary for presence. This optimization will enable to reduce 1552 the number of bytes that are transferred in presence systems by 1553 compressing the textual SIP messages and using the specialized 1554 presence dictionary the compression may be more significant then 1555 just using SIGCOMP as is. Note that number of actual messages 1556 will remain the same and a calculation of the amount of bytes that 1557 will be saved may be useful here. 1559 o Content Indirection [9] enables sending only the URI of the 1560 presence document to the watcher thus offloading the presence 1561 server from sending the presence document to the watcher. This 1562 optimization may be useful in some cases but in reality it may 1563 have several drawbacks: 1565 1. Due to partial/privacy/filtering and other functionalities, it 1566 will be relatively a rare case where many watchers will get 1567 exactly the same presence document. 1569 2. There should be a mechanism that will enable removing the 1570 content from the content server at the appropriate time. 1571 Defining the appropriate time is far from trivial since the 1572 removal should be synchronized with all the watcher that need 1573 to get the content. 1575 o Resubscription to resource list [12] requires that a full state 1576 will be sent for subscribe refreshes. In large resource lists the 1577 amount of data that needs to be sent for each subscribe refresh 1578 may be very big. Having an optimization that will enable sending 1579 only partial information at subscribe refreshes may let RLS 1580 subscriptions be more optimized. 1582 o No Resubscriptions - Due to the nature of SIP that is network 1583 agnostic and always assumes the worst for the network layer, 1584 resubscriptions are part of the SIP sub/notify model [2]. In many 1585 cases it should be possible to negotiate a special connection 1586 between watchers and presence servers, this type of connection 1587 will use a different mechanism of e.g. keep alives and will not 1588 necessitate resubscribes. This will be mostly important between 1589 presence domains and between RLSs and presence servers and may 1590 save many messages. 1592 8. Extremely Optimized Model 1594 The following calculations are made assuming that the following 1595 optimizations are deployed: 1597 o No resubscriptions are necessary. 1599 o Consolidates Subscriptions are possible. 1601 The following table shows the amount of messages that are required in 1602 this model using the very large network model numbers. We assume 1603 that even though there are 10M watchers from one domain to the other, 1604 the number of actually watched resources is only 3M. 1606 (A01) Subscription lifetime (hours)..............................8 1607 (A02) Presence state changes / hour..............................6 1608 (A03) Subscription refresh interval / hour.......................0 1609 (A04) Total federated presentities per watcher..................10 1610 (A05) Number of dialogs to maintain per watcher..................1 1611 (A06) Number of watchers in a federated presence domain.10,000,000 1612 (A06-1) Number of resources watched......................3,000,000 1614 (A07) Initial SUBSCRIBE/200 per watcher..........................2 1615 (A08) Initial NOTIFY/200 per watcher.............................2 1616 (A09) Total initial messages............................12,000,000 1618 (A10) NOTIFY/200 per watched presentity........................960 1619 (A11) SUBSCRIBE/200 refreshes....................................0 1620 (A12) NOTIFY/200 due to subscribe refresh........................0 1621 (A13) Number of steady state messages................2,880,000,000 1623 (A14) SUBSCRIBE termination......................................2 1624 (A15) NOTIFY terminated..........................................2 1625 (A16) Number of sign-out messages.......................12,000,000 1627 (A17) Total messages between domains.................5,808,000,000 1628 (A18) Total number of messages / second....................201,333 1629 (A19) Total number of bytes / second on the wire.........402,083KB 1631 Figure 14: Very large network peering with extreme optimizations 1633 Note that we get almost a 3 fold less messages by only assuming that 1634 10M watchers subscribe to 3M resources while consolidated 1635 subscriptions are possible. However, since the NOTIFY messages are 1636 big then the saving in the bandwidth is not so big. Due to the usage 1637 of the subnot-etags [20] optimization the total removal of 1638 resubscribes does not save many messages as the following table 1639 shows: 1641 (A01) Subscription lifetime (hours)..............................8 1642 (A02) Presence state changes / hour..............................6 1643 (A03) Subscription refresh interval / hour.......................1 1644 (A04) Total federated presentities per watcher..................10 1645 (A05) Number of dialogs to maintain per watcher..................1 1646 (A06) Number of watchers in a federated presence domain.10,000,000 1647 (A06-1) Number of resources watched......................3,000,000 1649 (A07) Initial SUBSCRIBE/200 per watcher..........................2 1650 (A08) Initial NOTIFY/200 per watcher.............................2 1651 (A09) Total initial messages............................12,000,000 1653 (A10) NOTIFY/200 per watched presentity........................960 1654 (A11) SUBSCRIBE/200 refreshes...................................16 1655 (A12) NOTIFY/200 due to subscribe refresh........................0 1656 (A13) Number of steady state messages................2,928,000,000 1658 (A14) SUBSCRIBE termination......................................2 1659 (A15) NOTIFY terminated..........................................2 1660 (A16) Number of sign-out messages.......................12,000,000 1662 (A17) Total messages between domains.................5,904,000,000 1663 (A18) Total number of messages / second....................205,000 1664 (A19) Total number of bytes / second on the wire.........402,088KB 1666 Figure 15: Very large network extreme optimizations+resubscribe 1668 "Only" additional 3.5K messages per second are needed if we re- 1669 introduce re-subscriptions, since the subnot-etags [20] optimization 1670 is used. 1672 Note that even other protocols that do not require subscription 1673 refreshes etc. will have "hard time" bettering the above scalability 1674 calculation 1676 9. Suggested Requirements 1678 In the previous sections we have shown several areas where the 1679 deployment of a presence system is far from being trivial, these 1680 include network load, memory load and CPU load. In this section we 1681 are listing an initial set of requirements to a possible 1682 optimizations in this area. 1684 Backward compatibility requirements 1686 o The solution should not hinder the ability of existing SIMPLE 1687 clients and/or servers from peering with a domain or client 1688 implementing the solution. No changes may be required of existing 1689 servers to interoperate 1691 o It does NOT constrain any existing RFC functional or security 1692 requirements for presence 1694 o Systems that are not using the new additions to the protocol 1695 should operate at the same level as they do today 1697 Policy, privacy, permissions requirements 1699 o The solution does not limit the ability for presentities to 1700 present different views of presence to different watchers 1702 o The solution does not restrict the ability of a presentity to 1703 obtain its list of watchers 1705 o The solution MUST NOT create any new or make worse any existing 1706 privacy holes 1708 Scalability requirements 1710 o It is highly desirable for any presence system (intra or inter- 1711 domain) to scale linearly as number of watchers and presentities 1712 increase linearly 1714 o The solution SHOULD NOT require significantly more state in order 1715 to implement the solution 1717 o It MUST be able to scale to tens of millions of concurrent users 1718 in each domain and in each peer domain 1720 o It MUST support a very high level of watcher/presentity 1721 intersections in various intersection models 1723 o Protocol changes MUST NOT prohibit optimizations in different 1724 deployment models esp. where there is a high level of cross 1725 subscriptions between the domains 1727 o New functionalities and extensions to the presence protocol SHOULD 1728 take into account scalability with respect to the number of 1729 messages, state size and management and processing load. 1731 Topology requirement 1733 o The solution SHOULD allow for arbitrary federation topologies 1734 including direct peering and intermediary routing 1736 10. Conclusions 1738 The document analysis the scalability of presence systems and of the 1739 SIP based in particular. It is apparent that the scalability of 1740 these systems is far from being trivial from several perspectives: 1741 number of messages, network bandwidth, state management and CPU load. 1743 Several optimizations are suggested or are surveyed in this document. 1744 It is important to note that not every optimization is really an 1745 optimization and some of them may seem to optimize in one place while 1746 they actually create load in other parts of the system. 1748 It is very possible that the issues that are described in this 1749 document are inherent to presence systems in general and not specific 1750 to the SIMPLE protocol. Organizations need to be prepared to invest 1751 a lot in network and hardware in order to create real big systems. 1752 However, it is apparent that not all the possible optimizations were 1753 done yet and further work is needed in the IETF in order to provide 1754 better scalability 1756 It seems that we need to think about the problem in a different way. 1757 We need to think about scalability as part of the protocol design. 1758 The IETF tends not to think about actual deployments when designing a 1759 protocol but in this case it seems that if we do not think about 1760 scalability with the protocol design it will not be very hard to 1761 scale. 1763 We should also consider whether using the same protocol between 1764 clients and servers and between servers is a good choice with this 1765 problem? It may be that in interdomain or even between servers in 1766 the same domain (as between RLSs and presence servers) there is a 1767 need to have a different protocol that will be very optimized for the 1768 load and can assume some assumptions about the network (e.g. do not 1769 use unreliable protocol as UDP but only TCP). 1771 Another issue that is more concerning protocol design is whether 1772 NOTIFY messages should not be considered as media as the audio, video 1773 and even text messaging are considered? The SUBSCRIBE can be 1774 extended to do similar three way handshake as INVITE and negotiate 1775 where the notify messages should go, rate and other parameters. This 1776 way the load can be offloaded to specialized NOTIFY "relays" thus not 1777 loading the control path of SIP. 1779 11. Security Considerations 1781 This document discusses scalability issues with the existing SIP/ 1782 SIMPLE presence protocol and model. Therefore, there are no security 1783 considerations to be considered for this document. However, a lot of 1784 the possible optimizations that are discussed in theory in this 1785 document will most probably have security implications that will need 1786 to be solved. 1788 12. Acknowledgments 1790 We would like to thank Jonathan Rosenberg (Cisco), Markus Isomaki 1791 (Nokia) Piotr Boni (Verizon), David Viamonte (Genaker) and Aki Niemi 1792 (Nokia) for their ideas and input. 1794 13. References 1796 13.1. Normative References 1798 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1799 Levels", BCP 14, RFC 2119, March 1997. 1801 13.2. Informational References 1803 [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 1804 Notification", RFC 3265, June 2002. 1806 [3] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, 1807 Z., and J. Rosenberg, "Signaling Compression (SigComp)", 1808 RFC 3320, January 2003. 1810 [4] Rosenberg, J., "A Presence Event Package for the Session 1811 Initiation Protocol (SIP)", RFC 3856, August 2004. 1813 [5] Rosenberg, J., "A Watcher Information Event Template-Package 1814 for the Session Initiation Protocol (SIP)", RFC 3857, 1815 August 2004. 1817 [6] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and 1818 J. Peterson, "Presence Information Data Format (PIDF)", 1819 RFC 3863, August 2004. 1821 [7] Rosenberg, J., "An Extensible Markup Language (XML) Based 1822 Format for Watcher Information", RFC 3858, August 2004. 1824 [8] Schulzrinne, H., "Timed Presence Extensions to the Presence 1825 Information Data Format (PIDF) to Indicate Status Information 1826 for Past and Future Time Intervals", RFC 4481, July 2006. 1828 [9] Burger, E., "A Mechanism for Content Indirection in Session 1829 Initiation Protocol (SIP) Messages", RFC 4483, May 2006. 1831 [10] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 1832 Requena, "Functional Description of Event Notification 1833 Filtering", RFC 4660, September 2006. 1835 [11] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 1836 Requena, "An Extensible Markup Language (XML)-Based Format for 1837 Event Notification Filtering", RFC 4661, September 2006. 1839 [12] Roach, A., Campbell, B., and J. Rosenberg, "A Session 1840 Initiation Protocol (SIP) Event Notification Extension for 1841 Resource Lists", RFC 4662, August 2006. 1843 [13] Lonnfors, M., "Session Initiation Protocol (SIP) extension for 1844 Partial Notification of Presence Information", 1845 draft-ietf-simple-partial-notify-08 (work in progress), 1846 July 2006. 1848 [14] Lonnfors, M., "Publication of Partial Presence Information", 1849 draft-ietf-simple-partial-publish-06 (work in progress), 1850 February 2007. 1852 [15] Rosenberg, J., "Presence Authorization Rules", 1853 draft-ietf-simple-presence-rules-08 (work in progress), 1854 October 2006. 1856 [16] Urpalainen, J., "An Extensible Markup Language (XML) Patch 1857 Operations Framework Utilizing XML Path Language (XPath) 1858 Selectors", draft-ietf-simple-xml-patch-ops-02 (work in 1859 progress), March 2006. 1861 [17] Garcia-Martin, M., "The Presence-specific Dictionary for the 1862 Signaling Compression (Sigcomp) Framework", 1863 draft-garcia-simple-presence-dictionary-01 (work in progress), 1864 December 2006. 1866 [18] Camarillo, G., "Subscriptions to Request-Contained Resource 1867 Lists in the Session Initiation Protocol (SIP)", 1868 draft-ietf-sipping-uri-list-subscribe-05 (work in progress), 1869 May 2006. 1871 [19] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE 1872 Requests in the Session Initiation Protocol (SIP)", 1873 draft-ietf-sip-uri-list-message-01 (work in progress), 1874 January 2007. 1876 [20] Niemi, A., "An Extension to Session Initiation Protocol (SIP) 1877 Events for Issuing Conditional Subscriptions", 1878 draft-niemi-sip-subnot-etags-02 (work in progress), 1879 October 2006. 1881 Authors' Addresses 1883 Avshalom Houri 1884 IBM 1885 Science Park Building 18/D 1886 Rehovot, 1887 Israel 1889 Email: avshalom@il.ibm.com 1891 Tim Rang 1892 Microsoft Corporation 1893 One Microsoft Way 1894 Redmond, WA 98052 1895 USA 1897 Email: timrang@microsoft.com 1899 Edwin Aoki 1900 AOL LLC 1901 360 W. Caribbean Drive 1902 Sunnyvale, CA 94089 1903 USA 1905 Email: aoki@aol.net 1907 Vishal Singh 1908 Columbia University 1909 Department of Computer Science 1910 450 Computer Science Building 1911 New York, NY 10027 1912 US 1914 Email: vs2140@cs.columbia.edu 1915 URI: http://www.cs.columbia.edu/~vs2140 1916 Henning Schulzrinne 1917 Columbia University 1918 Department of Computer Science 1919 450 Computer Science Building 1920 New York, NY 10027 1921 US 1923 Phone: +1 212 939 7004 1924 Email: hgs+ecrit@cs.columbia.edu 1925 URI: http://www.cs.columbia.edu/~hgs 1927 Full Copyright Statement 1929 Copyright (C) The IETF Trust (2007). 1931 This document is subject to the rights, licenses and restrictions 1932 contained in BCP 78, and except as set forth therein, the authors 1933 retain all their rights. 1935 This document and the information contained herein are provided on an 1936 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1937 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1938 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1939 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1940 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1941 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1943 Intellectual Property 1945 The IETF takes no position regarding the validity or scope of any 1946 Intellectual Property Rights or other rights that might be claimed to 1947 pertain to the implementation or use of the technology described in 1948 this document or the extent to which any license under such rights 1949 might or might not be available; nor does it represent that it has 1950 made any independent effort to identify any such rights. Information 1951 on the procedures with respect to rights in RFC documents can be 1952 found in BCP 78 and BCP 79. 1954 Copies of IPR disclosures made to the IETF Secretariat and any 1955 assurances of licenses to be made available, or the result of an 1956 attempt made to obtain a general license or permission for the use of 1957 such proprietary rights by implementers or users of this 1958 specification can be obtained from the IETF on-line IPR repository at 1959 http://www.ietf.org/ipr. 1961 The IETF invites any interested party to bring to its attention any 1962 copyrights, patents or patent applications, or other proprietary 1963 rights that may cover technology that may be required to implement 1964 this standard. Please address the information to the IETF at 1965 ietf-ipr@ietf.org. 1967 Acknowledgment 1969 Funding for the RFC Editor function is provided by the IETF 1970 Administrative Support Activity (IASA).