IETF 70 – SIMPLE WG 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 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 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 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 Numbers – Basic Use Case Presence state changes / hour Total federated presentities per watcher Total # of watchers in the federated domains ,000 No optimizations Dialog & Notify Total of messages between domains ,800, ,840,000 Total of bytes between domains (PD=350) ,232,000, ,311,760,000 Total of bytes between domains (PD=3000) ,376,000, ,063,760,000 Total number of messages / second Total of bytes per second (PD=350) , ,158 Total of bytes per second (PD=3000) , ,769 Total number of by msgs per user/day Total number of bytes per user/day (PD=350) , ,794 Total number of bytes per user/day (PD=3000) , ,594

IETF 70 – SIMPLE WG Numbers – Very Large Network Peering Presence state changes / hour Total federated presentities per watcher Total # of watchers in the federated domains ,000,000 No optimizations Partial & Notify Total of messages between domains ,600,000, ,400,000,000 Total of bytes between domains (PD=350)....14,896,000,000, ,564,000,000,000 Total of bytes between domains (PD=3000) ,046,000,000, ,094,000,000,000 Total number of messages / second , ,778 Total of bytes per second (PD=350) ,222, ,527,778 Total of bytes per second (PD=3000) ,529,375, ,930,556 Total number of by msgs per user/day , ,120 Total number of bytes per user/day (PD=350) , ,200 Total number of bytes per user/day (PD=3000) ,202, ,700

IETF 70 – SIMPLE WG 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 Other Protocol - Numbers Presence state changes / hour Total federated presentities per watcher Total # of watchers in the federated domains ,000,000 Other Protocol Partial & Notify Total of messages between domains ,800,000, ,400,000,000 Total of bytes between domains (PD=50) ,940,000,000,000 Total of bytes between domains (PD=350).....4,760,000,000, ,564,000,000,000 Total of bytes between domains (PD=3000)...29,670,000,000, ,094,000,000,000 Total number of messages / second , ,778 Total of bytes per second (PD=50) ,361,111 Total of bytes per second (PD=350) ,277, ,527,778 Total of bytes per second (PD=3000) ,030,208, ,930,556 Total number of by msgs per user/day ,120 Total number of bytes per user/day (PD=50) ,000 Total number of bytes per user/day (PD=350) , ,200 Total number of bytes per user/day (PD=3000) ,483, ,700

IETF 70 – SIMPLE WG 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 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 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 Next? WGLC?