idnits 2.17.1 draft-ietf-sipping-presence-scaling-requirements-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 935. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 946. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 953. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 959. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2, 2008) is 5654 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-simple-interdomain-scaling-analysis-05 == Outdated reference: A later version (-05) exists of draft-ietf-simple-intradomain-federation-01 == Outdated reference: A later version (-09) exists of draft-ietf-simple-simple-04 == Outdated reference: A later version (-02) exists of draft-ietf-simple-view-sharing-01 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING WG A. Houri 3 Internet-Draft IBM 4 Intended status: Informational S. Parameswar 5 Expires: May 6, 2009 Microsoft Corporation 6 E. Aoki 7 AOL LLC 8 V. Singh 9 H. Schulzrinne 10 Columbia U. 11 November 2, 2008 13 Scaling Requirements for Presence in SIP/SIMPLE 14 draft-ietf-sipping-presence-scaling-requirements-02.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on May 6, 2009. 41 Abstract 43 The document provides a set of requirements for enabling interdomain 44 scaling in presence for SIP/SIMPLE. 46 Table of Contents 48 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 49 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2.1. Very large network peering . . . . . . . . . . . . . . . . 3 51 2.2. State Management . . . . . . . . . . . . . . . . . . . . . 8 52 2.2.1. State Size Calculations . . . . . . . . . . . . . . . 8 53 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10 54 3.1. Backward Compatibility Requirements . . . . . . . . . . . 10 55 3.2. Policy, Privacy, Permissions Requirements . . . . . . . . 11 56 3.3. Scalability Requirements . . . . . . . . . . . . . . . . . 11 57 3.4. Topology Requirements . . . . . . . . . . . . . . . . . . 12 58 4. Considerations for Possible Optimizations . . . . . . . . . . 12 59 4.1. Very Optimized SIP . . . . . . . . . . . . . . . . . . . . 13 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 62 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 64 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 65 8.2. Informational References . . . . . . . . . . . . . . . . . 19 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 67 Intellectual Property and Copyright Statements . . . . . . . . . . 22 69 1. Requirements notation 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in [RFC2119]. 75 2. Introduction 77 The document lists requirements for optimizations of the SIP/SIMPLE 78 protocol. See [I-D.ietf-simple-simple] for the list of RFCs and 79 drafts that are considered as part of the SIP/SIMPLE protocol. These 80 optimizations should reduce the load on the network and the presence 81 servers in interdomain presence subscriptions. The requirements are 82 based on a separate scaling analysis document 83 [I-D.ietf-simple-interdomain-scaling-analysis]. 85 The scaling analysis document have shown that there is much room for 86 optimizations in the SIP/SIMPLE protocol. The need for optimizations 87 is in the number of by teds that are sent between two federating 88 domains, the number of messages that need to be processed and the 89 amount of state that needs to be managed by the presence servers. 90 The following is a snaphot of various numbers from the scaling 91 analysis document. This snapshot is in clouded here for 92 completeness, please refer to the scaling analysis document for the 93 full details including the description of the calculations and the 94 various SIP optimizations investigated. 96 2.1. Very large network peering 98 In this environment, two or more very large networks create a peering 99 relationship allowing their users to subscribe to presence in the 100 other domains. Where as the number of users in other deployment 101 types ranges from hundreds to several hundred thousand, these large 102 networks host up to hundreds of millions of users. Examples of these 103 networks are large wireless carriers and consumer IM networks. 105 Common characteristics of this deployment are: 107 o As users become accustomed to network boundaries disappearing, 108 federated subscriptions become as common as subscriptions within 109 the same domain 110 o Individual users are highly likely to want to see presence of 111 multiple presentities in the peer network 112 o The intersection of users in the deployment watching the same 113 presentities is very high (i.e., two or more users in network A 114 are extremely likely to be watching a same user in network B) 116 o Status changes increase greatly due to typical observed consumer 117 behavior 119 The first table below provides the calculations without optimizations 120 the second table provides the calculations with optimizations. Even 121 though the optimizations help a lot (almost cut the number of 122 messages by half), the numbers are still very high. Note also that 123 the bandwidth required is very high. 125 ** Constants 126 (C01) Subscription lifetime (hours)...........................8 127 (C02) Presence state changes / hour...........................6 128 (C03) Subscription refresh interval / hour....................1 129 (C04) Total federated presentities per watcher...............10 130 (C05) Number of dialogs to maintain per watcher..............10 131 (C06) Total number of watchers in domains............20,000,000 132 (C07) SUBSCRIBE message size in bytes.......................450 133 (C08) 200 OK for SUBSCRIBE message size in bytes............370 134 (C09) NOTIFY message size not including presence doc........500 135 (C10) 200 OK for NOTIFY message size in bytes...............370 136 (C11) Size of an average presence document..................350 138 ** Initial Messages 139 (I01) Initial SUBSCRIBE msgs per watcher.....................10 140 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher............10 141 (I03) Initial NOTIFY msgs per watcher........................10 142 (I04) Initial 200 OK msgs (NOTIFY) per watcher...............10 143 (I05) Total number & bytes of initial SUBSCRIBE msgs 144 Number of msgs for all watchers...........200,000,000 145 Bytes for all watchers.................90,000,000,000 146 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 147 Number of msgs for all watchers...........200,000,000 148 Bytes for all watchers.................74,000,000,000 149 (I07) Total number & bytes of initial NOTIFY msgs 150 Number of msgs for all watchers...........200,000,000 151 Bytes for all watchers................170,000,000,000 152 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 153 Number of msgs for all watchers...........200,000,000 154 Bytes for all watchers.................74,000,000,000 155 (I09) Total number & bytes of initial messages per day 156 Number of msgs for all watchers...........800,000,000 157 Bytes for all watchers................408,000,000,000 159 ** Steady State Messages 160 (S01) NOTIFY msgs due to state change 161 per watched presentity per day.....................46 162 (S02) 200 (for NOTIFY due to state change) msgs 163 per watched presentity per day.....................46 165 (S03) Total number and size of msgs due to state change per day 166 Number of msgs for all watchers........18,400,000,000 167 Bytes for all watchers.............11,224,000,000,000 168 (S04) Number of SUBSCRIBE msgs for refreshes 169 per watcher per day................................70 170 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 171 per watcher per day................................70 172 (S06) Number of NOTIFY msgs for refreshes 173 per watcher per day................................70 174 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 175 per watcher per day................................70 176 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 177 Number of msgs for all watchers per day.5,600,000,000 178 Bytes for all watchers per day......2,856,000,000,000 179 (S09) Total number & bytes of steady messages per day 180 Number of msgs for all watchers........24,000,000,000 181 Bytes for all watchers.............14,080,000,000,000 183 ** Termination Messages 184 (T01) Terminating SUBSCRIBE msgs per watcher.................10 185 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher........10 186 (T03) Terminating NOTIFY msgs per watcher....................10 187 (T04) Terminating 200 OK msgs (NOTIFY) per watcher...........10 188 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 189 Number of msgs for all watchers...........200,000,000 190 Bytes for all watchers.................90,000,000,000 191 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 192 Number of msgs for all watchers...........200,000,000 193 Bytes for all watchers.................74,000,000,000 194 (T07) Total number & bytes of terminating NOTIFY msgs 195 Number of msgs for all watchers...........200,000,000 196 Bytes for all watchers................170,000,000,000 197 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 198 Number of msgs for all watchers...........200,000,000 199 Bytes for all watchers.................74,000,000,000 200 (T09) Total number & bytes of terminating messages per day 201 Number of msgs for all watchers...........800,000,000 202 Bytes for all watchers................408,000,000,000 204 ** Bottom Line 205 (B01) Total of messages between domains..........25,600,000,000 206 Total of bytes bet. domains (PD=350)...14,896,000,000,000 207 Total of bytes bet. domains (PD=3000)..44,046,000,000,000 208 (B02) Total number of messages / second.................888,889 209 Total of bytes per second (PD=350)............517,222,222 210 Total of bytes per second (PD=3000).........1,529,375,000 211 (B03) Total number of by msgs per user/day................1,280 212 Total number of bytes per user/day (PD=350).......744,800 213 Total number of bytes per user/day (PD=3000)....2,202,300 215 Figure 1: Very large network peering with no optimizations 217 ** Constants 218 (C01) Subscription lifetime (hours)...........................8 219 (C02) Presence state changes / hour...........................6 220 (C03) Subscription refresh interval / hour....................1 221 (C04) Total federated presentities per watcher...............10 222 (C05) Number of dialogs to maintain per watcher...............1 223 (C06) Total number of watchers in domains............20,000,000 224 (C07) SUBSCRIBE message size in bytes.......................450 225 (C08) 200 OK for SUBSCRIBE message size in bytes............370 226 (C09) NOTIFY message size not including presence doc........500 227 (C10) 200 OK for NOTIFY message size in bytes...............370 228 (C11) Size of an average presence document..................350 229 (C13) Additional data per document in RLMI..................160 230 (C14) Multiparty boundary in RLMI document..................144 231 (C15) XML root node in RLMI document........................144 233 ** Initial Messages 234 (I01) Initial SUBSCRIBE msgs per watcher......................1 235 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............1 236 (I03) Initial NOTIFY msgs per watcher.........................1 237 (I04) Initial 200 OK msgs (NOTIFY) per watcher................1 238 (I05) Total number & bytes of initial SUBSCRIBE msgs 239 Number of msgs for all watchers............20,000,000 240 Bytes for all watchers..................9,000,000,000 241 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 242 Number of msgs for all watchers............20,000,000 243 Bytes for all watchers..................7,400,000,000 244 (I07) Total number & bytes of initial NOTIFY msgs 245 Number of msgs for all watchers............20,000,000 246 Bytes for all watchers................146,560,000,000 247 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 248 Number of msgs for all watchers............20,000,000 249 Bytes for all watchers..................7,400,000,000 250 (I09) Total number & bytes of initial messages per day 251 Number of msgs for all watchers............80,000,000 252 Bytes for all watchers................170,360,000,000 254 ** Steady State Messages 255 (S01) NOTIFY msgs due to state change 256 per watched presentity per day.....................46 257 (S02) 200 (for NOTIFY due to state change) msgs 258 per watched presentity per day.....................46 259 (S03) Total number and size of msgs due to state change per day 260 Number of msgs for all watchers........18,400,000,000 261 Bytes for all watchers.............16,670,400,000,000 262 (S04) Number of SUBSCRIBE msgs for refreshes 263 per watcher per day.................................7 264 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 265 per watcher per day.................................7 266 (S06) Number of NOTIFY msgs for refreshes 267 per watcher per day.................................0 268 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 269 per watcher per day.................................0 270 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 271 Number of msgs for all watchers per day...280,000,000 272 Bytes for all watchers per day........114,800,000,000 273 (S09) Total number & bytes of steady messages per day 274 Number of msgs for all watchers........18,680,000,000 275 Bytes for all watchers.............16,785,200,000,000 277 ** Termination Messages 278 (T01) Terminating SUBSCRIBE msgs per watcher..................1 279 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........1 280 (T03) Terminating NOTIFY msgs per watcher.....................0 281 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............0 282 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 283 Number of msgs for all watchers............20,000,000 284 Bytes for all watchers..................9,000,000,000 285 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 286 Number of msgs for all watchers............20,000,000 287 Bytes for all watchers..................7,400,000,000 288 (T07) Total number & bytes of terminating NOTIFY msgs 289 Number of msgs for all watchers.....................0 290 Bytes for all watchers..............................0 291 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 292 Number of msgs for all watchers.....................0 293 Bytes for all watchers..............................0 294 (T09) Total number & bytes of terminating messages per day 295 Number of msgs for all watchers............40,000,000 296 Bytes for all watchers.................16,400,000,000 298 ** Bottom Line 299 (B01) Total of messages between domains..........18,800,000,000 300 Total of bytes bet. domains (PD=350)...16,971,960,000,000 301 Total of bytes bet. domains (PD=3000)..41,881,960,000,000 302 (B02) Total number of messages / second.................652,778 303 Total of bytes per second (PD=350)............589,304,167 304 Total of bytes per second (PD=3000).........1,454,234,722 305 (B03) Total number of by msgs per user/day..................940 306 Total number of bytes per user/day (PD=350).......848,598 307 Total number of bytes per user/day (PD=3000)....2,094,098 308 Figure 2: Very large network peering with optimizations 310 2.2. State Management 312 In previous sections we have demonstrated the large amount of 313 messages that need to be sent to/from a presence server In this 314 section the state that needs to be maintained by a presence server 315 will be analyzed and shown to be far from trivial. 317 The presence server has two parallel tasks. 319 1. Maintain the state of the presentities to which watchers 320 subscribe. 321 2. Maintain the state of the subscriptions of watchers and provide 322 timely updates to the watchers. 324 For a single subscription from a single watcher on a presentity, the 325 presence server has to maintain the following state: 327 o Subscription state including all the parameters that are needed in 328 order to maintain the subscription as timers. 329 o Optional filtering information that was requested by the watcher. 330 This includes enough information that is needed for doing the 331 filtering. In addition additional information has to be 332 maintained if partial notification is being supported for the 333 subscription 334 o Optional rate management information as throttling 335 o Watcher information [RFC3857], [RFC3858] that is the result of the 336 subscription in order to enable watched presentities to see who is 337 watching them. 339 For each presentity that has been subscribed to in the presence 340 server, the presence server has to maintain the following state: 342 o A list of the subscriptions for the presentity. Note that this is 343 already taken care of from the size calculation point of view by 344 the subscription state above. 345 o Authorization information for the presentity. 347 For each presentity for which there was any publication and the 348 presentity has a state other then a default value, the presence 349 server has to maintain the current value of the presentity. 351 2.2.1. State Size Calculations 353 Assuming the following sizes, the state size is calculated for 354 various systems: 356 o Subscription size - 2K bytes. This includes watcher information 357 that need to be created by the presence server for each 358 subscription. This is for each subscription that is done by each 359 watcher to each presentity that the watcher is watching. So if we 360 have 10K watchers we should have 10K of these. 361 o Subscribed to resource - 1K bytes (for privacy information and 362 other management info). This is for each presentity that is being 363 watched. No matter how many watchers are watching it. The 364 subscriptions themselves are already calculated in the previous 365 bullet. 366 o Resource with a state - 6K bytes. This is a moderate assumption 367 if we take into account the amount of data that is being put in a 368 presence document as multiple devices, calendar and geographical 369 information. This is for each presentity that has state other 370 then the default empty state. It does not matter if it is being 371 watched or not. 373 Tiny System: 375 o 10K subscriptions = 19M bytes. 376 o 5K subscribed to presentities = 5M bytes. 377 o 10K presentities with state = 58M bytes. 379 The total for tiny system is 82M bytes. 381 Medium System: 383 o 100K subscriptions = 195M bytes. 384 o 50K subscribed to presentities = 49M bytes. 385 o 100K presentities with state = 586M bytes. 387 The total for medium system is 830M bytes. 389 Large System: 391 o 6M subscriptions = 11,718M bytes. 392 o 3M subscribed to presentities = 2,929M bytes. 393 o 4M presentities with state = 23437M bytes. 395 The total for large system is 38G bytes. 397 Very Large System: 399 o 150M subscriptions = 292,969M bytes. 400 o 75M subscribed to presentities = 73,242M bytes. 401 o 100M presentities with state = 585,937M bytes. 403 The total for very large system is 952G bytes which is a very big 404 number for a very dynamic storage as needed by the presence server. 406 Although the numbers above may seem moderate enough for the sizes 407 that the presence server is handling we should consider the 408 following: 410 o Dynamic state - Although the state may seem not so big for 411 databases even for the very large system, we need to remember that 412 this state is a very dynamic state. Subscriptions come and go all 413 the time, the status of presentities is being updated and so 414 forth. This means that the presence server has to manage its 415 state in a medium that is very dynamic and for such large sizes 416 this task is not trivial. 417 o Interlinked state - The subscriptions and the subscribed to 418 presentities are dependent on each other. There needs to be a 419 link from the presentity to the subscriptions and vice versa. 420 There is a need to be a linkage between the Resource List Server 421 (RLS [RFC4662]) and the various presence servers that hold the 422 presence data. See section 4.5 in the presence scaling document 423 for more details. 424 o Moderate assumptions - The size assumptions that were made above 425 are quite moderate. As presence is becoming more a core 426 middleware functionality that holds a lot of data on the user. In 427 real-life the numbers above may be even higher and the presence 428 server can have additional overhead as managing the SIP sessions, 429 networking and more. 431 Although the calculations above do not show that there is a real 432 issue with state management of presence in medium systems or even in 433 big systems since it should be possible to divide the state between 434 different machines, the state size is still very big. A bigger issue 435 with the state is more when resource lists are involved and create an 436 interlinked state between many servers. In that case the division of 437 very big state to multiple servers becomes less trivial... 439 3. Requirements 441 This section lists requirements for a solution that will optimize the 442 interdomain presence loads. The requirements are based on the 443 presence scaling draft 444 [I-D.ietf-simple-interdomain-scaling-analysis]. 446 3.1. Backward Compatibility Requirements 448 o REQ-001: The solution SHOULD NOT deprecate existing protocol 449 mechanisms defined in SIP/SIMPLE. The ability of existing SIP/ 450 SIMPLE clients and/or servers from peering with a domain or a 451 client implementing the solution SHOULD be retained with no 452 changes required of existing servers to interoperate. 454 o REQ-002-A: The solution SHOULD NOT constrain any existing RFC 455 functional requirements for presence. 457 o REQ-002-B: The solution MUST NOT constrain any existing RFC 458 security requirements for presence. 460 o REQ-003: Systems that are not using the new additions to the 461 protocol SHOULD operate at the same level as they do today. 463 3.2. Policy, Privacy, Permissions Requirements 465 o REQ-004: The solution SHOULD NOT limit the ability for 466 presentities to present different views of presence to different 467 watchers. 469 o REQ-005: The solution SHOULD NOT restrict the ability of a 470 presentity to obtain its list of watchers. 472 o REQ-006: The solution MUST NOT create any new or make worse any 473 existing privacy holes. 475 3.3. Scalability Requirements 477 o REQ-007: Presence systems (intra or inter-domain) SHOULD scale in 478 linear proportion to the number of watchers and presentities in 479 the system. 481 o REQ-008: The solution SHOULD NOT require significantly more state 482 then solutions based on current protocol in order to implement the 483 optimizations. 485 o REQ-009: The solution MUST allow presence systems to scale. Note: 486 we view scalability on the order of tens of millions of users in 487 each peer domain. 489 o REQ-010: There may be various usage patterns when users of one 490 domain subscribe to users from another domain. It may be that 491 only small percentage of users from each domain will subscribe to 492 users from the other domain, it may be that most watchers will be 493 from the other domain while there will be few watchers from the 494 same domain. The solution MUST support high percentage of 495 watcher/presentity intersections between the domains and it MUST 496 support various intersection models. 498 o REQ-011: Protocol changes MUST NOT prohibit optimizations in 499 different deployment models especially where there is a high level 500 of cross subscriptions between the domains. 502 o REQ-012: New functionalities and extensions to the presence 503 protocol SHOULD take into account scalability with respect to the 504 number of messages, state size and management and processing load. 506 3.4. Topology Requirements 508 o REQ-013: The solution SHOULD allow for arbitrary federation 509 topologies including direct and indirect peering. 511 4. Considerations for Possible Optimizations 513 The document provides an initial list of requirements for a solution 514 of scalability of interdomain presence systems using the SIP/SIMPLE 515 protocol. The issue of scalability was shown in a separate document 516 [I-D.ietf-simple-interdomain-scaling-analysis]. 518 The following is a discussion of the various possible paths for 519 optimizations. One of the most important considerations is whether 520 there is a need to adapt SIP that was designed more as an end to end 521 protocol to be much more optimized when presence server interacts 522 directly with another presence server. 524 It is very possible that the issues that are described in this 525 document are inherent to presence systems in general and not specific 526 to the SIP/SIMPLE protocol. Organizations need to be prepared to 527 invest substantial resources in the form of networks and hardware in 528 order to create sizable systems. However, it is apparent that 529 additional protocol optimizations are possible and further work is 530 needed in the IETF in order to provide better scalability of large 531 presence systems. 533 We should remember that SIP was originally designed for end to end 534 session creation and number and size of messages are of secondary 535 importance for an end to end session negotiation protocol. For large 536 scale and especially for very large scale presence the number of 537 messages that are needed and the size of each message are of extreme 538 importance. Adequate care must be taken in addressing scalability as 539 part of the initial protocol design phase; Trying to to shoehorn 540 scalability at a later phase will be doomed to failure. 542 We should also consider whether using the same protocol between 543 clients and servers and between servers is a good choice. It may be 544 that in interdomain or even between servers in the same domain (as 545 between RLSs [RFC4662], and presence servers) there is a need to have 546 a different protocol that will be very optimized for the load and can 547 assume some assumptions about the network (for example do not use 548 unreliable protocol as UDP but only TCP, see the section that 549 calculates the number of bytes and messages for imaginary very 550 optimized SIP). 552 When a presence server connects to another server using the current 553 SIP/SIMPLE protocol, there will be an extreme number of redundant 554 messages due to the overhead in the SIP protocol of supporting both 555 TCP and UDP and due to the need to send multiple presence documents 556 for the same watched user because of privacy issues. A server to 557 server protocol will have to address these issues. Some initial work 558 to address these issues can be found in: 559 [I-D.ietf-simple-view-sharing] and 560 [I-D.ietf-simple-intradomain-federation] and in other (still 561 individual) drafts. 563 Another issue that is more related to protocol design is whether 564 NOTIFY messages should not be considered as media just like audio, 565 video and even text messaging. The SUBSCRIBE method may be extended 566 to negotiate the route and other parameters of the NOTIFY messages, 567 in a similar way that the INVITE method negotiates media parameters. 568 This way the load can be offloaded to a specialized NOTIFY "relays" 569 thus not loading the control path of SIP. One of the possible ideas 570 (Marc Willekens) is to use the SIP protocol for client/server NOTIFY 571 but make use of a more optimized and controllable protocol for the 572 server-to-server interface. Another possibility is to use the MSRP 573 [RFC4975], [RFC4976] protocol for the notifications. 575 4.1. Very Optimized SIP 577 SIP is network agnostic protocol, therefore, the protocol carries 578 additional messages like 200 OK that would have been redundant in a 579 protocol that is TCP based only. 581 The following calculation assumes an imaginary TCP only based version 582 of SIP that optimizes the following: 584 o There is no 200 OK for each message. Since only TCP has to be 585 supported, there is not need to compensate for network issues. 586 o There is no refresh for subscriptions. 587 o There is no NOTIFY upon termination of SUBSCRIPTION 588 o The size of each message is smaller since there is no need for the 589 various headers that SIP uses for routing etc. So we need to 590 assume smaller message sizes while we will keep the size of the 591 presence document the same. 593 As notes above the calculations in this document do not assume 594 offline means of getting parts of the presence information. 595 Therefore, in addition to the above optimizations, the other 596 optimizations that were assumed in the document will be assumed here 597 also. These includes partial notifications and the dialog 598 optimizations. The NOTIFY optimization is not relevant here since 599 there are no refreshes of subscriptions. 601 The following is a calculation for the very large networks peering 602 scenario assuming the imaginary TCP only SIP. It is very interesting 603 to note that the dialog optimization does not reduce the number of 604 bytes when partial notification optimization is applied (on the 605 contrary) due to the RLMI overhead. 607 ** Constants 608 (C01) Subscription lifetime (hours)...........................8 609 (C02) Presence state changes / hour...........................6 610 (C03) Subscription refresh interval / hour....................0 611 (C04) Total federated presentities per watcher...............10 612 (C05) Number of dialogs to maintain per watcher...............1 613 (C06) Total number of watchers in domains............20,000,000 614 (C07) SUBSCRIBE message size in bytes.......................150 615 (C08) 200 OK for SUBSCRIBE message size in bytes..............0 616 (C09) NOTIFY message size not including presence doc........150 617 (C10) 200 OK for NOTIFY message size in bytes.................0 618 (C11) Size of an average presence document..................350 619 (C12) Size of an average partial presence document..........200 621 ** Initial Messages 622 (I01) Initial SUBSCRIBE msgs per watcher......................1 623 (I02) Initial 200 OK msgs (SUBSCRIBE) per watcher.............0 624 (I03) Initial NOTIFY msgs per watcher.........................1 625 (I04) Initial 200 OK msgs (NOTIFY) per watcher................0 626 (I05) Total number & bytes of initial SUBSCRIBE msgs 627 Number of msgs for all watchers............20,000,000 628 Bytes for all watchers..................3,000,000,000 629 (I06) Total number & bytes of initial 200 OK (SUBSCRIBE) msgs 630 Number of msgs for all watchers.....................0 631 Bytes for all watchers..............................0 632 (I07) Total number & bytes of initial NOTIFY msgs 633 Number of msgs for all watchers............20,000,000 634 Bytes for all watchers................136,680,000,000 635 (I08) Total number & bytes of initial 200 OK (NOTIFY) msgs 636 Number of msgs for all watchers.....................0 637 Bytes for all watchers..............................0 638 (I09) Total number & bytes of initial messages per day 639 Number of msgs for all watchers............40,000,000 640 Bytes for all watchers................139,680,000,000 642 ** Steady State Messages 643 (S01) NOTIFY msgs due to state change 644 per watched presentity per day.....................46 645 (S02) 200 (for NOTIFY due to state change) msgs 646 per watched presentity per day......................0 647 (S03) Total number and size of msgs due to state change per day 648 Number of msgs for all watchers.........9,200,000,000 649 Bytes for all watchers..............8,666,400,000,000 650 (S04) Number of SUBSCRIBE msgs for refreshes 651 per watcher per day.................................0 652 (S05) Number of 200 OK msgs for SUBSCRIBE msgs for refreshes 653 per watcher per day.................................0 654 (S06) Number of NOTIFY msgs for refreshes 655 per watcher per day.................................0 656 (S07) Number of 200 OK msgs for NOTIFY msgs for refreshes 657 per watcher per day.................................0 658 (S08) Total number and size of msgs due to SUBSCRIBE refreshes 659 Number of msgs for all watchers per day.............0 660 Bytes for all watchers per day......................0 661 (S09) Total number & bytes of steady messages per day 662 Number of msgs for all watchers.........9,200,000,000 663 Bytes for all watchers..............8,666,400,000,000 665 ** Termination Messages 666 (T01) Terminating SUBSCRIBE msgs per watcher..................1 667 (T02) Terminating 200 OK msgs (SUBSCRIBE) per watcher.........0 668 (T03) Terminating NOTIFY msgs per watcher.....................0 669 (T04) Terminating 200 OK msgs (NOTIFY) per watcher............0 670 (T05) Total number & bytes of Terminating SUBSCRIBE msgs 671 Number of msgs for all watchers............20,000,000 672 Bytes for all watchers..................3,000,000,000 673 (T06) Total number & bytes of terminating 200 OK (SUBSCRIBE) msgs 674 Number of msgs for all watchers.....................0 675 Bytes for all watchers..............................0 676 (T07) Total number & bytes of terminating NOTIFY msgs 677 Number of msgs for all watchers.....................0 678 Bytes for all watchers..............................0 679 (T08) Total number & bytes of terminating 200 OK (NOTIFY) msgs 680 Number of msgs for all watchers.....................0 681 Bytes for all watchers..............................0 682 (T09) Total number & bytes of terminating messages per day 683 Number of msgs for all watchers............20,000,000 684 Bytes for all watchers..................3,000,000,000 686 ** Bottom Line 687 (B01) Total of messages between domains...........9,260,000,000 688 Total of bytes between domains (PD=350).8,809,080,000,000 689 Total of bytes bet. domains (PD=3000)...9,339,080,000,000 690 (B02) Total number of messages / second.................321,528 691 Total of bytes per second (PD=350)............305,870,833 692 Total of bytes per second (PD=3000)...........324,273,611 693 (B03) Total number of by msgs per user/day..................463 694 Total number of bytes per user/day (PD=350).......440,454 695 Total number of bytes per user/day (PD=3000)......466,954 696