SIMPLE%20Problem%20Statement

1
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
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
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
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
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
Numbers
Numbers are between two domains only, Very
conservative assumptions
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/570 489 / 300 14.08M / 8.64M 20,000 4 3 Basic case
1968/571 2,444 / 1367 70.4M / 39.36M 20,000 20 3 Widely dist. inter-domain / Associated inter-domain
880,000/ 546.000 944K / 683K 27.2B / 19.68B 10M 10 6 Very large network peering
3683/1675 3,667 / 2,100 105.6M / 60.48M 60,000 10 3 Intra-domain
7
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
Notify Optimizations (1)

• Set of optimizations that are intended to save on
  the number of notifies thus helping scaling
• Akis subnot-etags is one example
• Several other suggestions are listed in the draft

9
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
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
Next Edits

• Get real data from real big deployments of SIP
  and other protocols
• Add rush hour calculations
• Add multiple device support
• More?

12
Next in Process

• Create a separate requirements document?
• Publish as informational RFC
• Other?