1. SIMPLE Presence Traffic Optimization and Server Scalability Vishal Kumar Singh Henning Schulzrinne Markus Isomaki Piotr Boni IETF 67, San Diego

2. Presence Problems Revisited Resource list server and conditional NOTIFY using entity-tags in SUBSCRIBE address 40% of total inter-domain presence traffic –NOTIFY = 60% of traffic Traffic scaling –Access network Low bandwidth (wireless) Traffic bursts due to user synchronization –Inter-domain traffic Steady-state NOTIFY message volume –Intra-domain traffic Server scaling –Partial notify, privacy filtering, composition, …  limited request rate per server

3. Proposed Solutions Common NOTIFY for multiple watchers in a domain –Useful in inter-domain scenario Batched NOTIFY –Useful both in access network and inter-domain scenarios Timed-status –User can choose to get notified based on calendar information of watcher On-demand presence –Useful in all scenarios Adapting the notification rate

4. Traffic Reduction Vs. Server Load TechniqueAccess (BW)Backbone (BW)Server (load) RLS+ (SUBSCRIBE)+- (dialog maintained) Conditional NOTIFY+ (NOTIFY)++ Partial publication+ (payload ~ ¼)+- Watcher filtering+ (smaller payload or # of messages) +- SIGCOMP++- Common NOTIFY=+ (messages)? Batched NOTIFY+ (header overhead)+ - On-demand presence+++ Timed status++- (+) improves, (-) worsens

5. Common NOTIFY for Multiple Watchers Multiple watchers subscribe to same presentity in another domain (Popular user, co-workers on a project) –Presentity’s presence server sends a single NOTIFY to watcher’s domain presence server –Watcher domain presence server distributes it to individual watchers Issues –Privacy filtering –Failure aggregation –Watcher list to watcher’s domain presence server Domain A Domain B NOTIFY (PIDF + subscriber list) PUBLISH (PIDF) Presentity Privacy Filtering SUBSCRIBE (To same presentity) Watcher NOTIFY (PIDF) SUBSCRIBE Watcher

6. Batched NOTIFY Bundled notification (reverse of RLS) –One or more watchers subscribe to multiple presentities in same or another domain –Presentity’s presence server sends a single aggregated NOTIFY To watcher – per watcher aggregation To watcher domain presence server – per domain aggregation –Watcher domain presence server distributes NOTIFY messages to individual watchers –Multiple presence document in same NOTIFY MIME multipart – PIDF concatenation, PIDF-diff concatenation Identifying and sending the changes only  new event package Domain A Domain B NOTIFY (Multiple PIDFs) PUBLISH (PIDF) Presentity Watcher NOTIFY (PIDF) Privacy Filtering Presentity Multiple SUBSCRIBE Watcher

7. Timed Presence General availability information instead of notification for every status change –calendar information only –limit notification to (say) once a day, not for every new appointment –limit range of time  don’t include year’s calendar in each update  combine with partial notification Watcher may turn subscriptions on and off based on Watchers can achieve this using watcher filtering –Currently, watcher filtering does not support timestamp comparison based triggers

8. On-demand Presence Watchers don’t need every presence update of every presentity –only care about small (but changing) subset e.g., those that person is working with currently SUBSCRIBE with expiration interval set to zero –No state created on the server Examples –Google Talk? –Presence-based call routing: fetch presence state using SUBSCRIBE to learn whether and where the callee is available, on demand Reduces traffic in all the three scenarios

9. Adaptive NOTIFY Rate Variation of on-demand presence Adjusting the requested rate of notification –Based on statistical information about multimedia sessions with other users Estimate: 60-70% of the calls/IM messages with 20% of the buddies Nearly 50% of the buddies are rarely contacted –Buddies from old city, previous company, college Hybrid approach –Regular updates –On-demand presence –Adapted rate of notification

10. Traffic Analysis Common NOTIFY for multiple watcher considering only inter-domain steady state –Reduction in traffic by a factor of the average number of watchers per remote domain – total inter-domain watchers/ number of domains for presentity Batched NOTIFY –Reduction in traffic by a factor of number of presentities watched by a single watcher in the remote domain Presentity Domain Watcher Domain NOTIFY PUBLISH (PIDF) Presentity SUBSCRIBE/ NOTIFY Presentity Watchers 3/hr State changes 1,000,000 Presentities ( N p ) SUBSCRIBE Watchers 5 watchers/domain For each presentity 20 watchers from same domain 2-5 domains

11. Conclusion Common NOTIFY for multiple watchers reduces inter-domain traffic by average number of watchers per domain Bundled NOTIFY useful both for access network and inter-domain scenario –Aggregation of multiple presence document or changes to documents Heuristics (timed-presence, on-demand presence) don’t require protocol work –But watcher filtering needs to be extended to improve scaling of timed-status

12. Back Up Slides SIMPLE Problem Statement Traffic with no optimization Traffic with RLS and Entity Tags Issues with common NOTIFY Issues with bundled NOTIFY Example of timed presence Traffic analysis

13. SIMPLE Problem Statement I Presence traffic is divided into 3 parts –Initial SUBSCRIBE/NOTIFY –Steady state (SUBSCRIBE refresh, NOTIFY) –Sign out (SUBSCRIBE/NOTIFY termination) Resource list server and conditional NOTIFY using entity-tags in SUBSCRIBE addresses 2/5 of total inter-domain presence traffic –NOTIFY constitutes 3/5 of total steady state traffic (details in next 3 slides)

14. SIMPLE Problem Statement- II PARAMETERS TO CALCULATE PRESENCE TRAFFIC (A01) Subscription lifetime (hours) (A02) Presence state changes / hour (A03) Subscription refresh interval / hour (A05) Number of dialogs to maintain per watcher (A04) Total federated presentities per watcher (A06) Number of watchers in a federated presence domain (A07) Initial SUBSCRIBE/200 per watcher = A5*2 (message and an OK) (A08) Initial NOTIFY/200 per watcher = A5*2 (message and an OK) (A09) Total initial messages = (A7+A8)*A6 (A10) NOTIFY/200 per watched presentity = (A2*A1*A4*2) (message and an OK) (A11) SUBSCRIBE/200 refreshes = (A1/A3)*A5*2 (message and an OK) (A12) NOTIFY/200 due to subscribe refresh - In a deployment where the notification optimization is not deployed this number will be ((A1/A3)*A5), otherwise it is 0 (A13) Number of steady state messages = (A10+A11+A12)*A6 (A14) SUBSCRIBE termination = A5*2 (message and an OK) (A15) NOTIFY terminated = A5*2 (message and an OK) (A16) Number of sign-out messages = (A7+A8)*A6 (A17) Total messages between domains (both directions where users from domain A subscribe to users from domain B and vice versa)= (A9+A13+A16)*2 (A18) Total number of messages / second = A17/A1/3600 (seconds in hour)

15. Traffic (no optimization) Two presence domains, Each with 20,000 federating users. 4 contacts in the peer domain (A01) Subscription lifetime (hours) 8 (A02) Presence state changes / hour3 (A03) Subscription refresh interval / hour1 (A04) Total federated presentities per watcher4 (A05) Number of dialogs to maintain per watcher4 (A06) Number of watchers in a federated presence domain 20,000 (A07) Initial SUBSCRIBE/200 per watcher8 (A08) Initial NOTIFY/200 per watcher8 (A09) Total initial messages 320,000 (A10) NOTIFY/200 per watched presentity. 192 (A11) SUBSCRIBE/200 refreshes 64 (A12) NOTIFY/200 due to subscribe refresh 64 (A13) Number of steady state messages 6,400,000 (A14) SUBSCRIBE termination 8 (A15) NOTIFY terminated8 (A16) Number of sign-out messages 320,000 (A17) Total messages between domains14,080,000 (A18) Total number of messages / second 489

16. Traffic (With RLS & Entity Tags) Two presence domains, Each with 20000 federating users. 4 contacts in the peer domain (A01) Subscription lifetime (hours) 8 (A02) Presence state changes / hour3 (A03) Subscription refresh interval / hour1 (A04) Total federated presentities per watcher4 (A05) Number of dialogs to maintain per watcher1 (A06) Number of watchers in a federated presence domain 20,000 (A07) Initial SUBSCRIBE/200 per watcher2 (A08) Initial NOTIFY/200 per watcher2 (A09) Total initial messages 80,000 (A10) NOTIFY/200 per watched presentity. 192 (A11) SUBSCRIBE/200 refreshes 16 (A12) NOTIFY/200 due to subscribe refresh 0 (A13) Number of steady state messages 4,160,000 (A14) SUBSCRIBE termination 2 (A15) NOTIFY terminated 2 (A16) Number of sign-out messages 80,000 (A17) Total messages between domains 8,640,000 (A18) Total number of messages / second 300 Reduction in NOTIFY/200 because of SUBSCRIBE refresh and SUBSCRIBE count. NO GAIN in NOTIFY which constituted 3/5 of Steady State Messages.

17. Traffic Optimization Approaches RLS –Access network –Only for SUBSCRIBE messages Conditional SUBSCRIBE –Only for NOTIFY corresponding to SUBSCRIBE refresh SIGCOMP Watcher filtering –Server load + Client support Partial publication and notification –Server load + Client support

18. Proposed Solutions Common NOTIFY for multiple watchers –Useful mainly in inter-domain scenario Batched NOTIFY –Useful both in access network and inter-domain scenarios Timed-status –User can choose to get notified based on calendaring information On-demand presence –Useful in all scenarios Adapting the notification rate

19. Issues with Common NOTIFY for Multiple Watchers Privacy filtering –Per domain filters –Watcher domain filter performs the privacy filter XCAP based privacy filter downloads –Layer 8 negotiation between presence servers of two domains Failure aggregation –Failure of NOTIFY causes subscription termination –Update notification server about delivery failures.

20. Issues with Common NOTIFY for Multiple Watchers Watcher list to watcher’s domain presence server –Watcher domain presence server maintains subscription of all the client’s from its domain to the presentity –Presentity’s domain presence server sends the list of watchers in each NOTIFY message –Watcher’s domain server subscribes using WINFO event package to get the list of watchers from its domain

21. Issues with Batched NOTIFY Presence status update for presentities may not occur simultaneously Watchers need to specify a tolerable delay for receiving presence state update for each presentity –Probably using a watcher filter NOTIFY delivery failure indication and subscription termination –‘Subscription-state’ header in the NOTIFY message is indicates subscription termination Bundled notification doesn’t indicate subscription termination, hence, terminating NOTIFY messages cannot be sent using this mechanism –Notifier needs to know if the NOTIFY was delivered successfully or not

22. Example of Timed-Presence PIDF <presence xmlns="urn:ietf:params:xml:ns:pidf“ xmlns:ts="urn:ietf:params:xml:ns:pidf:timed-status“ entity="pres:someone@columbia.edu"> open <ts:timed-status from="2006-11-04T10:20:00.000-05:00" until="2006-11-08T19:30:00.000-05:00"> closed sip:Vishal@cs.columbia.edu I'll be in San Diego, IETF meeting

23. Traffic Analysis - I NOTIFY traffic –N p x rate x Num_watchers [ local + remote domains] + log-in + log-out –N p x rate x [ 20 + (2 to 5) x 5 ] + initial + final PUBLISH –N p x rate SUBSCRIBE –N p x Num_watchers [ local + remote domains] x refresh rate + initial + final –N p x refresh rate The above is after applying RLS and conditional NOTIFY Presentity Domain Watcher Domain NOTIFY PUBLISH (PIDF) Presentity SUBSCRIBE/ NOTIFY Presentity Watchers 3/hr State changes 1,000,000 Presentities ( N p ) SUBSCRIBE Watchers 5 watchers/domain For each presentity 20 watchers from same domain 2-5 domains

24. Traffic Analysis - II Common NOTIFY for multiple watcher considering only inter-domain steady state –Reduction in traffic by a factor = Average number of watchers per remote domain –For widely distributed inter-domain presence in SIMPLE problem statement 5 federations and 20 federated watchers Number of NOTIFY = ¼ times the number of NOTIFY in steady state. Batched NOTIFY –Reduction in traffic by a factor (at least) = Average number of presentities watched by a single watcher per remote domain

25. Presence Traffic Size Size of SIMPLE message –Size of a single tuple ~ 400 bytes –Size of SIP header ~ 450 bytes –Size of body with single tuple ~ 600 bytes Rate of change of presence = 3/hr Watchers = 20+10 [intra-domain + inter-domain (2 domains with 5 watchers each)] Let number of user be N = 20,000 –PUBLISH = N x 3/hr x [1200 + 600] –SUBSCRIBE = N x 2 (RLS), Ignoring NOTIFY for this –NOTIFY = N x 3/hr x (intra-domain watcher + inter-domain watcher) x [size of NOTIFY + size of 200 OK] Total traffic from server = 0.93 MB /sec Inter-domain traffic from server = 0.3 MB/sec Inter-domain traffic from server ~ 0.055 MB/sec (with Common NOTIFY) Total traffic from server = 0.70 MB/sec (with Common NOTIFY)

26. Server Costs Vs. Network Cost Some optimization techniques incur heavy load on the server –Tradeoff between server scalability vs. traffic scalability Typical presence server scalability (based on Columbia’s presence server performance measurement) –600 messages per second or 2 million messages per hour. Publish processing (composition), subscription handling and notification. –Scalability in terms of number of users: With 1 endpoint per user and 50 buddies per user With 2 status changes per hour per user Approx number of concurrent users supported is 20,000 per server (NOTIFY only considered)