One document matched: draft-houri-simple-interdomain-scaling-optimizations-00.txt
SIMPLE WG A. Houri (Ed.)
Internet-Draft IBM
Intended status: Standards Track V. Singh
Expires: January 2, 2008 H. Schulzrinne
Columbia U.
S. Parameswar
Microsoft Corporation
E. Aoki
AOL LLC
July 1, 2007
Scaling Optimizations for Presence in SIP/SIMPLE
draft-houri-simple-interdomain-scaling-optimizations-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 2, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The document suggests various optimizations for presence that uses
the SIP/SIMPLE protocol. The suggestions are based on a separate
Houri (Ed.), et al. Expires January 2, 2008 [Page 1]
Internet-Draft Scaling Optimizations for Presence July 2007
document that contains scaling analysis and requirements. The
current document reviews only suggestions that are not yet part of
the work of the various SIP working groups while approved and in-work
optimizations are reviewed in the scaling document. The intention
here is to keep these suggestions at this document as a place holder
until a set of requirements will be discussed and accepted and the
work on optimizations will commence.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Possible Optimizations . . . . . . . . . . . . . . . . . . . . 3
2.1. Common NOTIFY for multiple watchers . . . . . . . . . . . 3
2.1.1. Privacy filtering . . . . . . . . . . . . . . . . . . 4
2.1.2. NOTIFY failure aggregation . . . . . . . . . . . . . . 4
2.1.3. Transferring the watcher list . . . . . . . . . . . . 5
2.1.4. Message flow example . . . . . . . . . . . . . . . . . 5
2.1.5. SIP message examples for common NOTIFY . . . . . . . . 7
2.2. Aggregation of NOTIFY messages (Batched notification) . . 8
2.2.1. Extracting and sending individual NOTIFY using
Aggregated NOTIFY message body . . . . . . . . . . . . 8
2.2.2. Subscription termination and failure indication in
NOTIFY delivery . . . . . . . . . . . . . . . . . . . 9
2.2.3. Message flow example . . . . . . . . . . . . . . . . . 9
2.2.4. SIP message flow example for batched notification . . 11
2.3. Timed presence . . . . . . . . . . . . . . . . . . . . . . 13
2.4. On-Demand presence (Fetch or Pull Model) . . . . . . . . . 14
2.5. Adapting the subscription rate . . . . . . . . . . . . . . 14
3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Normative References . . . . . . . . . . . . . . . . . . . 16
6.2. Informational References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Houri (Ed.), et al. Expires January 2, 2008 [Page 2]
Internet-Draft Scaling Optimizations for Presence July 2007
1. Introduction
The document gathers various optimizations for enabling better
scaling of presence traffic between domains. The optimizations were
suggested during the work on the scaling analysis document [6]. The
intention by this document at this stage is to serve as a place
holder for the various optimizations until there will be agreement on
the requirements for scaling and the work on the actual optimizations
will start.
Note that most of the optimizations that are suggested here were
suggested by Vishal Singh and Henning Schulzrine.
The term presence domain or presence system appears in the document
several time. By this term we refer to a presence server that
provides presence subscription and notification services to its
users. The system can be a system that is deployed in a small
enterprise or in a very large consumer network.
2. Possible Optimizations
This section contains suggested techniques which can be employed by
the presence server and clients to reduce presence traffic,
specifically, on inter-domain links. Several techniques proposed and
briefly described here. The quantitative analysis of these
techniques is not fully done yet and will be present in a future
version of this document. Protocol mechanisms to employ these
techniques are described briefly. This section is intended to help
us evaluate and decide if such techniques should become a part of
SIMPLE protocol suite.
2.1. Common NOTIFY for multiple watchers
When multiple watchers from a domain (for example, domain B)
SUBSCRIBE to a presentity in another domain (for example, domain A),
a single NOTIFY [2] per presentity in domain B can be sent to domain
B's presence server (PS). The presence server in domain B can then
distribute the NOTIFY messages to each of the watchers. This
eliminates the need to send individual NOTIFY messages from domain
A's presence server to each watcher in domain B. The presence server
and resource list server (RLS) are assumed to be co--located as a
result of which NOTIFY messages are sent to presence server (RLS) in
domain B rather then delivered directly to the watchers of domain B.
The server distributes the NOTIFY message to a list of watchers based
on a single NOTIFY message received from another presence agent.
There are three main issues namely, privacy filtering, failure
Houri (Ed.), et al. Expires January 2, 2008 [Page 3]
Internet-Draft Scaling Optimizations for Presence July 2007
aggregation and transfer of watcher list to watcher's domain presence
server to distribute NOTIFY. We discuss these in next subsections.
2.1.1. Privacy filtering
Privacy filtering is typically done by presentity's presence server.
We propose that presentity's privacy filtering task be handled by
watcher domain's presence server, in this case domain B's presence
server. There are two possibilities about privacy filtering rules of
the presentity as described below.
Per domain privacy filters: Presentity in domain A having same
privacy filter rules for all the watchers in domain B. In other
words, there is a domain level privacy filter specified by the
presentity for users from domain B. Privacy filtering can be done by
the presence server in domain A and a single NOTIFY can be sent from
presence server in domain B.
Per watcher privacy filters: Presentity in domain A has different
privacy filter rules for different watchers in domain B. Since,
presentity in domain A has different privacy filtering rules for
watchers from domain B, the privacy filter has to be applied by the
presence server in domain B. Complete presence state information
needs to be sent from the presentity's domain to watcher's domain.
Delegating the task of privacy filtering doesn't compromise any
additional privacy information when compared with normal operations.
The model is very similar to e-mail trust model. Transfer of a
single NOTIFY from presentity's domain to watcher's domain implies
that the presence server in watcher's domain receives that
information and can potentially distribute it to unauthorized
watchers. Thus, presentity implicitly trusts the presence server in
its own domain as well as watcher's domain. The proposed mechanism
extends such a trust to the presence server in domain B so that it
performs the privacy filtering on behalf of presentity in domain A.
One potential issue is when presence server in domain A encrypts the
presence document for each watcher using SMIME in which case the
watcher domain PS cannot perform privacy filtering. Hence, this kind
of privacy filtering requires a layer 8 security negotiation between
the presence servers of the two domains
2.1.2. NOTIFY failure aggregation
The success or failure of NOTIFY message by the server changes the
subscription status of the watcher on the presentity's presence
server. Hence, to update about failure of NOTIFY delivery, domain
B's presence server aggregates the success and failure responses for
each watcher and send it to the presence server in domain A.
Houri (Ed.), et al. Expires January 2, 2008 [Page 4]
Internet-Draft Scaling Optimizations for Presence July 2007
Alternatively, application level negative acknowledgement can be
used.
2.1.3. Transferring the watcher list
In order to distribute the NOTIFY message received from domain A, the
watcher domain presence server requires the list of watchers in its
domain for that presentity. We propose the following ways to achieve
this.
o Watcher list sent in NOTIFY message: The watcher list can be sent
from domain A's presence server to domain B's presence server in
each NOTIFY message. The NOTIFY is then distributed to each
watcher in the list. This has a disadvantage when the number of
watcher's from domain B is very large, every NOTIFY message
increases in size proportionately. An alternative could be
sending the complete list initially and sending changes to the
list using the XML-patch operations [7] specified in partial-
publication and maintaining the list on presence server in domain
B. Sending watcher- list and distributing it, is similar to multi
recipient messages i.e., [8], and SUBSCRIBE contained list or
Exploders.
o Watcher list obtained by subscribing to WINFO [3]package: In this
technique, the watcher's domain (domain B) presence server obtains
the watcher list from domain A's PS. It also receives any changes
to the watcher-list from domain A's PS by subscribing to the
presentity with presence.winfo event package. The domain A's PS
maintains and updates the watcher list as a part of its normal
operation. The updates are sent whenever watcher list changes.
They contain information about watchers from domain B only.
o Watcher list created on subscriber's presence server: The watcher
domain presence server maintains and updates the list of watchers
per presentity based on the SUBSCRIBE requests from these
watchers. Such a list is like a resource list of watchers per
presentity in watcher's domain built dynamically based on
SUBSCRIBE request which are not directly sent to presentity's PS.
2.1.4. Message flow example
Below is the message flow diagram of how the system may work.
Houri (Ed.), et al. Expires January 2, 2008 [Page 5]
Internet-Draft Scaling Optimizations for Presence July 2007
Watchers Domain B Domain A Presentity
(userB1, B2) (PS + RLS) (PS + RLS) (userA1, A2)
-----------------------------------------------------------
1 | SUBSCRIBE t:userA1 | | |
2 |--------------------->| | |
3 | f:userB1) | SUBSCRIBE | |
4 |<-------200OK---------|------------------>| |
5 | |<-----200OK -------| |
6 | | | |
7 | | NOTIFY | |
8 | |<------------------| |
9 | NOTIFY (f:userA1 |------200OK------->| |
10 |<---------------------| | |
11 | t:userB1) | | |
12 |---------200 OK------>| XCAP Filter B1 | |
13 | |<-----------------<| |
14 | | | |
15 | SUBSCRIBE t:userA1 | | |
16 |--------------------->| SUBSCRIBE | |
17 | f:userB2) |------------------>| |
18 |<-------200OK---------|<-----200OK -------| |
19 | | | |
20 | | NOTIFY | |
21 | NOTIFY (f:userA1 |<------------------| |
22 |<---------------------|------200OK------->| |
23 | t:userB2) | | |
24 |---------200 OK------>| XCAP Filter B2 | |
25 | |<-----------------<| PUBLISH |
26 | | |<-------------|
27 | | |------200OK ->|
28 | | NOTIFY (f:userA1 | |
29 | |<------------------| |
30 | | t: userB1, UserB2)| |
31 | NOTIFY (f:userA1 |------200OK------->| |
32 |<---------------------| | |
33 | t:userB1) | | |
34 |---------200 OK------>| | |
35 | NOTIFY (f:userA1 | | |
36 |<---------------------| | |
37 | t:userB2) | | PUT XCAP |
38 |---------200 OK------>| |<-------------|
39 | | NOTIFY (filter) <update filters>
40 | |<------------------| |
41 | |------200OK------->| |
42 | | | |
43 | | XCAP Filter B2 | |
44 | |<-----------------<| |
-----------------------------------------------------------
Houri (Ed.), et al. Expires January 2, 2008 [Page 6]
Internet-Draft Scaling Optimizations for Presence July 2007
Figure 1: Example message flow for common NOTIFY for watchers in a
domain
We can see in figure above that a single NOTIFY from userA1@
domainA.com is sent to watchers {userB1, userB2}@domainB.com. Also,
we can see that a change in privacy filter rule causes a NOTIFY which
triggers an XCAP-based download of privacy filtering rules by domain
B PS.
2.1.5. SIP message examples for common NOTIFY
The following NOTIFY message contains the list of watchers and the
presence document of the presentity. The RLS /presence server in B
will distribute it to all the watchers in the list.
NOTIFY sip:rlserver.domainB.com SIP/2.0
Via: SIP/2.0/TCP rlsserver.domainA.com;branch=z9hG4bK4EPlfSFQK1
Max-Forwards: 70
From: <sip:userA1@domainA.com>;tag=zpNctbZq
To: <sip:rlsserver@domainB.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@domainA.com
CSeq: 997935769 NOTIFY
Contact: <sip:rlsserver.domainA.com>
Event: presence
Subscription-State: active;expires=7200
Content-Type: multipart/related;type="resource-lists+xml";
start="<2BEI83@rlsserver.domainA.com >";
boundary=" tuLLl3lDyPZX0GMr2YOo "
Content-Length: 2014
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID: <2BEI83@rlsserver.domainA. com>
Content-Type: application/resource-lists+xml; charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<list>
<entry uri="sip:userB1@domainB.com" />
<entry uri="sip:userB2@domainB.com" />
</list>
</resource-lists>
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID: <2BEI83@rlsserver.domainA.example.com >
Content-Type:type="application/pidf+xml;charset="UTF-8"
start="<AAAA@rlsserver.domainB.example.com >";
boundary=" TfZxoxgAvLqgj4wRWPDL"
Houri (Ed.), et al. Expires January 2, 2008 [Page 7]
Internet-Draft Scaling Optimizations for Presence July 2007
--TfZxoxgAvLqgj4wRWPDL
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:userA1@domainA.com">
<tuple id="z98075">
<status>
<basic>closed</basic>
</status>
</tuple>
</presence>
--TfZxoxgAvLqgj4wRWPDL--
Figure 2: SIP message examples using common notify technique
2.2. Aggregation of NOTIFY messages (Batched notification)
When a watcher from a domain (for example domain B) SUBSCRIBE to
multiple presentities in another domain (domain A), domain A's
presence server can aggregate the notification messages and send them
together as a single NOTIFY message to the presence server in domain
B. The presence server in domain B can then deliver the message to
the watcher or create individual NOTIFY messages for different
watchers and send it to them. This reduces the number of NOTIFY/ 200
OK messages on the inter-domain link as well as access network. This
aggregation of NOTIFY can be done on per watcher or per domain basis.
The RLS specification describes aggregation and throttling however,
leaves it open to the implementers.
One problem in aggregation is that presence status update for
presentities may not occur simultaneously. Hence, in order to bundle
the NOTIFY messages for each watcher or domain, the presence server
may have to delay some of the NOTIFY messages. One approach to solve
this issue could be that the watcher specifies a tolerable delay for
receiving presence state update of the presentities. The watcher can
specify this delay value using the watcher filtering mechanism or a
SIP-header extension in the SUBSCRIBE message. The presence server
in presentity's domain can hold the NOTIFY message only for the
amount of time specified.
2.2.1. Extracting and sending individual NOTIFY using Aggregated NOTIFY
message body
The aggregation of NOTIFY bodies originating from different
presentities to a single NOTIFY body works on the basis of Multipart
(MIME). Bundling of notification imply aggregating multiple NOTIFY
bodies destined to a single watcher (or watcher domain) into a single
Houri (Ed.), et al. Expires January 2, 2008 [Page 8]
Internet-Draft Scaling Optimizations for Presence July 2007
NOTIFY and delivered to watcher domain presence server. If all the
NOTIFY messages are destined to a single watcher, the watcher domain
presence server delivers the message directly. Otherwise, the server
extracts multiple presence bodies (PIDF) from the received NOTIFY
message. Each presence document (PIDF [4]) contains an entity field
which uniquely identifies the presentity; hence, there is no
dependency on SIP headers to construct individual NOTIFY messages for
delivering them to watchers. Delivering bundled NOTIFY messages
reduces the traffic on access network as well.
2.2.2. Subscription termination and failure indication in NOTIFY
delivery
The Subscription-state header in the NOTIFY message is used to
indicate subscription termination to a watcher. Bundled notification
doesn't indicate subscription termination, hence, terminating NOTIFY
messages cannot be sent using this mechanism. Additionally, the
notifier needs to know if the NOTIFY was delivered successfully or
not. The subscription can be terminated if NOTIFY is not delivered
successfully. The presence server in domain B should aggregate and
send to PS in domain A the success or failure of NOTIFY messages.
The advantage is observed when a single watcher subscribes to
multiple presentities from another domain. The delay tolerance
interval specified by the watcher should be good enough so that
multiple NOTIFY messages can be bundled or aggregated. The reduction
in traffic can be seen under two scenarios, i.e., (i) when watcher
logs in and subscribes to all the presentities. The NOTIFY from
multiple presentities can be bundled and delivered as a single
message to the watcher. (ii) In steady state, the gain can be
calculated based on the delay tolerance interval, number of
presentities to which a watcher is subscribed, probability of these
presentities changing state in that interval. With increase in
number of presentities, the probability that presentities will update
presence state within a time difference of delay tolerance interval
will increase and hence the inter domain traffic reduction (gain)
will increase.
2.2.3. Message flow example
The message flow diagram in Figure below assumes watchers in domain B
(userB1, userB2) and presentities in domain A (userA1, userA2). We
can see that when userA1 and userA2 send PUBLISH, a single NOTIFY is
sent from domain A to domain B, which is converted to individual
NOTIFY messages by presence server at domain B.
Houri (Ed.), et al. Expires January 2, 2008 [Page 9]
Internet-Draft Scaling Optimizations for Presence July 2007
Watchers Domain B Domain A Presentity
(userB1,B2) (PS + RLS) (PS + RLS) (userA1,A2)
-----------------------------------------------------------
1 | SUBSCRIBE t:userA1 | | |
2 |--------------------->| | |
3 | f:userB1) | | |
4 |<-------200OK---------| SUBSCRIBE | |
5 | |------------------>| |
6 | |<-----200OK -------| |
7 | | | |
8 | | NOTIFY | |
9 | |<------------------| |
10 | NOTIFY (f:userA1 |------200OK------->| |
11 |<---------------------| | |
12 | t:userB1) | | |
13 |---------200 OK------>| | |
14 | | | |
15 | | | |
16 | SUBSCRIBE t:userA2 | | |
17 |--------------------->| SUBSCRIBE | |
18 | f:userB1) |------------------>| |
19 |<-------200OK---------|<-----200OK -------| |
20 | | | |
21 | | NOTIFY | |
22 | NOTIFY (f:userA2 |<------------------| |
23 |<---------------------|------200OK------->| |
24 | t:userB1) | | |
25 |---------200 OK------>| | PUBLISH |
26 | | userA1|<-------------|
27 | | |------200OK ->|
28 | | | |
29 | | | PUBLISH |
30 | | userA2|<-------------|
31 | | |------200OK ->|
32 | | | |
33 | | NOTIFY (multipart)| |
34 | |<------------------| |
35 | NOTIFY (f:userA1 | (userA1,userA2) | |
36 |<---------------------|------200OK------->| |
37 | t:userB1) | | |
38 |---------200 OK------>| | |
39 | | | |
40 | | | |
41 | NOTIFY (f:userA1 | | |
42 |<---------------------| | |
43 | t:userB1) | | |
44 |---------200 OK------>| | |
-----------------------------------------------------------
Houri (Ed.), et al. Expires January 2, 2008 [Page 10]
Internet-Draft Scaling Optimizations for Presence July 2007
Figure 3: Message flow for aggregation or batched notification
2.2.4. SIP message flow example for batched notification
The following NOTIFY message contains presence documents of multiple
presentities. In the example, all the presence documents are
destined to a single watcher.
Houri (Ed.), et al. Expires January 2, 2008 [Page 11]
Internet-Draft Scaling Optimizations for Presence July 2007
NOTIFY sip:rlserver.domainB.com SIP/2.0
Via: SIP/2.0/TCP rlsserver.domainA.example.com;branch=z9hG4bK4EPlfSFQK1
Max-Forwards: 70
From: <sip:rlsserver@domainA.com>;tag=zpNctbZq
To: <sip:userA@domainB.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@ domainA.com
CSeq: 997935769 NOTIFY
Contact: <sip:rlsserver.domainA.com>
Event: presence
Subscription-State: active;expires=7200
Content-Type: multipart/related;type="rlmi+xml";
start="<2BEI83@rlsserver.domainB.example.com >";
boundary=" tuLLl3lDyPZX0GMr2YOo "
Content-Length: 2862
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID: <2BEI83@rlsserver.domainB.example.com>
Content-Type: application/pidf+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:userA1@domainA.com">
<tuple id="x823a4">
<status>
<basic>open</basic>
</status>
<contact priority="1.0">sip:joe@stockholm.example.org</contact>
</tuple>
</presence>
--tuLLl3lDyPZX0GMr2YOo
Content-Transfer-Encoding: binary
Content-ID: <KKMDmv@stockholm.example.org>
Content-Type: application/pidf+xml;charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="sip:userA2@domainA.com">
<tuple id="z98075">
<status>
<basic>closed</basic>
</status>
</tuple>
</presence>
--tuLLl3lDyPZX0GMr2YOo--
Figure 4: Message Flow for Aggregation or Batched Notification
Houri (Ed.), et al. Expires January 2, 2008 [Page 12]
Internet-Draft Scaling Optimizations for Presence July 2007
2.3. Timed presence
Watchers may be interested in general, coarse-grained availability
information of certain presentities rather then getting notification
for every status change of the presentity. For example, a manager
may be interested in knowing if the employees under him are available
or on vacation (calendar/timed-presence) rather then getting
notification about every status change. This can be achieved using
timed-presence [5]. An example of Timed-presence status is below:
<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>
</tuple>
<note>I'll be in San Diego IETF meeting</note>
</presence>
Figure 5: Time-presence status example
Thus, timed-presence can be used to automatically switch the
subscription on or off which can lower the presence notification
traffic. However, with current watcher filtering specification it is
not straightforward to automatically enable or disable notifications
based on calendar information from timed-presence. Watchers cannot
specify a watcher filter indicating not to send NOTIFY based on
timed-status as it would require them to know the 'from'/'until'
attribute in <timed-status> before hand. Watcher filtering
specification does not allow watchers to specify filter rules to
disable notifications based on comparison of timestamps. A watcher
application upon obtaining the <timed-status> can specify a watcher
filter using the 'from' and 'until' attribute in the received <timed-
status>, indicating the server not to send a NOTIFY unless the
<timed-status> or 'from' or 'until' attribute changes. A watcher
should not blindly un-subscribe for the time specified in the <timed-
status> because presentity may update the time-status and watcher may
not be aware of this. Hence, watcher must specify a watcher filter
which triggers a notification upon changes in elements of <timed-
status>, after it has received the first <timed-status>. Once the
interval for the received <timed-status> is over, the watcher
Houri (Ed.), et al. Expires January 2, 2008 [Page 13]
Internet-Draft Scaling Optimizations for Presence July 2007
application removes the filter and starts receiving notifications in
a normal manner. However, differential notification can be used to
know about changes in the timed-presence. From the above discussion,
it is clear that watcher filtering specification requires
enhancements for timestamp based watcher filters.
2.4. On-Demand presence (Fetch or Pull Model)
Watchers need not be notified about every presence update of all the
contacts at all times. Watchers may be interested in regularly
receiving presence updates for some of their contacts. But for other
contacts, watchers may only want to know their presence information
when they want to start a communication session. This can be labeled
as on-demand presence and can be accomplished by using fetch based
SUBSCRIBE with expiration interval set to zero. This approach
requires a mechanism in the watcher application to enable watchers to
indicate that they are not interested in regular presence updates,
rather they only require presence information when starting a new
session. Examples may include services, where presence status does
not have to be seen or known to a watcher all of the time. For
example, a cell-phone associated watcher may need presence updates
only when the cell-phone application (e.g., phone book) runs in the
foreground on the device. Another example is a presence-based call
routing in telephony, where - before the call is delivered - a
watcher issues a fetch-based SUBSCRIBE to learn whether and where the
callee is available.
2.5. Adapting the subscription rate
The rate of notification can be adjusted based on statistical
information about past multimedia sessions with user's contacts.
This can be initiated by the client or can be automatically done by
the server as server can procure such information based on stored
call and text session information. As a matter of fact, 60-70% of
the calls/IM messages are sent to 20% of the contacts [Reference
required, Observation based on call detail records of friends].
Nearly 50% of the buddies are called rarely. This may include
buddies from old office, old college, and old city who are present in
the buddy list but are not contacted actively. Based on such
information the presence server or the client can adapt the
subscription rate and use the fetch model for such buddies.
3. Conclusions
The document analysis the scalability of presence systems and of the
SIP based in particular. It is apparent that the scalability of
these systems is far from being trivial from several perspectives:
Houri (Ed.), et al. Expires January 2, 2008 [Page 14]
Internet-Draft Scaling Optimizations for Presence July 2007
number of messages, network bandwidth, state management and CPU load.
Several optimizations are suggested or are surveyed in this document.
It is important to note that not every optimization is really an
optimization and some of them may seem to optimize in one place while
they actually create load in other parts of the system.
It is very possible that the issues that are described in this
document are inherent to presence systems in general and not specific
to the SIMPLE protocol. Organizations need to be prepared to invest
a lot in network and hardware in order to create real big systems.
However, it is apparent that not all the possible optimizations were
done yet and further work is needed in the IETF in order to provide
better scalability
It seems that we need to think about the problem in a different way.
We need to think about scalability as part of the protocol design.
The IETF tends not to think about actual deployments when designing a
protocol but in this case it seems that if we do not think about
scalability with the protocol design it will not be very hard to
scale.
We should also consider whether using the same protocol between
clients and servers and between servers is a good choice with this
problem? It may be that in interdomain or even between servers in
the same domain (as between RLSs and presence servers) there is a
need to have a different protocol that will be very optimized for the
load and can assume some assumptions about the network (e.g. do not
use unreliable protocol as UDP but only TCP).
Another issue that is more concerning protocol design is whether
NOTIFY messages should not be considered as media as the audio, video
and even text messaging are considered? The SUBSCRIBE can be
extended to do similar three way handshake as INVITE and negotiate
where the notify messages should go, rate and other parameters. This
way the load can be offloaded to specialized NOTIFY "relays" thus not
loading the control path of SIP.
4. Security Considerations
One of the biggest sources of traffic between commnunities when
dealing with presence are multiple notifications on the same
presentities. The need for multiple notifications is due to the need
to provide different presence documents to different watchers
according to the privacy settings of presentity. Optimizing the
traffic between domains will most probably mean delegation of privacy
handling of users to the other domain. This is one of the most
Houri (Ed.), et al. Expires January 2, 2008 [Page 15]
Internet-Draft Scaling Optimizations for Presence July 2007
hardest issues that will need to be solved as part of presence
optimizations that directly touches the security of users.
Another security threat is actually coming from the fact that users
from one community subscribe to users on another community. The fact
that there are at least two servers between the users, that the users
need to trust for the real identity behind the watcher and the real
identity of the provider of the presence information has to be
considered while providing solutions for the protocol scalability.
5. Acknowledgments
We would like to thank Jonathan Rosenberg, Ben Campbell, Markus
Isomaki Piotr Boni, David Viamonte and Aki Niemi for their ideas and
input.
6. References
6.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
6.2. Informational References
[2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[3] Rosenberg, J., "A Watcher Information Event Template-Package for
the Session Initiation Protocol (SIP)", RFC 3857, August 2004.
[4] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
J. Peterson, "Presence Information Data Format (PIDF)",
RFC 3863, August 2004.
[5] Schulzrinne, H., "Timed Presence Extensions to the Presence
Information Data Format (PIDF) to Indicate Status Information
for Past and Future Time Intervals", RFC 4481, July 2006.
[6] Houri, A., "Problem Statement for SIP/SIMPLE",
draft-ietf-simple-interdomain-scaling-analysis-00 (work in
progress), February 2007.
[7] Urpalainen, J., "An Extensible Markup Language (XML) Patch
Operations Framework Utilizing XML Path Language (XPath)
Selectors", draft-ietf-simple-xml-patch-ops-02 (work in
Houri (Ed.), et al. Expires January 2, 2008 [Page 16]
Internet-Draft Scaling Optimizations for Presence July 2007
progress), March 2006.
[8] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE
Requests in the Session Initiation Protocol (SIP)",
draft-ietf-sip-uri-list-message-01 (work in progress),
January 2007.
Authors' Addresses
Avshalom Houri
IBM
Science Park Building 18/D
Rehovot,
Israel
Email: avshalom@il.ibm.com
Vishal Singh
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Email: vs2140@cs.columbia.edu
URI: http://www.cs.columbia.edu/~vs2140
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7004
Email: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Houri (Ed.), et al. Expires January 2, 2008 [Page 17]
Internet-Draft Scaling Optimizations for Presence July 2007
Sriram Parameswar
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
Email: Sriram.Parameswar@microsoft.com
Edwin Aoki
AOL LLC
360 W. Caribbean Drive
Sunnyvale, CA 94089
USA
Email: aoki@aol.net
Houri (Ed.), et al. Expires January 2, 2008 [Page 18]
Internet-Draft Scaling Optimizations for Presence July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Houri (Ed.), et al. Expires January 2, 2008 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-23 10:22:11 |