Date post: | 18-Jan-2016 |
Category: |
Documents |
Upload: | samantha-hunt |
View: | 212 times |
Download: | 0 times |
IETF 67 – SIMPLE WG
SIMPLE Problem Statement
Draft-rang-simple-problem-statement-01Tim Rang - Microsoft
Avshalom Houri – IBMEdwin 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 - 1367
IETF 67 – SIMPLE WG
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
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
PresenceDoc
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?