ietf 67 – simple wg simple problem statement draft-rang-simple-problem-statement-01 tim rang -...

IETF 67 – SIMPLE WG

SIMPLE Problem Statement

Draft-rang-simple-problem-statement-01Tim Rang - Microsoft

Avshalom Houri – IBMEdwin Aoki – AOL


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


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


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


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


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


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


Numbers

ModelPresence change/hour

Presentities per watcher

# of watchers between domains

Total msgs – non optimized / optimized

msgs/sec – non optimized / optimized

Basic case3420,00014.08M / 8.64M489 / 300

Widely dist. inter-domain / Associated inter-domain

32020,00070.4M / 39.36M2,444 / 1367

Very large network peering

61010M27.2B / 19.68B944K / 683K

Intra-domain31060,000105.6M / 60.48M3,667 / 2,100

Subscription lifetime = 8 hours, subscription refresh interval – 1 hourNumbers are between two domains only, Conservative assumptions


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


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


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


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


Processing Complexities (1)

• Aggregation – Taking multiple resources and merging them into a single presence document

Dev A

Dev B

PresenceDoc


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


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


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


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



• 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



• 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


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


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


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 simple problem statement draft-rang-simple-problem-statement-01 tim rang -...

Documents