SIPPING Working Group T. Moran Internet Draft SAIC Expires: September 14, 2008 March 14, 2008 Determining When to Discard or Retry a SIP Request During Overload draft-moran-sipping-overload-retry-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 September 14, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract SIP servers can become overload and unable to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document proposes an architecture for determining when a client should throttle the sending of SIP requests vs. retrying them. Moran Expires September 14, 2008 [Page 1] Internet-Draft Overload Retry Control March 2008 Conventions used in this document 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]. Table of Contents 1. Introduction...................................................3 2. Determining the Scope of the Overload..........................3 2.1. Server Overload...........................................4 2.2. Proxy Overload............................................4 2.3. Cluster Overload..........................................4 3. Taking the Appropriate Action..................................5 3.1. Server Overload...........................................5 3.2. Proxy Overload............................................5 3.3. Cluster Overload..........................................6 4. Security Considerations........................................6 5. IANA Considerations............................................6 6. Conclusions....................................................7 7. Acknowledgments................................................7 APPENDIX A: Overload Reporting Mechanisms.........................8 APPENDIX B: Network Scenarios (Diagrams)..........................9 7.1. Normative References.....................................12 7.2. Informative References...................................12 Author's Address.......................Error! Bookmark not defined. Intellectual Property Statement..................................13 Disclaimer of Validity...........................................13 Moran Expires September 14, 2008 [Page 2] Internet-Draft Overload Retry Control March 2008 1. Introduction From reading [3], as well as [4], [5] and [6], the fundamental issue with the current SIP overload control mechanism (i.e. the 503 "Cluster Unavailable" response) is that it does not provide the means for a client receiving overload notification to determine whether it should retry or throttle requests. Determination of the appropriate client action requires knowledge of the scope of the overload condition and the client's specific role within the network. The scope of the overload may be limited to a single server undergoing maintenance, an entire cluster of servers providing a service, a gateway proxy or perhaps a load balancing proxy. The following proposes an architecture (set of rules and methods) for determining the scope of an overload condition and the appropriate actions to be taken by the affected server(s) and client(s). The example network scenario diagrams of [3] should be considered when reviewing this contribution. For convenience, APPENDIX B: includes those diagrams as well as additional ones. 2. Determining the Scope of the Overload This section defines the categories of overload scope and identifies the mechanisms for declaring such. Knowing the overload scope enables the upstream client(s) to take the appropriate action (e.g. throttle requests) as discussed in Section 3. Note: The rules for determining the overload condition itself are not addressed by this contribution. The overload categories are defined as: o Server - A network element that only responds to requests o Proxy - per RFC 3261, primarily routes requests toward the final destination o Cluster - A set of servers that appear as a single server to the client The mechanisms for declaring overload and its category are described below. Note: No additional identification is made as to what cluster or what server. Whether or not this is needed within and between domains is FFS. Current assumption is that this is not needed. Moran Expires September 14, 2008 [Page 3] Internet-Draft Overload Retry Control March 2008 2.1. Server Overload Server (e.g. registration, application, etc.) overload is autonomously declared by the server in question. The actions taken upon declaration of server overload are described in Section 3.1. 2.2. Proxy Overload Proxy overload is autonomously declared by the proxy in question. The required actions in response to proxy overload are described in Section 3.2. 2.3. Cluster Overload The declaration of cluster overload may be made by the client (e.g. proxy) that is immediately upstream of the server or servers reporting an overload condition. When a service is provided using more than one server, the immediately upstream client must be aware of all servers providing the service and their overload status. If the state of all servers providing the service is that of overload, then the proxy declares a state of cluster overload. How the proxy acquires the overload status of the servers and the appropriate actions it is to take is addressed in section 3.3. An example of cluster overload due to lack of available servers would be the scenario where servers S1-S3 of Figure 1 in APPENDIX B: are simultaneously overloaded. In this case, proxy P1 declares cluster overload. In addition, a cluster may be declared as overloaded if there are no available paths (proxys) to a qualified server. An upstream client that is not adjacent the server(s) (e.g. two hops upstream) declares cluster overload if all adjacent downstream proxies with a path to the cluster are overloaded. How the proxy acquires the overload status of the downstream proxies and the appropriate actions it is to take is addressed in section 3.3. An example of cluster overload due to lack of an available path to the service would be the scenario where proxies P1 and P2 of Figure 2 in APPENDIX B: are simultaneously overloaded. In this case, proxy PA would declare cluster overload. Question: Is it a viable case wherein the clusters of servers providing service are disjoint as shown in Figure 3? If so, then a separate category is needed which describes partial outage and a client further upstream (e.g. PA) would be the proxy that declares total outage. The proxy overload category could be used to signify a Moran Expires September 14, 2008 [Page 4] Internet-Draft Overload Retry Control March 2008 group of servers was overloaded, e.g. P1 would declare proxy overload when S1-S3 are overloaded and it has been configured as not- the- final-authority-to-declare-service-overload. FFS 3. Taking the Appropriate Action This section describes the actions taken by the clients and servers once a defined category of overload has been declared as described in Section 2. One of these actions, and a fundamental one, is the actual reporting of the overload condition to upstream clients. Candidate methods for reporting overload are discussed in the informative APPENDIX A: . 3.1. Server Overload A server that has declared an overload condition reports "Server" overload to its immediately upstream client(s) (e.g. a load balancing proxy). The report describes the degree of the overload using either a temporal or spatial indicator from which the immediately upstream client integrates with overload information from other servers (as applicable) to determine the scope of the overload as either cluster or server. Providing the degree of the overload in the report enables better management of resources such as varying the level of throttling in the early stages of congestion so as to avoid a total collapse of a server. Question: Is it feasible (technically and otherwise) to provide overload status across domains/service providers? For the case of server overload, the client determines that there is at least one other qualified server with available resources. Therefore, the client retries the request to an available server. 3.2. Proxy Overload Question: Do we need this category? When a proxy declares an overload condition it sends a "Proxy" overload report to its immediately upstream client(s). The report describes the degree of the overload using either a temporal or spatial indicator from which the immediately upstream client integrates with overload information from other proxies (as applicable) to determine the scope of the overload as either cluster or proxy. Providing the degree of the overload in the report enables better management of resources such as varying the level of throttling in Moran Expires September 14, 2008 [Page 5] Internet-Draft Overload Retry Control March 2008 the early stages of congestion so as to avoid a total collapse of a proxy. Question: Is it feasible (technically and otherwise) to provide overload status across domains/service providers? For the case of proxy overload, the client determines that there is at least one other qualified proxy with available resources. Therefore, the client retries the request to an available proxy. 3.3. Cluster Overload Cluster overload can be declared by a client due to overload of all servers providing a service or by a client due to overload of all proxies providing a path to the service. If the client immediately upstream of an overloaded server (see Section 2.3. ) declares cluster overload, then it reports "Cluster" overload to its upstream client(s) and executes request throttling to the overloaded cluster per network provider defined policy. The report includes the degree of the overload. Providing the degree of the overload in the report enables better management of resources, such as varying the level of throttling in the early stages of congestion, so as to avoid a total collapse of the cluster while maximizing resource utilization. Question: Is it feasible (technically and otherwise) to provide overload status across domains/service providers? If the client immediately upstream of an overloaded proxy (see Section 2.3. ) declares cluster overload, due to no other available downstream proxies with a path to the cluster, then it reports "Cluster" overload to its upstream client(s) and executes request throttling to the overloaded cluster per network provider defined policy. An upstream client receiving a "Cluster" overload report passes the report further upstream and executes request throttling to the overloaded cluster per network provider defined policy. 4. Security Considerations Forging of or man-in-the-middle attacks to overload control reports can lead to denial of service or service collapse. 5. IANA Considerations The overload categories (Server, Cluster, etc) will need a standardized identifier. Moran Expires September 14, 2008 [Page 6] Internet-Draft Overload Retry Control March 2008 6. Conclusions The definition of overload categories, the rules for declaring and reporting the overload category, the recognition of a server's role w.r.t. overload control and the actions to be taken by the upstream server receiving a categorized overload report; provide a mechanism for determining when a server should retry vs. throttle requests. This capability avoids overload amplification as well as under utilization of server resources. 7. Acknowledgments Many thanks to Dr. Ken Carlberg, Ms. Janet Gunn, Dr. John Wullert and Dr. Arye Ephrath for their in depth comments. This document was prepared using 2-Word-v2.0.template.dot. Moran Expires September 14, 2008 [Page 7] Internet-Draft Overload Retry Control March 2008 APPENDIX A: Overload Reporting Mechanisms At least two approaches are candidates for overload reporting. The first is to use a SIP response (such as the 503 "Service Unavailable") but possibly with some procedural modifications as suggested in [5]. The other approach is to use the subscribe-notify method. The tradeoffs are TBD. Moran Expires September 14, 2008 [Page 8] Internet-Draft Overload Retry Control March 2008 APPENDIX B: Network Scenarios (Diagrams) +------+ > | | / | S1 | / | | / +------+ / / / / +------+ / +------+ --------> | |/ | | | P1 |---------> | S2 | --------> | |\ | | +------+ \ +------+ \ \ \ \ \ \ +------+ \ | | > | S3 | | | +------+ Figure 1 Load Balanced Servers: Single Load Balancing Proxy Moran Expires September 14, 2008 [Page 9] Internet-Draft Overload Retry Control March 2008 +------+ > | | < / | S1 | \\ / | | \\ / +------+ \\ / \ / \\ / \\ / \ +------+ / +------+ +------+ | | / | | | | | P1 | ---------> | S2 |<----------| P2 | | | \ | | | | +------+ \ +------+ +------+ ^ \ / ^ \ \ // / \ \ // / \ \ // / \ \ / / \ \ +------+ // / \ \ | | // / \ > | S3 | < / \ | | / \ +------+ / \ / \ / \ / \ / \ / \ / \ / \ / +------+ | | | PA | | | +------+ ^ ^ | | | | Figure 2 Load Balanced Servers: Multiple Load Balancing Proxys Moran Expires September 14, 2008 [Page 10] Internet-Draft Overload Retry Control March 2008 +------+ > | | / | S1 | / | | / +------+ / / / / +------+ / +------+ | |/ | | ---> | P1 |---------> | S2 | / | |\ | | / +------+ \ +------+ / \ / \ / \ / \ / \ / \ +------+ / \ | | / > | S3 | +------+ / | | | | / +------+ | PA |/ | |\ +------+ +------+ \ > | | \ / | S4 | \ / | | \ / +------+ \ / \ / \ / \ / \ +------+ / +------+ \ | |/ | | -----> | P2 |---------> | S5 | | | | | +------+ +------+ Figure 3 Disjoint Clusters: Multiple Load Balancing Proxys Moran Expires September 14, 2008 [Page 11] Internet-Draft Overload Retry Control March 2008 References 7.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [3] Rosenberg, J., "Requirements for the Management of Overload in the Session Initiation Protocol," draft-ietf-sipping-overload- reqs-01, November 17, 2007 [4] Chadli, Y., Marjou, X., "An overload control package for the Session Initiation Protocol (SIP)," draft-chadli-sipping- overload-sub-not-00, December 04, 2007 [5] Hilt, V., Widjaja, I., Malas, D., and Shulzrinne, H., "Session Initiation Protocol (SIP) Overload Control," draft-hilt- sipping-overload-03, October 26, 2007 [6] Hilt, V., Widjaja, I., "Essential Correction to the Session Initiation Protocol (SIP) 503 (Service Unavailable) Response," draft-hilt-sip-correction-503-01, July 6, 2007 Author's Addresses Timothy Moran SAIC 1710n SAIC Drive McLean, Va 22102 USA Email: morantl@saic.com Moran Expires September 14, 2008 [Page 12] Internet-Draft Overload Retry Control March 2008 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, 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. Copyright Statement Copyright (C) The IETF Trust (2008). 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. Moran Expires September 14, 2008 [Page 13]