![Page 1: SIMPLE Presence Traffic Optimization and Server Scalability](https://reader033.vdocuments.mx/reader033/viewer/2022050909/5681503d550346895dbe3b46/html5/thumbnails/1.jpg)
SIMPLE Presence Traffic Optimization and Server
Scalability
Vishal Kumar SinghHenning Schulzrinne
Markus IsomakiPiotr Boni
IETF 67, San Diego
![Page 2: SIMPLE Presence Traffic Optimization and Server Scalability](https://reader033.vdocuments.mx/reader033/viewer/2022050909/5681503d550346895dbe3b46/html5/thumbnails/2.jpg)
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
![Page 3: SIMPLE Presence Traffic Optimization and Server Scalability](https://reader033.vdocuments.mx/reader033/viewer/2022050909/5681503d550346895dbe3b46/html5/thumbnails/3.jpg)
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
![Page 4: SIMPLE Presence Traffic Optimization and Server Scalability](https://reader033.vdocuments.mx/reader033/viewer/2022050909/5681503d550346895dbe3b46/html5/thumbnails/4.jpg)
Traffic Reduction Vs. Server LoadTechnique Access (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
![Page 5: SIMPLE Presence Traffic Optimization and Server Scalability](https://reader033.vdocuments.mx/reader033/viewer/2022050909/5681503d550346895dbe3b46/html5/thumbnails/5.jpg)
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 ADomain B
NOTIFY(PIDF + subscriber list)PUBLISH
(PIDF) Presentity
Privacy Filtering
SUBSCRIBE (To same presentity)
Watcher
NOTIFY(PIDF)
SUBSCRIBE
Watcher
Watcher
Watcher
![Page 6: SIMPLE Presence Traffic Optimization and Server Scalability](https://reader033.vdocuments.mx/reader033/viewer/2022050909/5681503d550346895dbe3b46/html5/thumbnails/6.jpg)
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 ADomain B
NOTIFY(Multiple PIDFs)
PUBLISH(PIDF)
Presentity
Watcher
NOTIFY(PIDF)
Privacy Filtering
Presentity
Presentity
MultipleSUBSCRIBE SUBSCRIBE
Watcher
Watcher
Watcher
![Page 7: SIMPLE Presence Traffic Optimization and Server Scalability](https://reader033.vdocuments.mx/reader033/viewer/2022050909/5681503d550346895dbe3b46/html5/thumbnails/7.jpg)
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
![Page 8: SIMPLE Presence Traffic Optimization and Server Scalability](https://reader033.vdocuments.mx/reader033/viewer/2022050909/5681503d550346895dbe3b46/html5/thumbnails/8.jpg)
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
![Page 9: SIMPLE Presence Traffic Optimization and Server Scalability](https://reader033.vdocuments.mx/reader033/viewer/2022050909/5681503d550346895dbe3b46/html5/thumbnails/9.jpg)
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
![Page 10: SIMPLE Presence Traffic Optimization and Server Scalability](https://reader033.vdocuments.mx/reader033/viewer/2022050909/5681503d550346895dbe3b46/html5/thumbnails/10.jpg)
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
PresentityDomain
Watcher Domain
NOTIFY
PUBLISH(PIDF)
Presentity
SUBSCRIBE/ NOTIFY
Presentity
Presentity
Watchers
3/hr State changes
1,000,000Presentities (Np)
SUBSCRIBE
Watchers
5 watchers/domainFor each presentity
20 watchers from same domain
2-5 domains
![Page 11: SIMPLE Presence Traffic Optimization and Server Scalability](https://reader033.vdocuments.mx/reader033/viewer/2022050909/5681503d550346895dbe3b46/html5/thumbnails/11.jpg)
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
![Page 12: SIMPLE Presence Traffic Optimization and Server Scalability](https://reader033.vdocuments.mx/reader033/viewer/2022050909/5681503d550346895dbe3b46/html5/thumbnails/12.jpg)
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
![Page 13: SIMPLE Presence Traffic Optimization and Server Scalability](https://reader033.vdocuments.mx/reader033/viewer/2022050909/5681503d550346895dbe3b46/html5/thumbnails/13.jpg)
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)
![Page 14: SIMPLE Presence Traffic Optimization and Server Scalability](https://reader033.vdocuments.mx/reader033/viewer/2022050909/5681503d550346895dbe3b46/html5/thumbnails/14.jpg)
SIMPLE Problem Statement- IIPARAMETERS 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)
![Page 15: SIMPLE Presence Traffic Optimization and Server Scalability](https://reader033.vdocuments.mx/reader033/viewer/2022050909/5681503d550346895dbe3b46/html5/thumbnails/15.jpg)
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
![Page 16: SIMPLE Presence Traffic Optimization and Server Scalability](https://reader033.vdocuments.mx/reader033/viewer/2022050909/5681503d550346895dbe3b46/html5/thumbnails/16.jpg)
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.
![Page 17: SIMPLE Presence Traffic Optimization and Server Scalability](https://reader033.vdocuments.mx/reader033/viewer/2022050909/5681503d550346895dbe3b46/html5/thumbnails/17.jpg)
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
![Page 18: SIMPLE Presence Traffic Optimization and Server Scalability](https://reader033.vdocuments.mx/reader033/viewer/2022050909/5681503d550346895dbe3b46/html5/thumbnails/18.jpg)
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
![Page 19: SIMPLE Presence Traffic Optimization and Server Scalability](https://reader033.vdocuments.mx/reader033/viewer/2022050909/5681503d550346895dbe3b46/html5/thumbnails/19.jpg)
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.
![Page 20: SIMPLE Presence Traffic Optimization and Server Scalability](https://reader033.vdocuments.mx/reader033/viewer/2022050909/5681503d550346895dbe3b46/html5/thumbnails/20.jpg)
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
![Page 21: SIMPLE Presence Traffic Optimization and Server Scalability](https://reader033.vdocuments.mx/reader033/viewer/2022050909/5681503d550346895dbe3b46/html5/thumbnails/21.jpg)
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
![Page 22: SIMPLE Presence Traffic Optimization and Server Scalability](https://reader033.vdocuments.mx/reader033/viewer/2022050909/5681503d550346895dbe3b46/html5/thumbnails/22.jpg)
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:[email protected]"><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:[email protected]</contact> <note>I'll be in San Diego, IETF meeting</note></tuple></presence>
![Page 23: SIMPLE Presence Traffic Optimization and Server Scalability](https://reader033.vdocuments.mx/reader033/viewer/2022050909/5681503d550346895dbe3b46/html5/thumbnails/23.jpg)
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
PresentityDomain
Watcher Domain
NOTIFY
PUBLISH(PIDF)
Presentity
SUBSCRIBE/ NOTIFY
Presentity
Presentity
Watchers
3/hr State changes
1,000,000Presentities (Np)
SUBSCRIBE
Watchers
5 watchers/domainFor each presentity
20 watchers from same domain
2-5 domains
![Page 24: SIMPLE Presence Traffic Optimization and Server Scalability](https://reader033.vdocuments.mx/reader033/viewer/2022050909/5681503d550346895dbe3b46/html5/thumbnails/24.jpg)
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
![Page 25: SIMPLE Presence Traffic Optimization and Server Scalability](https://reader033.vdocuments.mx/reader033/viewer/2022050909/5681503d550346895dbe3b46/html5/thumbnails/25.jpg)
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)
![Page 26: SIMPLE Presence Traffic Optimization and Server Scalability](https://reader033.vdocuments.mx/reader033/viewer/2022050909/5681503d550346895dbe3b46/html5/thumbnails/26.jpg)
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)