View
217
Download
0
Category
Tags:
Preview:
Citation preview
SIMPLE Presence Traffic Optimization and Server
Scalability
Vishal Kumar SinghHenning Schulzrinne
Markus IsomakiPiotr 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 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
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
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
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
• 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
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- 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)
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: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>
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
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)
Recommended