1 / 12

SIMPLE Problem Statement

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. Changes (1).

Download Presentation

SIMPLE Problem Statement

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related