Simple presence traffic optimization and server scalability
Download
1 / 26

SIMPLE Presence Traffic Optimization and Server Scalability - PowerPoint PPT Presentation


  • 72 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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha

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

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

(+) improves, (-) worsens


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


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

  • 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


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

    • 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 / 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)

    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

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


    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

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


    ad
  • Login