SIMPLE Problem Statement

1. SIMPLE Problem Statement draft-ietf-simple-interdomain-scaling-analysis-03 Avshalom Houri – IBM Tim Rang, Sriram Parameswar - Microsoft Edwin Aoki – AOL Vishal Singh, Henning Schulzrine – Columbia University IETF 70 – SIMPLE WG

2. Changes (1) • Added some input from real life deployments and input on a test with batched notifies • Added Calculations of messages and bytes per user • Calculations are now done both for minimal size of presence document and for an average size of rich presence document. • Comparison with other protocol is now done using small, tiny and rich presence document sizes • Removed dialog optimization with partial notification since it is not relevant (yet?) IETF 70 – SIMPLE WG

3. Changes (2) • Fixed a few issues in calculations that were found by Victoria Beltran-Martinez. • Added overhead for RLMI for dialog optimizations (list subscription). This calculation fix actually shows that dialog optimization is not a real optimization from the point of view of bytes and number of messages • When NOTIFY optimizations are applied no need for final NOTIFY • The usage of RLS between domains was clarified. • Significantly enhanced the conclusions section • Several typo fixes IETF 70 – SIMPLE WG

4. Size Assumptions • SUBSCRIBE – 450 bytes • 200 OK (for SUBSCRIBE/NOTIFY) – 370 • NOTIFY (w/o presence document) – 500 • Minimal presence document – 350 • “Rich” presence document – 3000 • Partial presence document - 200 IETF 70 – SIMPLE WG

5. Numbers – Basic Use Case Presence state changes / hour....................................3 Total federated presentities per watcher.........................4 Total # of watchers in the federated domains................40,000 No optimizations Dialog & Notify Total of messages between domains.......................12,800,000........7,840,000 Total of bytes between domains (PD=350).........7,232,000,000....6,311,760,000 Total of bytes between domains (PD=3000).......20,376,000,000...16,063,760,000 Total number of messages / second..............................444..............272 Total of bytes per second (PD=350)....................251,111..........219,158 Total of bytes per second (PD=3000)...................707,500..........557,769 Total number of by msgs per user/day...........................320..............196 Total number of bytes per user/day (PD=350)...........180,800..........157,794 Total number of bytes per user/day (PD=3000)..........509,400..........401,594 IETF 70 – SIMPLE WG

6. Numbers – Very Large Network Peering Presence state changes / hour....................................6 Total federated presentities per watcher........................10 Total # of watchers in the federated domains............20,000,000 No optimizations Partial & Notify Total of messages between domains...................25,600,000,000......22,400,000,000 Total of bytes between domains (PD=350)....14,896,000,000,000..11,564,000,000,000 Total of bytes between domains (PD=3000)........44,046,000,000,000..12,094,000,000,000 Total number of messages / second..........................888,889.............777,778 Total of bytes per second (PD=350)........... ... 517,222,222.........401,527,778 Total of bytes per second (PD=3000).............1,529,375,000.........419,930,556 Total number of by msgs per user/day........................ 1,280...............1,120 Total number of bytes per user/day (PD=350)...........744,800.............578,200 Total number of bytes per user/day (PD=3000)........2,202,300.............604,700 IETF 70 – SIMPLE WG

7. Other Protocol - Assumptions • Assuming • TCP only – No need for 200 OK etc. • No need for refreshes • No NOTIFY for termination (also in subnot-etags) • Did not assume • No need for termination at all (TCP based) • The need for rich presence document may be minimal since other data may be achieved by other means (e.g. PEP in XMPP) IETF 70 – SIMPLE WG

8. Other Protocol - Numbers Presence state changes / hour....................................6 Total federated presentities per watcher........................10 Total # of watchers in the federated domains............20,000,000 Other Protocol Partial & Notify Total of messages between domains....................9,800,000,000.......22,400,000,000 Total of bytes between domains (PD=50)......1,940,000,000,000 Total of bytes between domains (PD=350).....4,760,000,000,000...11,564,000,000,000 Total of bytes between domains (PD=3000)...29,670,000,000,000...12,094,000,000,000 Total number of messages / second..........................340,278..............777,778 Total of bytes per second (PD=50)..................67,361,111 Total of bytes per second (PD=350)................165,277,778..........401,527,778 Total of bytes per second (PD=3000).............1,030,208,333..........419,930,556 Total number of by msgs per user/day...........................490................1,120 Total number of bytes per user/day (PD=50).............97,000 Total number of bytes per user/day (PD=350)...........238,000..............578,200 Total number of bytes per user/day (PD=3000)........1,483,500..............604,700 IETF 70 – SIMPLE WG

9. Problem is Even Harder • In the analysis we assume: • Single device per user • No external sources as location or calendar • Small rate of change • These are “optimistic” assumptions IETF 70 – SIMPLE WG

10. What Can Be Done? • SIP is a verbose protocol by initial design (end to end) • Many headers • Need to support UDP • Etc. • However, optimizations by other protocols as TCP only, Binary messages and more still provide a constant factor reduction in traffic • Scaling to hundreds of million users with multiple devices and other good features will be a real challenge with any protocol • The presence scaling problem seems intrinsic to presence • We need to think about the scaling problem both from protocol optimization and also from the algorithmic point of view IETF 70 – SIMPLE WG

11. Optimizations • Requirements (draft-houri-sipping-presence-scaling-requirements-01) presented in SIPPING • Several optimization directions are described in draft-houri-simple-interdomain-scaling-optimizations-00 • Important optimization suggestion draft is draft-rosenberg-simple-view-sharing-00 which will be presented next IETF 70 – SIMPLE WG

12. Next? • WGLC? IETF 70 – SIMPLE WG