SIMPLE Problem Statement

1. SIMPLE Problem Statement Draft-rang-simple-problem-statement-01 Tim Rang - Microsoft Avshalom Houri – IBM Edwin Aoki – AOL IETF 67 – SIMPLE WG

2. Categories of Issues • Message Load (Network) – Calculations of amount of messages needed with and with out optimizations • State management (Memory) – Calculation of the amount of state that the presence server needs to maintain • Processing complexities (CPU) – Discussion on various processing complexities that the presence server need to handle • Groups explosion – The “unbearable” easiness of expansion via resource lists IETF 67 – SIMPLE WG

3. Message Load • Inter domain traffic of SUBSCRIBE and NOTIFY between two domains is analyzed with and without optimizations • Results show that even with optimizations the number of messages (only between two domains) are very big • Conservative assumptions on amount of users and subscriptions IETF 67 – SIMPLE WG

4. Computation • Described in detail in the draft • Input parameters • Subscription lifetime • Presence state change/hour • Subscription refresh interval/hour • Total federated presentities per watcher • Number of dialogs per watcher (optimization dependent) • Number of watchers in each domain IETF 67 – SIMPLE WG

5. Models • Two domains connecting – Basic case of two domains connecting • Widely Distributed Inter-Domain – Users of each domain are not usually subscribed to presence within the domain. E.g. small public servers • Associated inter domain – e.g. enterprise servers. Assuming it is the same as widely distributed inter-domain with respect to traffic between domains • Very large network peering – e.g. consumer IM networks • Intra domain peering – e.g. multiple presence servers in the same domain IETF 67 – SIMPLE WG

6. Optimizations Considered • Two categories of optimizations were considered: • Dialog saving optimization i.e. event-list or uri- list that enable using a single subscribe dialog for many subscriptions • Notification optimizations i.e. subnot-etags by Aki Niemi which suppresses non necessary notifies IETF 67 – SIMPLE WG

7. Widely Distributed Inter-Domain • Numbers used • Subscription lifetime – 8 hours • Presence state changes per hour – 3 • Subscription is refreshed every hour • Total watched presentities – 20 • Number of watchers in each domain – 20,000 • Number of dialogs per watcher - 20 (non optimized), 1 (optimized) • Not Optimized • Total of messages (8 hours) between domains – 70.4M • Number of messages per second - 2,444 • Optimized • Total of messages (8 hours) between domains – 39.36M • Number of messages per second - 1367 IETF 67 – SIMPLE WG

8. Numbers Subscription lifetime = 8 hours, subscription refresh interval – 1 hour Numbers are between two domains only, Conservative assumptions IETF 67 – SIMPLE WG

9. Extreme Optimizations • Consolidated subscriptions (privacy is somehow solved) • No re-subscription is required • Using the above optimizations for the very large network peering model we get 3 fold reduction in the number of messages only by using consolidates subscriptions • No re-subscription does not have much effect since subnot-etag is used IETF 67 – SIMPLE WG

10. Message Computation Summary • The numbers presented are only between two domains, when more domains are connected the number of messages will be multiplied • Conservative numbers were used, in real life numbers may be even higher • Although current optimizations can reduce the traffic by up to 50%, the traffic is still very high • Consolidates subscriptions can help a lot but the privacy issue between domains has to be solved first IETF 67 – SIMPLE WG

11. State Management • Calculation of size of data the presence server has to manage • Data contains: • State of managed resources • List of subscribers • Various additional data as watcher information, privacy and filtering • Data is very dynamic and interlinked • Conservative assumptions were used also here • New usages of presence as Geopriv may increase the state considerably IETF 67 – SIMPLE WG

12. State Sizes • Tiny system – 10K subscriptions, 5K subscribed to resources, 10K resources with data – 82M byte • Medium system – 100K subscriptions, 50K subscribed to resources, 100K resources with data – 830M byte • Large system – 6M subscriptions, 3M subscribed to resources, 4M resources with data – 38G byte • Very large system – 150M subscriptions, 75M subscribed to resources, 100M resources with data – 925G byte IETF 67 – SIMPLE WG

13. Processing Complexities (1) • Aggregation – Taking multiple resources and merging them into a single presence document Dev A Presence Doc Dev B IETF 67 – SIMPLE WG

14. Processing Complexities (2) • Partial publish and notify • Filtering on subscription conditions • Filtering due to privacy/geopriv • Some of the complexities are due to trying to save data on the network • Need to add sizing model but it is obvious that the presence server is CPU intensive IETF 67 – SIMPLE WG

15. Groups Explosion • Resource list subscriptions enables optimizing the number of subscriptions • On the other hand, it is very easy to create enormous number of subscriptions via resource list subscriptions • Administrators may define public groups that can be very large • The combination of resource lists and public groups can increase the amount of subscriptions between domains exponentially IETF 67 – SIMPLE WG

16. Conclusions • The presence server has major challenges: • Network • Memory • CPU • Exponentiality • Some of the issues can be solved via protocol changes and some will be solved via careful design and implementation • The SIMPLE WG should do what can be done in order to make really big deployments of presence via SIP feasible IETF 67 – SIMPLE WG

17. Current Optimizations (1) • Subnot-etags – Seems to be an efficient optimization that saves on the network and processing time • Resource Lists – Saves on the number of subscriptions but can create exponential number of subscriptions between presence servers • Partial Notify/Publish – Saves on the amount of data sent to/from presence server but loads the presence server processing time • Filtering - Saves on the amount of data sent to/from presence server but loads the presence server processing time IETF 67 – SIMPLE WG

18. Current Optimizations (2) • Throttling – Saves on the amount of messages sent and does not seem to load the presence server on other aspects. May be more important with resource lists • SIGCOMP dictionary – Can save on the amount of data sent • Content indirection – Enables sending only URI as the content for presence but due to partial notification/filtering/privacy and the complexity of content management on the content server may not help a lot IETF 67 – SIMPLE WG

19. Current Optimizations (3) • Resource list re-subscriptions – Current definition in RFC 4662 require full state on re-subscription while it is an open issue in the subnot-etags draft • Consolidates Subscriptions – Enables sending only one subscription between domains for many users. Can not be done without finding a solution to privacy between domains IETF 67 – SIMPLE WG

20. Requirements (1) • Seems that further work in SIMPLE WG is needed in order to have better optimizations • Initial set of requirements is included in the draft including: • Backward compatibility should be preserved • Privacy should be supported • All topologies should be enabled IETF 67 – SIMPLE WG

21. Requirements (2) • Scalability requirements • It is highly desirable for inter-domain network to scale linearly as number of watchers and presentities increase linearly • The solution SHOULD NOT require significantly more state in order to implement the solution • It MUST be able to scale to tens of millions of concurrent users in each peer domain • It MUST support a very high level of watcher/presentity intersections in various intersection models • Protocol changes MUST NOT prohibit optimizations in different deployment models esp. where there is a high level of cross subscriptions between the domains • New functionalities and extensions to presence protocol should take into account scalability issues IETF 67 – SIMPLE WG

22. The ?s Slide • What is missing? • What is not correct? • Adopt as working group document? • Start working on separate requirements document? • Other next steps? IETF 67 – SIMPLE WG