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

IETF 67 – SIMPLE WG 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 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 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 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 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 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

IETF 67 – SIMPLE WG Numbers msgs/sec – non optimized / optimized Total msgs – non optimized / optimized # of watchers between domains Presentities per watcher Presence change/hour Model 489 / M / 8.64M20,00043Basic case 2,444 / M / 39.36M20,000203Widely dist. inter-domain / Associated inter-domain 944K / 683K27.2B / 19.68B10M106Very large network peering 3,667 / 2, M / 60.48M60,000103Intra-domain Subscription lifetime = 8 hours, subscription refresh interval – 1 hour Numbers are between two domains only, Conservative assumptions

IETF 67 – SIMPLE WG 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 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 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 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 Processing Complexities (1) Aggregation – Taking multiple resources and merging them into a single presence document Dev A Dev B Presence Doc

IETF 67 – SIMPLE WG 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 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 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 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 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 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 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 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 The ?s Slide What is missing? What is not correct? Adopt as working group document? Start working on separate requirements document? Other next steps?