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)