SIMPLE Presence Traffic Optimization and Server Scalability

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)
• Presentitys presence server sends a single
  NOTIFY to watchers domain presence server
• Watcher domain presence server distributes it to
  individual watchers
• Issues
• Privacy filtering
• Failure aggregation
• Watcher list to watchers domain presence server

6
Batched NOTIFY

• Bundled notification (reverse of RLS)
• One or more watchers subscribe to multiple
  presentities in same or another domain
• Presentitys 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

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 ? dont include years
  calendar in each update ? combine with partial
  notification
• Watcher may turn subscriptions on and off based
  on lttimed-statusgt
• Watchers can achieve this using watcher filtering
• Currently, watcher filtering does not support
  timestamp comparison based triggers

8
On-demand Presence

• Watchers dont 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
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

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)
  dont 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 A52
  (message and an OK)
• (A08) Initial NOTIFY/200 per watcher A52
  (message and an OK)
• (A09) Total initial messages (A7A8)A6
• (A10) NOTIFY/200 per watched presentity
  (A2A1A42) (message and an OK)
• (A11) SUBSCRIBE/200 refreshes (A1/A3)A52
  (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
  (A10A11A12)A6
• (A14) SUBSCRIBE termination A52 (message and
  an OK)
• (A15) NOTIFY terminated A52 (message and an
  OK)
• (A16) Number of sign-out messages (A7A8)A6
• (A17) Total messages between domains (both
  directions where users from domain A subscribe to
  users from domain B and vice versa)
  (A9A13A16)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) 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

16
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

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
• 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 watchers domain presence server
• Watcher domain presence server maintains
  subscription of all the clients from its domain
  to the presentity
• Presentitys domain presence server sends the
  list of watchers in each NOTIFY message
• Watchers 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 doesnt 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

• ltpresence xmlns"urnietfparamsxmlnspidf
• xmlnsts"urnietfparamsxmlnspidftimed-status
  
• entity"pressomeone_at_columbia.edu"gt
• lttuple id"c8dqui"gt
• ltstatusgt
• ltbasicgtopenlt/basicgt
• lt/statusgt
• lttstimed-status from"2006-11-04T102000.000
  -0500"
• until"2006-11-08T193000.000-0500"gt
  
• lttsbasicgtclosedlt/tsbasicgt
• lt/tstimed-statusgt
• ltcontactgtsipVishal_at_cs.columbia.edult/contactgt
• ltnotegtI'll be in San Diego, IETF
  meetinglt/notegt
• lt/tuplegt
• lt/presencegt

23
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

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 2010 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)

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
  Columbias 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)