SIMPLE Problem Statement

draft-ietf-simple-interdomain-scaling-analysis-00Avshalom Houri – IBMTim Rang - Microsoft

Edwin Aoki – AOLVishal Singh – Columbia University

Henning Schulzrine – Columbia University

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

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

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

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

Numbers

ModelPresence change/hour

Presentities per watcher

# of watchers between domains

Total msgs – non optimized / optimized

msgs/sec – non optimized / optimized

KBs/sec - non optimized / optimized

Basic case3420,00014.08M / 8.64M

489 / 300830/570

Widely dist. inter-domain / Associated inter-domain

32020,00070.4M / 39.36M

2,444 / 13671968/571

Very large network peering

61010M27.2B / 19.68B

944K / 683K880,000/

546.000

Intra-domain31060,000105.6M / 60.48M

3,667 / 2,1003683/1675

Numbers are between two domains only, Very conservative assumptions

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

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

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

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

Next Edits

• Get real data from real big deployments of SIP and other protocols

• Add “rush hour” calculations

• Add multiple device support

• More?

Next in Process

• Create a separate requirements document?

• Publish as informational RFC

• Other?