1 / 26

SIMPLE Presence Traffic Optimization and Server Scalability

This paper discusses the challenges of inter-domain presence traffic and proposes solutions such as common NOTIFY for multiple watchers, batched NOTIFY, timed-status, on-demand presence, and adapting the notification rate to reduce traffic and improve server scalability.

cgary
Download Presentation

SIMPLE Presence Traffic Optimization and Server Scalability

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 (+) improves, (-) worsens

  5. Watcher SUBSCRIBE (To same presentity) SUBSCRIBE NOTIFY (PIDF + subscriber list) Watcher PUBLISH (PIDF) Presentity Privacy Filtering Domain A Domain B Watcher NOTIFY (PIDF) Watcher 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

  6. Multiple SUBSCRIBE Watcher SUBSCRIBE PUBLISH (PIDF) Presentity Presentity NOTIFY (Multiple PIDFs) Privacy Filtering Watcher Presentity NOTIFY (PIDF) Watcher Domain A Domain B Watcher 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

  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 <timed-status> • 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. PUBLISH (PIDF) Presentity SUBSCRIBE SUBSCRIBE/ NOTIFY Watchers Presentity NOTIFY Presentity Domain Watcher Domain 5 watchers/domain For each presentity 3/hr State changes Presentity Watchers 2-5 domains 20 watchers from same domain 1,000,000 Presentities (Np) 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

  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 / hour 3 • (A03) Subscription refresh interval / hour 1 • (A04) Total federated presentities per watcher 4 • (A05) Number of dialogs to maintain per watcher 4 • (A06) Number of watchers in a federated presence domain 20,000 • (A07) Initial SUBSCRIBE/200 per watcher 8 • (A08) Initial NOTIFY/200 per watcher 8 • (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 terminated 8 • (A16) Number of sign-out messages 320,000 • (A17) Total messages between domains 14,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 / hour 3 • (A03) Subscription refresh interval / hour 1 • (A04) Total federated presentities per watcher 4 • (A05) Number of dialogs to maintain per watcher 1 • (A06) Number of watchers in a federated presence domain 20,000 • (A07) Initial SUBSCRIBE/200 per watcher 2 • (A08) Initial NOTIFY/200 per watcher 2 • (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"> <tuple id="c8dqui"> <status> <basic>open</basic> </status> <ts:timed-status from="2006-11-04T10:20:00.000-05:00" until="2006-11-08T19:30:00.000-05:00"> <ts:basic>closed</ts:basic> </ts:timed-status> <contact>sip:Vishal@cs.columbia.edu</contact> <note>I'll be in San Diego, IETF meeting</note> </tuple> </presence>

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

  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)

More Related