One document matched: draft-noel-soc-overload-rate-control-01.txt

Differences from draft-noel-soc-overload-rate-control-00.txt

SOC Working Group                                             Eric Noel
Internet-Draft                                                AT&T Labs
Intended status: Standards Track                      Philip M Williams
Expires: March 5 2012                              BT Innovate & Design
                                                             Janet Gunn
                                                                    CSC

                                                      September 2, 2011


              Session Initiation Protocol (SIP) Rate Control
                draft-noel-soc-overload-rate-control-01.txt


Abstract

   The prevalent use of Session Initiation Protocol (SIP) [RFC3261] in
   Next Generation Networks necessitates that SIP networks provide
   adequate control mechanisms to optimize transaction throughput and
   prevent congestion collapse during traffic overloads. Already
   [draft-ietf-soc-overload-control-03] proposes a loss-based solution
   to remedy known vulnerabilities of the [RFC3261] SIP 503 (service
   unavailable) overload control mechanism. This document proposes a
   rate-based control solution to complement the loss-based control
   defined in [draft-ietf-soc-overload-control-03].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on February 2, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors. All rights reserved.




Noel, et al.           Expires February 2, 2012                [Page 1]

Internet-Draft             SIP Rate Control              September 2011


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document. Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.

Table of Contents

   1. Introduction...................................................2
   2. Terminology....................................................3
   3. Rate-based algorithm scheme....................................3
      3.1. Overview..................................................3
      3.2. Client and server rate-control algorithm selection........4
      3.3. Server operation..........................................4
      3.4. Client operation (default algorithm)......................5
   4. Example........................................................6
   5. Syntax.........................................................7
   6. Security Considerations........................................7
   7. IANA Considerations............................................8
   8. References.....................................................8
      8.1. Normative References......................................8
      8.2. Informative References....................................8
   Appendix A. Acknowledgments.......................................9

1. Introduction

   The use of SIP in large scale Next Generation Networks requires that
   SIP based networks provide adequate control mechanisms for handling
   traffic growth. In particular, SIP networks must be able to handle
   traffic overloads gracefully, optimizing transaction throughput
   without causing congestion collapse.

   A promising SIP based overload control solution has been proposed in
   [draft-ietf-soc-overload-control-03]. That solution includes a
   default loss-based overload control algorithm that makes it possible
   for a set of clients to limit offered load towards an overloaded
   server.

   However, such loss control algorithm is sensitive to variations in
   load so that any increase in load would be directly reflected by the
   clients in the offered load presented to the overloaded servers. In


Noel, et al.            Expires March 2, 2012                  [Page 2]

Internet-Draft             SIP Rate Control              September 2011


   other words, a loss-based control cannot guarantee clients to
   produce a constant offered load towards an overloaded server.

   This document proposes a rate-based control that guarantees clients
   produce a constant offered load towards an overloaded server.  The
   penalty for such a benefit is in terms of algorithmic complexity,
   since the overloaded server must estimate a target offered load and
   allocate a portion to each conversing client.

   The proposed rate-based overload control algorithm mitigates
   congestion in SIP networks while adhering to the overload signaling
   scheme in [draft-ietf-soc-overload-control-03] and proposing a rate
   control in addition to the default loss-based control in [draft-
   ietf-soc-overload-control-03].

2. Terminology

   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 [RFC2119].

   The normative statements in this specification as they apply to SIP
   clients and SIP servers assume that both the SIP clients and SIP
   servers support this specification.  If, for instance, only a SIP
   client supports this specification and not the SIP server, then
   follows that the normative statements in this specification
   pertinent to the behavior of a SIP server do not apply to the server
   that does not support this specification.


3. Rate-based algorithm scheme

3.1. Overview

   The server is what the overload control algorithm defined here
   protects and the client is what throttles traffic towards the
   client.

   Following the procedures defined in [draft-ietf-soc-overload-
   control-03], the server and clients signal one another support for
   rate-based overload control.



Noel, et al.            Expires March 2, 2012                  [Page 3]

Internet-Draft             SIP Rate Control              September 2011


   Then periodically, the server relies on internal measurements (e.g.
   CPU utilization, queueing delay...) to evaluate its overload state
   and estimate a target SIP request rate (as opposed to target percent
   loss in the case of loss-based control).

   When in overload, the server uses [draft-ietf-soc-overload-control-
   03] via header oc parameters of SIP responses to inform the clients
   of its overload state and of the target SIP request rate.

   Upon receiving the oc parameters with a target SIP request rate,
   each client throttles new SIP requests towards the overloaded
   server.

3.2. Client and server rate-control algorithm selection

   Per [draft-ietf-soc-overload-control-03], new clients indicate
   supported overload control algorithms to servers by inserting oc and
   oc-algo in Via header of SIP requests destined to servers.  While
   servers notify clients of selected overload control algorithm
   through the oc-algo parameter in the Via header of SIP responses to
   clients.

   Support of rate-based control MUST be indicated by clients and
   servers by setting oc-algo to "rate".


3.3. Server operation

   The actual algorithm used by the server to determine its overload
   state and estimate a target SIP request rate is beyond the scope of
   this document.

   However, the server MUST be able to evaluate periodically its
   overload state and estimate a target SIP request rate beyond which
   it would become overloaded. The server must allocate a portion of
   the target SIP request rate to each of its client.

   Upon detection of overload, the server MUST follow the
   specifications in [draft-ietf-soc-overload-control-03] to notify its
   clients of its overload state and of the allocated target SIP
   request rate.



