One document matched: draft-jain-sipping-persistent-conn-reqs-02.txt
Differences from draft-jain-sipping-persistent-conn-reqs-01.txt
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.
<BNF for "Supported", "Persistent-Timeout" and "Min-Persistence"
to be added later>.
7. Security Considerations
<To be provided>
8. IANA Considerations
<To be provided>
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] | PAFTECH AB 2003-2026 | 2026-04-23 15:53:29 |