Simple presence traffic optimization and server scalability
This presentation is the property of its rightful owner.
Sponsored Links
1 / 26

SIMPLE Presence Traffic Optimization and Server Scalability PowerPoint PPT Presentation


  • 51 Views
  • Uploaded on
  • Presentation posted in: General

SIMPLE Presence Traffic Optimization and Server Scalability. Vishal Kumar Singh Henning Schulzrinne Markus Isomaki Piotr Boni IETF 67, San Diego. Presence Problems Revisited.

Download Presentation

SIMPLE Presence Traffic Optimization and Server Scalability

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Simple presence traffic optimization and server scalability

SIMPLE Presence Traffic Optimization and Server Scalability

Vishal Kumar Singh

Henning Schulzrinne

Markus Isomaki

Piotr Boni

IETF 67, San Diego


Presence problems revisited

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

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

Traffic Reduction Vs. Server Load

(+) improves, (-) worsens


Common notify for multiple watchers

Watcher

SUBSCRIBE

(To same presentity)

SUBSCRIBE

NOTIFY

(PIDF + subscriber list)

Watcher

PUBLISH

(PIDF)

Presentity

Privacy Filtering

Domain A

Domain B

Watcher

NOTIFY

(PIDF)

Watcher

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


Batched notify

Multiple

SUBSCRIBE

Watcher

SUBSCRIBE

PUBLISH

(PIDF)

Presentity

Presentity

NOTIFY

(Multiple PIDFs)

Privacy Filtering

Watcher

Presentity

NOTIFY

(PIDF)

Watcher

Domain A

Domain B

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


Timed presence

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

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

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

SUBSCRIBE/

NOTIFY

Watchers

Presentity

NOTIFY

Presentity

Domain

Watcher Domain

5 watchers/domain

For each presentity

3/hr

State changes

Presentity

Watchers

2-5 domains

20 watchers from same domain

1,000,000

Presentities (Np)

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


  • Conclusion

    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

    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

    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

    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

    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 / hour3

    • (A03) Subscription refresh interval / hour1

    • (A04) Total federated presentities per watcher4

    • (A05) Number of dialogs to maintain per watcher4

    • (A06) Number of watchers in a federated presence domain 20,000

    • (A07) Initial SUBSCRIBE/200 per watcher8

    • (A08) Initial NOTIFY/200 per watcher8

    • (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 terminated8

    • (A16) Number of sign-out messages 320,000

    • (A17) Total messages between domains14,080,000

    • (A18) Total number of messages / second 489


    Traffic with rls entity tags

    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 / hour3

    • (A03) Subscription refresh interval / hour1

    • (A04) Total federated presentities per watcher4

    • (A05) Number of dialogs to maintain per watcher1

    • (A06) Number of watchers in a federated presence domain 20,000

    • (A07) Initial SUBSCRIBE/200 per watcher2

    • (A08) Initial NOTIFY/200 per watcher2

    • (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

    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 solutions1

    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

    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 watchers1

    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

    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

    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

    SUBSCRIBE

    SUBSCRIBE/

    NOTIFY

    Watchers

    Presentity

    NOTIFY

    Presentity

    Domain

    Watcher Domain

    5 watchers/domain

    For each presentity

    3/hr

    State changes

    Presentity

    Watchers

    2-5 domains

    20 watchers from same domain

    1,000,000

    Presentities (Np)

    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


    Traffic analysis ii

    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

    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

    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)


  • Login