Noel, et al.            Expires March 2, 2012                  [Page 4]

Internet-Draft             SIP Rate Control              September 2011


   The server MUST use [draft-ietf-soc-overload-control-03] oc
   parameter to send a target SIP request rate to each of its client.


3.4. Client operation (default algorithm)

   To throttle new SIP requests at the rate specified in the oc value
   sent by the server to its clients, the client MAY use the proposed
   default algorithm for rate-based control or any other equivalent
   algorithm.

   The default Leaky Bucket algorithm presented here is based on [ITU-T
   Rec. I.371] Appendix A.2.  The algorithm makes it possible for
   client to deliver SIP requests at a rate specified in the oc value
   with tolerance TAU.

   Conceptually, the Leaky Bucket algorithm can be viewed as a finite
   capacity bucket whose real-valued content drains out at a continuous
   rate of 1 unit of content per time unit and whose content increases
   by the increment T for each forwarded SIP request. T is computed as
   the inverse of the rate specified in the oc value, namely T = 1 /
   oc-value.

   If at a new SIP request arrival the content of the bucket is less
   than or equal to the limit value TAU, then the SIP request is
   forwarded to the server; otherwise, the SIP request is rejected.

   Note that the capacity of the bucket (the upper bound of the
   counter) is (T + TAU).

   At the arrival time of the k-th new SIP request ta(k), the content
   of the bucket is provisionally updated to the value

   X' = X - ([ta(k) - LCT])

   where X is the content of the bucket after arrival of the last
   forwarded SIP request, and LCT is the time at which the last SIP
   request was forwarded.






Noel, et al.            Expires March 2, 2012                  [Page 5]

Internet-Draft             SIP Rate Control              September 2011


   If X' is less than or equal to the limit value TAU, then the new SIP
   request is forwarded and the bucket content X is set to X' (or to 0
   if X' is negative) plus the increment T, and LCT is set to the
   current time ta(k). If X' is greater than the limit value tau, then
   the new SIP request is rejected and the values of X and LCT are
   unchanged.

   At the arrival time of the first new SIP request ta(1), the content
   of the bucket X is set to zero and LCT is set to ta(1).

   Note that specification of a value for TAU is beyond the scope of
   this document.

  4. Example

   Adapting [draft-ietf-soc-overload-control-03] example in section 6.2
   where SIP client P1 sends requests to a downstream server P2:

            INVITE sips:user@example.com SIP/2.0

            Via: SIP/2.0/TLS p1.example.net;

            branch=z9hG4bK2d4790.1;received=192.0.2.111;

            oc;oc-algo="loss,rate"

            ...



            SIP/2.0 100 Trying

            Via: SIP/2.0/TLS p1.example.net;

            branch=z9hG4bK2d4790.1;received=192.0.2.111;

            oc=0;oc-algo="rate";oc-validity=500;

            oc-seq=1282321615.781

             ...






Noel, et al.            Expires March 2, 2012                  [Page 6]

Internet-Draft             SIP Rate Control              September 2011


   In the messages above, the first line is sent by P1 to P2.  This
   line is a SIP request; because P1 supports overload control, it
   inserts the "oc" parameter in the topmost Via header that it
   created. P1 supports two overload control algorithms: loss and rate.

   The second line --- a SIP response --- shows the topmost Via header
   amended by P2 according to this specification and sent to P1.
   Because P2 also supports overload control, it chooses the "rate"
   based scheme and sends that back to P1 in the "oc-algo" parameter.
   It also sets the value of "oc" parameter to 0.

   At some later time, P2 starts to experience overload. It sends the
   following SIP message indicating P1 should send SIP requests at a
   rate no greater than or equal to 150 SIP requests per seconds.

            SIP/2.0 180 Ringing

            Via: SIP/2.0/TLS p1.example.net;

            branch=z9hG4bK2d4790.1;received=192.0.2.111;

            oc=150;oc-algo="rate";oc-validity=1000;

            oc-seq=1282321615.782

             ...



  5. Syntax

   This specification extends the existing definition of the Via header
   field parameters of [RFC3261] as follows:

   oc          = "oc" EQUAL oc-value

   oc-value    = "NaN" / oc-num

   oc-num      = 1*DIGIT



6. Security Considerations

   None.




Noel, et al.            Expires March 2, 2012                  [Page 7]

Internet-Draft             SIP Rate Control              September 2011


7. IANA Considerations

   None.

8. References

8.1. Normative References

   [RFC3261] 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.

8.2. Informative References

   [draft-ietf-soc-overload-control-03]
             Gurbani, V., Hilt, V., Schulzrinne, H., "Session
             Initiation Protocol (SIP) Overload Control", draft-ietf-
             soc-overload-control-03.


   [ITU-T Rec. I.371]
             "Traffic control and congestion control in B-ISDN", ITU-T
             Recommendation I.371.

























Noel, et al.            Expires March 2, 2012                  [Page 8]

Internet-Draft             SIP Rate Control              September 2011


Appendix A.                 Acknowledgments

   Many thanks for the contributions, comments and feedback on this
   document to:

   This document was prepared using 2-Word-v2.0.template.dot.



   Authors' Addresses

   Eric Noel
   AT&T Labs
   200s Laurel Avenue
   Middletown, NJ, 07747
   USA

   Philip M Williams
   BT Innovate & Design
   UK

   Janet Gunn
   CSC
   USA























Noel, et al.            Expires March 2, 2012                  [Page 9]