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]