Download presentation
Presentation is loading. Please wait.
Published byNora Cunningham Modified over 9 years ago
1
IETF 68 – SIMPLE WG SIMPLE Problem Statement draft-ietf-simple-interdomain-scaling-analysis-00 Avshalom Houri – IBM Tim Rang - Microsoft Edwin Aoki – AOL Vishal Singh – Columbia University Henning Schulzrine – Columbia University
2
IETF 68 – SIMPLE WG Changes from previous draft Draft replaces draft-rang-simple-problem- statement-01 Cleaning, clarifications and terminology corrections Added computation of estimated bandwidth Added more discussion around the issues with scalability with resource lists Added several suggestions for optimizations by Vishal and Henning
3
IETF 68 – SIMPLE WG Presence Load Modeling Presence behavior is very dependent on user behavior, “rush” hour, number of devices and many more factors It is really hard to freeze only a single collection of behaviors The draft tries to use a very conservative assumptions in order to prove a scalability issue
4
IETF 68 – SIMPLE WG Subscription Assumptions 8 hours working day (who has this luxury these days?) Subscription refresh interval – 1 hour Single device per user No “rush hour” traffic is taken into consideration Based on common sense assumptions and experience but not on rigorous statistical data from a real SIP deployment
5
IETF 68 – SIMPLE WG Bandwidth Assumptions 1K for SUBSCRIBE/200 and 4K for NOTIFY/200 Very moderate since due to various extensions to PIDF and multiple devices, NOTIFY can be much bigger
6
IETF 68 – SIMPLE WG Numbers KBs/sec - non optimized / optimized msgs/sec – non optimized / optimized Total msgs – non optimized / optimized # of watchers between domains Presentities per watcher Presence change/hour Model 830/570489 / 30014.08M / 8.64M 20,00043Basic case 1968/5712,444 / 136770.4M / 39.36M 20,000203Widely dist. inter-domain / Associated inter-domain 880,000/ 546.000 944K / 683K27.2B / 19.68B 10M106Very large network peering 3683/16753,667 / 2,100105.6M / 60.48M 60,000103Intra-domain Numbers are between two domains only, Very conservative assumptions
7
IETF 68 – SIMPLE WG Bandwidth Optimizations Filtering, partial notifications and more that were intended to save bandwidth on the wire and especially for the client These optimizations create processing load on the server
8
IETF 68 – SIMPLE WG Notify Optimizations (1) Set of optimizations that are intended to save on the number of notifies thus helping scaling Aki’s subnot-etags is one example Several other suggestions are listed in the draft
9
IETF 68 – SIMPLE WG Notify Optimizations (2) Common NOTIFY for multiple watchers – a single NOTIFY for all watchers on the other domain that subscribed to the same user –Raises the need to address moving privacy, filtering and watcher list between domains Aggregation of NOTIFY messages – Send several notifications to a single watcher on multiple presentities in single message
10
IETF 68 – SIMPLE WG Lazy Subscriptions Timed presence – Do not subscribe when a user is e.g. in vacation Use on-demand presence – Divide between users with whom the watcher has frequent interactions and users that are “only there” for the latter batched subscriptions can be done
11
IETF 68 – SIMPLE WG Next Edits Get real data from real big deployments of SIP and other protocols Add “rush hour” calculations Add multiple device support More?
12
IETF 68 – SIMPLE WG Next in Process Create a separate requirements document? Publish as informational RFC Other?
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.