Transcript SIMPLE Presence Traffic Optimization and Server Scalability Vishal Kumar Singh

SIMPLE Presence Traffic
Optimization and Server
Scalability
Vishal Kumar Singh
Henning Schulzrinne
Markus Isomaki
Piotr Boni
IETF 67, San Diego
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
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
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
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
Watcher
SUBSCRIBE
(To same presentity)
Presentity
PUBLISH
(PIDF)
Domain A
NOTIFY
(PIDF + subscriber list)
SUBSCRIBE
Watcher
Domain B
Privacy
Filtering
Watcher
NOTIFY
(PIDF)
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
Presentity
Watcher
Multiple
SUBSCRIBE
PUBLISH
(PIDF)
SUBSCRIBE
Watcher
Presentity
Presentity
Domain B
Domain A
NOTIFY
(Multiple PIDFs)
Privacy
Filtering
Watcher
NOTIFY
(PIDF)
Watcher
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
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
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
Traffic Analysis
PUBLISH
(PIDF)
Presentity
SUBSCRIBE/
NOTIFY
Presentity
Domain
Presentity
Presentity
SUBSCRIBE
3/hr
State changes
Watcher
Domain
NOTIFY
5 watchers/domain
For each presentity
Watchers
20 watchers from
same domain
1,000,000
Presentities (Np)
Watchers
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
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
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
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)
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)
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
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.
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
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
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.
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
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
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>
Traffic Analysis - I
PUBLISH
(PIDF)
Presentity
3/hr
State changes
1,000,000
Presentities (Np)
•
•
•
•
SUBSCRIBE/
NOTIFY
Presentity
Domain
Presentity
Presentity
SUBSCRIBE
Watcher
Domain
Watchers
NOTIFY
5 watchers/domain
For each presentity
Watchers
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
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
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)
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)