INTERNET-DRAFT SIPPING WG May 2004 Rajnish Jain Expires: November 2004 Excel Switching Corporation Vijay K. Gurbani Lucent Technologies/Bell Laboratories Requirements for Persistent Connection Management in the Session Initiation Protocol (SIP) draft-jain-sipping-persistent-conn-reqs-02.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed,and any of which I become aware will be disclosed, in accordance with RFC 3667. 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 November, 2004. Copyright Notice Copyright ¨ The Internet Society (2003). All Rights Reserved. Jain Expires - November 2004 [Page 1] Internet-Draft Persistent Connection Reqs May 2004 Abstract SIP over connection-oriented transport protocol based systems are likely to face certain distinct performance and behavioral issues that are not manifest when SIP is transported over connectionless protocols. Allowing SIP entities to mutually conserve connections over a predictable, extended period of time is one of the leading requirements to help SIP entities deliver their optimal performance in the network. Overall, this document contemplates transport layer connection management issues relating to SIP. Requirements and potential solutions for introducing a backward compatible notion of persistent connections in SIP are presented. Applicability Statement The means and procedures described in the Internet-Draft are most applicable in scenarios where there is a high volume of signaling traffic between two SIP entities, or the need to maintain a long- term trusted, peering relationship between them. Examples of such scenarios are much-used signaling paths between two proxies belonging to different service providers, or the signaling path between a SIP User Agent Client (UAC) and its default outbound proxy. Table of Contents 1. Conventions used in this document.............................3 2. Introduction..................................................3 3. Transport Layer Connection Management.........................6 4. Advantages of Persistent Connections..........................9 4.1 Performance Efficiency....................................9 4.2 Resources Efficiency......................................9 5. Requirements.................................................10 6. Proposed Solutions...........................................10 6.1 New Via header field parameter...........................10 6.2 New SIP header...........................................11 7. Security Considerations......................................12 8. IANA Considerations..........................................12 9. Acknowledgements.............................................12 Jain Expires - November 2004 [Page 2] Internet-Draft Persistent Connection Reqs May 2004 1. Conventions used in this document In this document, the key words "MUST", "MUST NOT","REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC2119[2] and indicate requirement levels for compliant SIP implementations. 2. Introduction SIP [1] being an application layer protocol is stacked above the transport layer in the Internet Protocol model. Although SIP tends to be loosely coupled with transport layer, certain aspects of SIP entities are somewhat influenced by (or can benefit from) the workings of vastly diverse transport layer protocols. For instance, connection-oriented transport protocols (such as TCP, SCTP, and TLS over TCP) demand more systemic resources and introduce latencies to provide their salient features in contrast with their connectionless counterparts (such as UDP). As a result, the dynamics of a connection oriented transport protocol are likely to produce somewhat of a ripple effect on the entire SIP entity. Evidently, in order to minimize the negative performance impact caused by excessive connections, SIP implementers desire standardized mechanisms to expend connections cautiously. In general, SIP is currently quite liberal in setting up and tearing down transport layer connections. Per [1], transport layer connections should be opened, closed, and recycled at the discretion of individual implementations. To prevent lingering of low traffic connections, section 18 of [1] guides implementers to close connections after an implementation-defined amount of idle time. Depending on the interpretation of [1] by the implementer, the idle time can range from 32s (T1*64) to infinity (thereby keeping the connection open forever; however, there are problems with this interpretation of "infinity", as will be discussed later). In a multi-vendor SIP network, diverse SIP entities will thus vastly differ in their discretion of connection idle timeout periods and connection reuse policies. Such discrepancies will manifest themselves into inter-operability chaos and inefficient network performance. The connect-reuse Internet-Draft[2] presents a few scenarios where performance degradation is evident. Typically, connections between SIP entities frequently age out due to sporadic traffic patterns, if they are maintained at all beyond a transactionÆs lifetime. Connections are always deemed ephemeral in nature and are shut down without any consensus Jain Expires - November 2004 [Page 3] Internet-Draft Persistent Connection Reqs May 2004 between interacting SIP entities. To that end, several opportunities are missed where SIP entities would best serve the network if they communicate over persistent connections that are setup and torn down predictably. Unfortunately, connections are currently torn down by either side due to lack of communication of such intent from one entity to another using a SIP construct. Exceptions include a few scenarios supported by SIP currently that facilitate connection conservation. Figure 1. below shows a typical SIP trapezoid arrangement with end-points Ea and Eb and their default out-bound proxy servers Pa and Pb, respectively. --Ca2b--> Pa . . . . . .Pb . . . . Ea . . . . . . . . . Eb Figure 1: Typical SIP trapezoid. For illustration purpose it is assumed that Pa and Pb are in a peering relationship and communicate over a connection-oriented transport protocol. The call flow begins with Pa receiving an INVITE from Ea (for Eb). As a result, Pa originates a transport layer connection to Pb called Ca2b and puts call request to Pb over that connection. Per SIP, the following message exchanges will likely recycle connections further down the call flow: 1. Responses from Pb to Pa 2. New requests from Pa to Pb It is worth noting that new requests from Pa to Pb have the opportunity to recycle connection Ca2b, if the connection is indeed active at the time new requests arrive. If there is significant (implementation-defined) time gap between two requests from Pa to Pb, it is likely that connection Ca2b would age out and be closed before the later request arrives. In this case, a new request from Pa to Pb will have to trigger a new connection. This problem can be alleviated by making PaÆs implementation-defined timer substantially large. However, that approach manifests a bigger scaling issue, as Pa would then tend to exhibit that behavior universally with every SIP entity (including end-points) it initiates a connection to. Furthermore, Pa and Pb may vastly differ in their discretion of transport layer idle timeouts. Assuming that Pa tends to be ôliberalö (smaller timeout) and Pb ôconservativeö (larger timeout), when it comes to cycling through transport connections, Pa can swamp Pb Jain Expires - November 2004 [Page 4] Internet-Draft Persistent Connection Reqs May 2004 with transport layer connection setup and tear down requests. This may negatively influence overall functioning of Pb. Likewise, numerous under utilized lingering connections may lend themselves to scaling and performance issues. Therefore, some technique is required for selectively making the implementation- defined timer large on a per entity pair relationship basis. Apart from transactions from Pa to Pb, new transactions initiated from Pb to Pa are most unlikely to recycle connection Ca2b despite of it being active. The reason is that normally SIP treats connections as ephemeral, as indicated in the following text from section 18 of [1]: ôNote that, because the source port is often ephemeral, but it cannot be known whether it is ephemeral or selected through procedures in [4], connections accepted by the transport layer will frequently not be reused. The result is that two proxies in a "peering" relationship using a connection-oriented transport frequently will have two connections in use, one for transactions initiated in each direction.ö Given the method described in [1], proxy server Pb is faced with two subtly distinct dilemmas in recycling connection Ca2b. Firstly, Pb cannot rely on the availability of the Ca2b connection for a required time period as the connection was originally created by Pa, and therefore can be preempted (torn down) by Pa at PaÆs own discretion. Pb has no idea, whatsoever, whether PaÆs Ca2b connection is meant to be persistent or ephemeral. Giving the benefit of doubt to the ephemeral case, Pb will be unable to recycle connection Ca2b for transporting its transactions to Pa (unless the implementer is willing to take the risk of mid-transaction connection closure and handle consequences thereafter). Secondly, Pb has no way to know from Pa if it is welcome to (or forced to) use the Ca2b connection for requests from Pb to Pa. It is quite likely that an implementation of Pa may not be set up to accept new requests within an existing dialog on any other port than the standard SIP port numbers (5060 for UDP, TCP and SCTP, 5061 for TLS over TCP, or TLS over SCTP). If Pb were to use the Ca2b connection for requests to Pa, the requests will arrive at PaÆs source port for Ca2b connection, which may not necessarily be a standard SIP port number. Given that [1] does not provide a way for Pa and Pb to communicate their connection usage methods, Pb will most likely originate a new transport layer connection to Pa called Cb2a for transport of Pb to Pa transactions. Figure 2 below shows simultaneous existence of Ca2b and Cb2a connections. Jain Expires - November 2004 [Page 5] Internet-Draft Persistent Connection Reqs May 2004 --Ca2b--> Pa . . . . . .Pb . <--Cb2a-- . . . Ea . . . . . . . . . Eb Figure 2 Two connections for SIP messages. Quite likely, the Cb2a connection is unnecessary when Ca2b connection is active. Reference [2] acknowledges this issue. It presents requirements and proposes a mechanism for Ca2b connection reuse for transactions initiated from Pb to Pa. It recommends that a new Via header field parameter (called ôaliasö) be added in a request from Pa to Pb, to imply that Pb is allowed to (and should) reuse the Ca2b connection. The technique presented in [2] is quite efficient and flexible in eliminating the need for a Cb2a connection when Ca2b connection is active. However, the technique tends to solve only the second dilemma mentioned above. While it enables Pa to tell Pb that Pb is welcome to (and perhaps should) use the Ca2b connection for Pb to Pa requests, it leaves out the connection longevity aspect. Pb still cannot rely on the availability of Ca2b connection for a required time period. Furthermore, the technique presented in [2] ignores a potential insistence aspect for connection reuse request. That is, how insistent (or needy) Pa is when it puts out the ôaliasö field in the Via header. On one extreme, Pa may want to softly request Pb to reuse Ca2b connection (for performance optimization e.g.), in which case Pb can somewhat leverage itsÆ own judgment to honor or deny the request. On another extreme, Pa may want to hard press Pb to reuse Ca2b connection (when Pa is behind a NAT e.g.), in which case Pb can be made to somewhat unconditionally honor the connection. Evidently, a scheme that allows SIP entities to communicate their transport layer connection reuse policy (including longevity and insistence aspects) with each other is necessary. Such a scheme would not only allow SIP implementations to cautiously expend transport layer connections to provide optimal performance, but also accomplish certain application layer requirements. Accordingly, this draft goes beyond [2] and presents requirements and proposals for introducing needful vocabulary in SIP the management of persistent transport layer connections. 3. Transport Layer Connection Management Jain Expires - November 2004 [Page 6] Internet-Draft Persistent Connection Reqs May 2004 Management of transport layer connections can be premised on diverse stimuli and policies. Typically such discretions arise from SIP traffic profiles, SIP entity relationships, application behaviors, underlying platform support, etc. For instance, two high throughput proxy servers in a peering relationship will greatly benefit if they are conservative at connection management (i.e. have a larger timeout). Whereas, a SIP phone that occasionally places or receives call is perhaps best suited to be liberal at connection management. In connection-oriented transport layer protocols, a connection instance is somewhat mutually owned by both client and server sides. Both sides commit their resources and maintain per connection finite state machines. Therefore, broadly speaking, connection management should be considered and allowed to be a cooperative onus of the connected entities. Application entities on the two sides of a connection should be allowed to communicate their connection management information of mutual interest over an application layer protocol. In SIP based networks, where SIP entities range from edge to the core of the network, the connection management behaviors cannot be base-lined; however, given that the roles of SIP entities are well defined, a few broad classes of connection management can be defined that represent every SIP entity in the network. Based on SIP traffic profiles and application behaviors, diverse requirements for connection management are expected to fall into the following three classes: 1. Uni-directional ephemeral connections 2. Bi-directional ephemeral connections 3. Persistent connections Uni-directional ephemeral connections carry transactions initiated by one side only (the side that actively sought out the connection). They age out at the isolated discretion of individual implementations. Typically, connections that become idle for an implementation-defined period of time are closed. Either party is allowed to close such type of connections. Choosing a large connection idle time period on the originator side alone does not guarantee that these connections will be long-lived. Accordingly, SIP entities should inherently assume these connections to be ephemeral in nature. These are essentially the type of connections described in section 18 of [1]. Connections Ca2b and Cb2a in figure 2 of this draft are unidirectional ephemeral connections. Bi-directional ephemeral connections carry transactions initiated by both sides. They (also) age out at the isolated discretion of individual implementations. Typically, connections that become Jain Expires - November 2004 [Page 7] Internet-Draft Persistent Connection Reqs May 2004 idle for an implementation-defined period of time are closed. Either party is allowed to close such type of connections. Choosing a large connection idle time period on one side alone does not guarantee that these connections will be long-lived. Since SIP does not allow peering entities to communicate their connection idle time periods, each SIP entity should, therefore, inherently assume these connections to be ephemeral in nature. These are essentially the ôaliasö type of connections described in [2]. Bi-directional ephemeral connections essentially start out as uni-directional connections, but on solicitation from the original uni-directional side to another they become bi- directional. Bi-directional connections do not occur automatically. They are solicited and succeed upon acceptance from the other side. For instance, in the Pa/Pb example, Pb shouldnÆt make Ca2b connection bi-directional unless Pa requests it. Pb is allowed to accept or deny the request to reuse the connection. Figure 3 below shows a bi-directional ephemeral connection between Pa and Pb called Ca+b. <-Ca+b-> Pa . . . . . .Pb . . . . Ea . . . . . . . . . Eb Figure 3. Bi-directional ephemeral connections. Persistent connections, in contrast with ephemeral connections, do not age out due to connection idle timeouts typically caused by sporadic SIP traffic patterns. Persistent connections are driven by the application logic above SIP and therefore are most predictable. Once established between two SIP entities as a result of a dialog-initiating transaction, these connections persists beyond the transaction's lifetime, and in fact, even beyond the dialog's lifetime. Their closure may be expected (scheduled downtime) or unexpected (system crash), however, the remaining peer should construe any such closure as an indication to release resources on its side of the connection. Neither side explicitly closes these connections under normal circumstances. These connections are expected to endure regardless of SIP message traffic patterns. Their typical usage would be between two SIP entities that are kind of ôhard wiredö together based on the network architecture. Figure 4 below shows a persistent connection between Pa and Pb called Ca&b. Jain Expires - November 2004 [Page 8] Internet-Draft Persistent Connection Reqs May 2004 <-Ca&b-> Pa . . . . . .Pb . . . . Ea . . . . . . . . . Eb Figure 4. Persistent Connections. Note: Is there any need to further sub-divide persistent connections into 2: uni-directional persistent connections and bi-directional persistent connections? As a prelude to a discussion, consider that a TCP socket, once opened, is bi- directional. Thus, it would seem appropriate to carry over the same semantics to a persistent connection. On the other hand, certain SIP clients may want to ensure the downstream server that they will keep the connection persistent and not close it down after the transaction is over (uni-directional persistent), but if the downstream entity wants to send a new request, it can open up a new uni-directional persistent connection on its own, which will be honored. 4. Advantages of Persistent Connections Persistent connections can potentially be advantageous in many ways. This section presents some of their evident advantages. 4.1 Performance Efficiency TCP itself requires a 3-way handshake to agree on window sizes and sequence numbers before the first byte of payload data is exchanged between peers. TLS over TCP endures an even longer delay as both parties are authenticated. Such delays can vary from being mildly irritable to causing signaling and media to become out of lockstep (for example, subjecting a re-INVITE putting media on hold to re-establish credentials between two or more intervening proxies can add several round-trip times between the time a user presses the "Hold" button to when the media is actually put on hold). A persistent connection between signaling entities along the path would alleviate the need to establish a new ephemeral connection for such services. 4.2 Resources Efficiency Every connection entails precious resources. Each time a socket is opened between peers, the hosts allocate buffers, descriptors and other resources in the kernel for the subsequent exchange of data. Simultaneously, implementation of TCP and SCTP layers instantiate and maintain per connection finite state machines. Jain Expires - November 2004 [Page 9] Internet-Draft Persistent Connection Reqs May 2004 Typically, every connection entails timer support. As the number of simultaneously active connections rise, so does the burden on the transport layer and therefore the entire entity. It would appear that in peering arrangements (or in cases of a UAC and its default outbound proxy), these machinations could be avoided since the intent is to reuse the connection between the peers. 5. Requirements The following items present requirements on the SIP protocol for connection management between two interacting SIP entities: 1. The mechanism provided for persistent connection management should accommodate needs for diverse kinds of SIP entities. 2. The mechanism provided should allow SIP entities to utilize persistent connections at their own discretion, as well as in consultation with their peers. 3. The mechanism provided should allow SIP entities to request unidirectional/bi-directional ephemeral or persistent connections from the transport layer. 4. The mechanism provided should prevent a SIP entity that liberally expends connections from swamping another peer entity. 5. The mechanism provided should be such that a SIP entity that supports this Internet-Draft automatically honors requests from entities supporting [2] and [1]. 6. Proposed Solutions This section presents two potential solutions to connection management information exchange between two SIP entities. The intent is to have one solution; however, such a solution would benefit from a discussion involving a larger audience as represented by the IETF SIPPING WG. 6.1 New Via header field parameter The first solution is to extend the via-params parameter of the Via header as follows: via-params = via-ttl / via-maddr / via-received / via-branch / via-connection via-connection = "persistent" Jain Expires - November 2004 [Page 10] Internet-Draft Persistent Connection Reqs May 2004 The advantage of this solution is that the presence of the "persistent" Via parameter serves as a hint to the server on the intention of the originator of the connection. The originator guarantees to leave the connection up beyond the transaction's lifetime. It is now up to the server to either honor the persistency and send subsequent requests (in the same dialog or on separate dialogs) on the same socket, or to close the socket after the transaction is over. In the event that the server closes the socket after the transaction, the client reverts to existing behavior by freeing up any resources and attempting a new connection to the same downstream server on subsequent requests. The disadvantage of this solution is that it does not provide for a negotiation on the time frame that the socket remains open. The next solution addresses this very disadvantage. 6.2 New SIP header The second solution is to implement an extension that allows for negotiation for the acquiescence and longevity of a persistent connection. Under this solution, a client that seeks a persistent connection will: (1) Insert a "Supported" header with the option tag "persistence", indicating support for this extension. (2) Insert a "persistent" Via parameter as described in the previous section. The client MAY also include a header called "Persistent-Timeout" to indicate an upper bound on the time it will allow for the socket to remain open. If this header is not present, a value of infinity is assumed (i.e. the client will not, under normal operations, close the socket). A receiving server, if it supports the extension in this Internet-Draft, can honor the request depending on its policies with respect to persistent connections and the presence (or absence) of the "Persistent-Timeout" header. If a server wants to decrease (or increase) the timeout value, it will send a 4xx response (exact number to be determined) along with a "Min- Persistence" header that indicates its desire on the longevity of the persistent connection. The client is expected to retry the request again with the "Persistent-Timeout" parameter containing a value of MIN("Persistence-Timeout", "Min-Persistence"). The advantage of this solution is that a server can explicitly reject a request from a client that wants to establish a Jain Expires - November 2004 [Page 11] Internet-Draft Persistent Connection Reqs May 2004 persistent connection. It can also pare down (or force up) the longevity timer of the persistent connection. The disadvantage of this solution is that it goes beyond the "hint" nature of a transparent solution. At this point, some more discussion would be helpful to understand if such a offer/counter-offer mechanism is desired. . 7. Security Considerations 8. IANA Considerations 9. Acknowledgements Thanks to Eric Colasanto, Victor Saverino, James Ford, Sarit Galanos Mekler, Cullen Jennings, and Aby Kuriakose for providing valuable input on the issues addressed in this draft. Normative References [1] 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. [2] Mahy, R., "Requirements for Connection Reuse in the Session Initiation Protocol (SIP)", draft-ietf-sipping-connect-reuse-reqs00 (work in progress), October 2002. [3] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999. Informational References [4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., \ Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. Jain Expires - November 2004 [Page 12] Internet-Draft Persistent Connection Reqs May 2004 Author's Addresses Rajnish Jain Excel Switching Corporation, 75 Perseverance Way, Hyannis, Massachusetts 02601 Email: rajnishjain@xl.com Vijay K. Gurbani Lucent Technologies, Inc. 2000 Lucent Lane Rm 6G-440 Naperville, IL 60566, US Email: vkg@lucent.com Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Jain Expires - November 2004 [Page 13] Internet-Draft Persistent Connection Reqs May 2004 Jain Expires - November 2004 [Page 14]