One document matched: draft-sparks-sipping-load-00.txt

Network Working Group                                          R. Sparks
Internet-Draft                                               dynamicsoft
Expires: April 16, 2004                                 October 17, 2003


                          SIP Load Management
                      draft-sparks-sipping-load-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 April 16, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

   As deployments of services based on the Session Initiation Protocol
   increase in scope, managing load across the systems providing their
   services becomes increasingly important. This document looks at
   generic load management requirements and the tools to address them
   currently available in the protocol. Potential new tools to better
   meet the requirements are proposed.










Sparks                   Expires April 16, 2004                 [Page 1]

Internet-Draft            SIP Load Management               October 2003


Table of Contents

   1.  Problem statement  . . . . . . . . . . . . . . . . . . . . . .  3
   1.1 Load contributors  . . . . . . . . . . . . . . . . . . . . . .  3
   1.2 Clustering . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Currently available SIP mechanisms . . . . . . . . . . . . . .  4
   2.1 Redirection  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.2 503 unavailability . . . . . . . . . . . . . . . . . . . . . .  4
   2.3 REFER  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Proposals for new tools  . . . . . . . . . . . . . . . . . . .  5
   3.1 Throttling . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.2 Modifying route-sets . . . . . . . . . . . . . . . . . . . . .  6
   4.  Recommendations  . . . . . . . . . . . . . . . . . . . . . . .  6
       References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  7
       Intellectual Property and Copyright Statements . . . . . . . .  8



































Sparks                   Expires April 16, 2004                 [Page 2]

Internet-Draft            SIP Load Management               October 2003


1. Problem statement

   A SIP element, either an endpoint or an intermediary, has an upper
   bound on the volume of SIP traffic it can (or is willing to) process.
   When ambient demand exceeds that volume, the element and its SIP
   peers must behave such that

   o  The application constructed using SIP can continue to exhibit
      predictable behavior.

   o  The element continues to receive volume near, but not above, its
      limit.

   When an element's capacity changes, either increasing or decreasing,
   the element and its SIP peers must behave such that existing volume
   toward the element is modified to be near, but not above, the new
   capacity.  This behavior must encompass the special case of changing
   to a capacity of zero (allowing a controlled shutdown for example).

   These behaviors might be achievable using mechanisms entirely outside
   SIP, but providing support from within the protocol may allow them to
   be realized with less effort. Some in-protocol support already
   exists.

   This document discusses realizing those behaviors using proxies and
   PSTN gateways as concrete examples of intermediaries and endpoints to
   take advantage of the widespread familiarity with those elements. The
   discussion is applicable, however, to arbitrary SIP elements. The
   document also uses the terms "traffic volume" and "load"
   interchangeably.

1.1 Load contributors

   Load can arrive at an element from one or multiple sources. These
   sources may vary the size of their contribution over time. The
   contribution can range from being evenly distributed across all
   sources to one source providing nearly the total load. A proxy could
   be processing traffic for thousands of directly connected endpoints,
   or could be isolated such that it only ever communicates with one or
   two neighboring proxies. Likewise, a gateway could have thousands of
   endpoints utilizing it directly, or could be isolated such that all
   SIP traffic comes through one proxy. The behaviors above must be
   effective given any configuration of contributors.

1.2 Clustering

   Systems frequently provide higher capacity than is achievable with a
   single element by distributing load across a cluster of elements.



Sparks                   Expires April 16, 2004                 [Page 3]

Internet-Draft            SIP Load Management               October 2003


   These systems must be able to distribute load across these elements
   in such a way that each element can operate near, but not above, its
   limit.

2. Currently available SIP mechanisms

2.1 Redirection

   An element can redirect some types of request to a peer using a 3xx
   response. This can be used to redirect load. For instance, a gateway
   can redirect initial INVITEs to a peer, thus avoiding the load
   associated with the remainder of the messages in the dialog it might
   create. Only load directed toward the Request-URI of this request
   will be redirected, so this tool is most valuable when requests to
   this URI represent a significant fraction of the total load.

   The duration of this redirection can be controlled with a 1 second
   granularity by using a 302 response with either an Expires header
   field, or an expires parameter on the Contact header field value.

   Care needs to be taken in such systems to avoid redirect-loops. If A
   redirects to B and B redirects to A, a requester will consider the
   last redirection an unrecoverable failure.

   This mechanism is only applicable to out-of-dialog requests. Behavior
   upon receiving a 300-class response in-dialog is not explicitly
   specified in [1], nor is there a prohibition against issuing a
   300-class response in-dialog. The immutability of a dialog's
   route-set adds difficulty to making in-dialog redirection meaningful,
   particularly at a proxy.

