Internet DRAFT - draft-niemi-sipping-subnot-issues
draft-niemi-sipping-subnot-issues
Network Working Group A. Niemi
Internet-Draft Nokia Research Center
Expires: January 13, 2006 July 12, 2005
Problems with the Session Initiation Protocol (SIP) Events Framework
draft-niemi-sipping-subnot-issues-00
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 13, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The Session Initiation Protocol (SIP) events framework enables
receiving asynchronous notification of events related to SIP systems.
This framework defines the procedures for creating, refreshing and
terminating subscriptions, as well as fetching and periodic polling
of resource state. These procedures have a serious deficiency in
that they do not allow state to persist over a subscription refresh,
or between two consecutive polls. Another related but different
problem relates to the relative intolerance of the framework to
interferences in networking connectivity of subscribers in long-
Niemi Expires January 13, 2006 [Page 1]
Internet-Draft Problems with SIP Events July 2005
lasting subscriptions. This document explains the problems in more
detail and discusses possible solutions.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Document Conventions . . . . . . . . . . . . . . . . . . . 3
2. Motivations and Background . . . . . . . . . . . . . . . . . . 3
2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Problem: High Subscription Maintenance Costs . . . . . . . 4
2.3 Problem: Low Tolerance to Connectivity Interferences
in Long-lasting Subscriptions . . . . . . . . . . . . . . 4
2.4 Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
3. Description of Potential Solutions . . . . . . . . . . . . . . 5
3.1 Entity-tags and Conditional Requests . . . . . . . . . . . 5
3.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.2 Detailed Description . . . . . . . . . . . . . . . . . 6
3.1.3 Backwards Compatibility . . . . . . . . . . . . . . . 6
3.1.4 Examples . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Rules for Terminating a Subscription . . . . . . . . . . . 8
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1 Normative References . . . . . . . . . . . . . . . . . . . 9
7.2 Informative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 11
Niemi Expires January 13, 2006 [Page 2]
Internet-Draft Problems with SIP Events July 2005
1. Introduction
The Session Initiation Protocol (SIP) events framework provides an
extensible facility for requesting notification of certain events
from other SIP nodes. This framework includes procedures for
creating, refreshing and terminating of subscriptions, as well as the
possibility to periodically fetch or poll the event resource.
Several instantiations of this framework, called event packages have
been defined, e.g., for presence [4], message waiting indications [5]
and registrations [6].
In certain conditions, the overhead induced by having to maintain
subscriptions becomes prohibitively high for subscribers. Polling of
resource state behaves in a similarly suboptimal way in cases where
the state has not changed since the previous poll occurred. In
general, the problem lies in the inability to persist state across a
subscription refresh, or two consecutive fetches.
Another related but different problem lies in with the inability of
the notifier to fail soft in case a temporary network outage that
leads to a NOTIFY request timing out, causing the subscription to
terminate. Subscribers may be unaware of this until they refresh,
which might be even days later.
This memo discusses these problems in more detail, and ventures into
solution space by providing a possible ways to reduce the impact of
these problems.
1.1 Document Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1] and
indicate requirement levels for compliant implementations.
2. Motivations and Background
2.1 Overview
A SUBSCRIBE request creates a subscription with a finite lifetime.
This lifetime is negotiated using the Expires header field, and
unless the subscription is refreshed by the subscriber before the
expiration is met, the soft state is cleared. The frequency of these
subscription refreshes depends on the event package, and can range
from minutes to hours to months in some cases.
Changes in connectivity represent another impetus for a subscriber
Niemi Expires January 13, 2006 [Page 3]
Internet-Draft Problems with SIP Events July 2005
re-subscribing. If the subscriber's point of attachment to the
Internet changes, e.g., due to dynamic address allocation, the
subscriber needs to re-subscribe in order to update the dialog
endpoint, which is carried in the Contact header field.
2.2 Problem: High Subscription Maintenance Costs
The SIP events framework does not include different methods for
initial sibscriptions, subscription refreshes and fetches inside and
outside of the SIP dialog. Instead, the SUBSCRIBE method is
overloaded to perform all of these actions, and the notifier behavior
is identical in each of them; each SUBSCRIBE request generates a
NOTIFY request containing the latest resource state. This inability
to persist state across a SUBSCRIBE request results in substantial
overhead in maintaining subscriptions. This materializes in the form
of increased network traffic and unnecessary processing overhead for
both the subscriber and the notifier.
There are certain conditions that aggravate the problem. Such
conditions usually entail such things as:
o Large entity bodies in the payloads of notifications
o High rate of subscription refreshes
o Relatively low rate of actual notifications triggered by state
changes
Some of the same problems affect fetching and polling of event state
as well. Regarding polling, if we look at the performance of
Hypertext Transfer Protocol (HTTP) [7] in similar scenarios, it
performs substantially better when resources are tagged with an
entity-tag, and each GET is a conditional one using the "If-None-
Match" header field. If the resource has not changed between
successive polls, an error response is returned indicating this fact,
and the resource is not transmitted again.
The SIP PUBLISH [2] method also contains a similar feature, where a
refresh of a publication is done by reference to its assigned entity-
tag, instead of retransmitting the event state each time the
publication expiration is extended.
2.3 Problem: Low Tolerance to Connectivity Interferences in Long-
lasting Subscriptions
Another related but separate problem arises from long-lasting
subscriptions where during the subscription lifetime, the subscriber
experiences intermittent connectivity. The problem is that if a
Niemi Expires January 13, 2006 [Page 4]
Internet-Draft Problems with SIP Events July 2005
NOTIFY happens to time-out because of such temporary problems in
connectivity, the subscription is terminated, but the subscriber has
really no way of finding this out. The subscriber will only find out
when its time to refresh the subscription upon which it will receive
a 481 error response, and have to re-subscribe. In other words,
subscriptions have a very low tolerance for networking interference,
i.e., the notifier does not fail soft.
This problem manifests itself as a temporary zombie subscription,
which can result in poor user experience. The longer the
subscription expiration, the longer time it takes for the subscriber
to notice this zombie state, and the poorer the user experience
becomes. The problem is aggravated with event packages that
recommend long subscription expirations, e.g., the certificate event
package [8]
2.4 Requirements
As a summary, here is a short list of required functionality to solve
the presented issues:
REQ1: It must be possible to suppress the NOTIFY request (and the
event body therein) triggered by a subscription refresh, if
the subscriber already has possession of the latest event
state of the resource
REQ2: It must be possible to suppress the NOTIFY request (and the
event body therein) triggered by a fetch, if the subscriber
already has possession of the latest event state
REQ3: It must be possible for the notifier to fail soft in case
temporary interferences in the subscriber's connectivity. In
other words, the notifier must tolerate notification time outs
without severing the subscription, especially in long-lasting
subscriptions.
3. Description of Potential Solutions
This section lists some possible solutions to the problem. This text
is only meant as a high-level overview.
3.1 Entity-tags and Conditional Requests
3.1.1 Overview
This potential solution entails replicating similar features from
HTTP, namely entity-tags and conditional requests. Some existing
Niemi Expires January 13, 2006 [Page 5]
Internet-Draft Problems with SIP Events July 2005
header field and response code definitions can be reused from the
PUBLISH [2] specification.
3.1.2 Detailed Description
Each initial SUBSCRIBE request would be exactly as currently defined.
However, each NOTIFY request would contain an entity-tag in a SIP-
ETag header field. Each subsequent SUBSCRIBE request would include a
SIP-If-None-Match header field containing the entity-tag received in
the previous NOTIFY request. This header makes the SUBSCRIBE request
conditional -- the request will only progress if the condition is
met. In case the entity-tag has not changed, the condition is not
met, and the notifier responds with a 412 (Conditional Request
Failed) response.
The fact that the condition fails, also means that the NOTIFY request
is suppressed and the subscription continues as before.
OPEN ISSUE: To make this work, the SUBSCRIBE has to partially
succeed, i.e., the subscription expiry needs to be refreshed, even
though the NOTIFY is suppressed. It isn't entirely clear if this
is allowed with a 4xx response. Do we need a new 2xx response
code?
In case the entity-tag has changed, the notifier behaves normally,
and the SUBSCRIBE triggers a NOTIFY request carrying the latest
resource state.
The advantages of this solution are clear:
o It allows resource state to persist over a subscription refresh.
I.e., a subscription refresh due to a changed IP address, or
extension of the expiry time no longer triggers a notification
carrying full event state.
o It allows resource state to persist accross two consecutive
fetches. A fetch would not trigger a NOTIFY if the resource state
had not changed (i.e., its entity tag had not changed) since the
previous fetch.
OPEN ISSUE: Another option to maintaining subscriptions with
little or no overhead is to define an alternative to SUBSCRIBE
that installs a hard-state subscription at the notifier.
3.1.3 Backwards Compatibility
The proposed solution is backwards compatible with SIP events [3] in
Niemi Expires January 13, 2006 [Page 6]
Internet-Draft Problems with SIP Events July 2005
that a notifier supporting this mechanism will insert a SIP entity-
tag in its NOTIFY requests, and a subscriber that understands this
mechanism will know how to use them in creating a conditional
request.
Unaware subscribers will simply ignore the entity-tag, make
unconditional requests and get the usual defined behavior from the
notifier.
As a hint to the notifier, the subscriber could also use the
Supported header field to advertize support for this feature, for
example, like this:
Supported: etags
3.1.4 Examples
Below is an example message flow that utilizes conditional SUBSCRIBE
requests and entity-tags.
Initial subscription, at t=0:
Watcher Notifier
| |
|'---...__M1 |
| `'---...__ |
| ->|
| |
| M2___..,--'' |
| _.,--''' |
|<- |
| |
| M3___..,--'' |
| _.,--''' |
|<- |
| |
| |
|'---...__M4 |
| `'---...__ |
| ->|
M1: SUBSCRIBE, no entity-tag, Expires: 3600. M2: 200 OK. M3:
NOTIFY, SIP-ETag: 0001. M4: 200 OK, Expires: 3600
Niemi Expires January 13, 2006 [Page 7]
Internet-Draft Problems with SIP Events July 2005
Subscription refresh, at t=3000:
Watcher Notifier
| |
|'---...__M5 |
| `'---...__ |
| ->|
| |
| M6___..,--'' |
| _.,--''' |
|<- |
M5: SUBSCRIBE, If-None-Match: 0001, Expires:3600. M6: 412
Conditional Request Failed, Expires: 3600.
3.2 Rules for Terminating a Subscription
To allow a notifier to fail soft requires changes to the notifier
behavior defined in the SIP events framework [3].
Currently, the notifier is instructed to terminate the subscription
("MUST" strength) in case a NOTIFY request times out. Instead, the
notifier should be allowed to keep the subscription alive.
OPEN ISSUE: Perhaps the notifier could install such subscriptions
into "probation" state, keep sending the notifications. For
example, it could be defined such that those NOTIFYs that are in
Subscription-State: "probation", only NULL bodies are sent, and
the subscriber needs to refresh in order to lift the state back to
"active" and get the actual event state delivered to it.
4. Conclusions
In this memo, we describe the problem of high costs in maintaining
SIP event subscriptions, and specifically the inability to persist
state accross subscription refreshes or consequtive fetches in the
SIP events framework. A related problem that deals with the
inability to tolerate temporary connectivity problems in long-lasting
subscriptions is also presented.
The proposal is to acknowledge the problems exist and take the
proposed solutions as the baseline towards fixing the problems.
5. IANA Considerations
This document includes no actions for IANA at this time.
Niemi Expires January 13, 2006 [Page 8]
Internet-Draft Problems with SIP Events July 2005
6. Security Considerations
This document includes no security considerations at this time.
7. References
7.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Niemi, A., "Session Initiation Protocol (SIP) Extension for
Event State Publication", RFC 3903, October 2004.
[3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
7.2 Informative References
[4] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[5] Mahy, R., "A Message Summary and Message Waiting Indication
Event Package for the Session Initiation Protocol (SIP)",
RFC 3842, August 2004.
[6] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004.
[7] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[8] Jennings, C. and J. Peterson, "Certificate Management Service
for The Session Initiation Protocol (SIP)",
draft-ietf-sipping-certs-01 (work in progress), February 2005.
Niemi Expires January 13, 2006 [Page 9]
Internet-Draft Problems with SIP Events July 2005
Author's Address
Aki Niemi
Nokia Research Center
P.O. Box 407
NOKIA GROUP, FIN 00045
Finland
Phone: +358 50 389 1644
Email: aki.niemi@nokia.com
Niemi Expires January 13, 2006 [Page 10]
Internet-Draft Problems with SIP Events July 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Niemi Expires January 13, 2006 [Page 11]
