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
Technique
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

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

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
Privacy Filtering
Multiple
SUBSCRIBE

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. 20 watchers from same domain
Traffic Analysis
Presentity
Domain
Watcher Domain
NOTIFY
PUBLISH
(PIDF)
SUBSCRIBE/
Watchers
3/hr
State changes
1,000,000
Presentities (Np)
SUBSCRIBE
5 watchers/domain
For each presentity
20 watchers from same domain
2-5 domains
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)
(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 ,000
(A07) Initial SUBSCRIBE/200 per watcher 8
(A08) Initial NOTIFY/200 per watcher 8
(A09) Total initial messages ,000
(A10) NOTIFY/200 per watched presentity
(A11) SUBSCRIBE/200 refreshes
(A12) NOTIFY/200 due to subscribe refresh
(A13) Number of steady state messages 6,400,000
(A14) SUBSCRIBE termination
(A15) NOTIFY terminated
(A16) Number of sign-out messages ,000
(A17) Total messages between domains 14,080,000
(A18) Total number of messages / second

16. Traffic (With RLS & Entity Tags)
Two presence domains, Each with federating users. 4 contacts in the peer domain
(A01) Subscription lifetime (hours)
(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 ,000
(A07) Initial SUBSCRIBE/200 per watcher 2
(A08) Initial NOTIFY/200 per watcher 2
(A09) Total initial messages ,000
(A10) NOTIFY/200 per watched presentity
(A11) SUBSCRIBE/200 refreshes
(A12) NOTIFY/200 due to subscribe refresh
(A13) Number of steady state messages ,160,000
(A14) SUBSCRIBE termination
(A15) NOTIFY terminated
(A16) Number of sign-out messages ,000
(A17) Total messages between domains ,640,000
(A18) Total number of messages / second
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 Batched NOTIFY
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“
<tuple id="c8dqui">
<status>
<basic>open</basic>
</status>
<ts:timed-status from=" T10:20: :00"
until=" T19:30: :00">
<ts:basic>closed</ts:basic>
</ts:timed-status>
<note>I'll be in San Diego, IETF meeting</note>
</tuple>
</presence>

23. 20 watchers from same domain
Traffic Analysis - I
Presentity
Domain
Watcher Domain
NOTIFY
PUBLISH
(PIDF)
SUBSCRIBE/
Watchers
3/hr
State changes
1,000,000
Presentities (Np)
SUBSCRIBE
5 watchers/domain
For each presentity
20 watchers from same domain
2-5 domains
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 = [intra-domain + inter-domain (2 domains with 5 watchers each)]
Let number of user be N = 20,000
PUBLISH = N x 3/hr x [ ]
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 ~ 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)