2.2 503 unavailability

   An element can squelch all traffic from a source by returning a 503
   to any request from that source. Per [2] the peer will treat this
   response as a transport error and quit sending traffic over this
   transport, failing over to another through SRV. The duration of the
   squelch can be controlled with a 1 second granularity by providing a
   Retry-After header field in the response. This can be useful for
   controlling load when there are multiple contributors. Its
   all-or-nothing nature reduces its utility when the environment
   contains only one or two peers. It is particularly unhelpful for a
   gateway behind a single protecting proxy or a proxy in a pipeline
   with exactly one peer to either side.

   Behavior on receipt of a 503 without a Retry-After header is
   underspecified. It is possible that emitting a 503 without a
   Retry-After could squelch all future traffic from a peer (until the



Sparks                   Expires April 16, 2004                 [Page 4]

Internet-Draft            SIP Load Management               October 2003


   squelch is reset manually at the peer). [3] proposes refining the
   caching behavior in [2] to improve behavior in this scenario.

2.3 REFER

   Load at an endpoint within an existing dialog can increase (or
   capacity may decrease) driving total load beyond the endpoint's
   capacity. Shedding non-dialog-related load may not be sufficient to
   bring total load below capacity. An endpoint can shed dialog related
   load by terminating the dialog (BYE to INVITE, unSUBSCRIBE or NOTIFY/
   Terminated for SUBSCRIBE or REFER related dialogs). If a system can
   preserve the value of the dialog to the SIP application by
   transferring the state-association related to the dialog to a peer
   endpoint, the endpoint can use REFER to do so before terminating the
   dialog locally. For instance, a gateway might transfer all calls
   currently using one of its trunks to a peer to allow that trunk to be
   taken out of service.

3. Proposals for new tools

3.1 Throttling

   The all-or-nothing nature of 503 is too coarse. A tool that allowed
   traffic to continue to arrive from a peer, but at a reduced rate,
   would be useful. As a strawman, consider a new method "THROTTLE" that
   contains a "Gap:" header field with an integer value representing
   milliseconds. A peer accepting a THROTTLE agrees to send messages no
   closer than that number of milliseconds apart. This will allow an
   element with, say, one peer to continue to receive load near its
   capacity, whereas the 503 mechanism introduces bursts of no-load.

   A request is proposed over a response for the following reasons:

   o  It is less error-prone to control the propagation distance of a
      request (using both the Request-URI and Max-Forwards). It also
      provides a feedback channel, in the form of the SIP response, that
      can carry information from the peer about its support for
      throttling.

   o  An element can be pro-active in managing load using this request
      before it reaches saturation.

   Using an error response would require rejecting a request that was
   otherwise acceptable. It will be difficult to extend success
   responses to carry a throttle indicator and limit the effect of that
   indicator to the first hop (a proxy that didn't understand the
   indicator would forward it, resulting in throttling load to itself
   unintentionally).



Sparks                   Expires April 16, 2004                 [Page 5]

Internet-Draft            SIP Load Management               October 2003


3.2 Modifying route-sets

   It is necessary to be able to take a proxy out of service without
   destroying the future of any existing dialogs that happen to have
   that proxy in their route-set. Currently, the only protocol-supported
   way to do this is to provide an alternate instantiation of that proxy
   via DNS SRV records. It would be useful for a proxy to indicate that
   it wants out of the path. Consider, for example, a proxy on the path
   to a presence server carrying thousands of active subscriptions. If
   this proxy had to be removed from service and another instance
   couldn't be provided through DNS, the system would have to endure
   thousands error detections and generation of new subscriptions. If
   notifications on the original dialogs are infrequent, this may mean
   the presence server will carry double its subscription load until the
   original dialogs expire.

   It would be better if the proxy could either modify the route set
   inside this dialog or indicate to both ends that it wants this dialog
   torn down. The later could be achieved with something like a

   Proxy-Desires: terminate-session

    added to both the request and response of any transaction within the
   dialog.

4. Recommendations

   If this brief analysis survives review, then we should

   o  Refine the 503 caching mechanics in RFC 3263

   o  Begin work on a throttling tool in the SIP working group

   o  Begin work on allowing a proxy to modify route sets or request
      dialog termination in the SIP working group

   o  Capture the results in this document and expand it into an
      informational document recommending load management practices that
      involve using SIP mechanisms.

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]  Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
        (SIP): Locating SIP Servers", RFC 3263, June 2002.



Sparks                   Expires April 16, 2004                 [Page 6]

Internet-Draft            SIP Load Management               October 2003


   [3]  Sparks, R., "Considerations for the Session Initiation
        Protocol's non-INVITE Transaction",
        draft-sparks-sip-noninvite-01 (work in progress), October 2003.


Author's Address

   Robert J. Sparks
   dynamicsoft
   5100 Tennyson Parkway
   Suite 1200
   Plano, TX  75024

   EMail: rsparks@dynamicsoft.com





































Sparks                   Expires April 16, 2004                 [Page 7]

Internet-Draft            SIP Load Management               October 2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


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 assignees.

   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



Sparks                   Expires April 16, 2004                 [Page 8]

Internet-Draft            SIP Load Management               October 2003


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Sparks                   Expires April 16, 2004                 [Page 9]