IETF SIPPING Working Group                                       C. Shen
Internet-Draft                                            H. Schulzrinne
Intended status: Standards Track                             Columbia U.
Expires: November 24, 2010                                      A. Koike
                                                                     NTT
                                                            May 23, 2010


  A Mechanism for Session Initiation Protocol (SIP) Avalanche Restart
                            Overload Control
            draft-shen-sipping-avalanche-restart-overload-01

Abstract

   When a large number of clients register with a SIP registrar server
   at approximately the same time, the server may become overloaded.
   Near-simultaneous floods of SIP SUBSCRIBE and PUBLISH requests may
   have similar effects.  Such request avalanches can occur, for
   example, after a power failure and recovery in a metropolitan area.
   This document describes how to avoid such overload situations.  Under
   this mechanism, a server estimates an avalanche restart backoff
   interval during its normal operation and conveys this interval to its
   clients through a new Restart-Timer header in normal response
   messages.  Once an avalanche restart actually occurs, the clients
   perform backoff based on the previously received Restart-Timer header
   value before sending out the first request attempt.  Thus, the
   mechanism spreads all the initial client requests and prevents them
   from overloading the server.

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 November 24, 2010.

Copyright Notice




Shen, et al.            Expires November 24, 2010               [Page 1]


Internet-Draft   SIP Avalanche Restart Overload Control         May 2010


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

   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  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   3.  Restart-Timer Header for Registration Responses . . . . . . . . 5
     3.1.  Generating the Restart-Timer Header . . . . . . . . . . . . 5
     3.2.  Determining the Restart-Timer Header Value  . . . . . . . . 5
     3.3.  Processing the Restart-Timer Header . . . . . . . . . . . . 6
     3.4.  Using the Restart-Timer Header  . . . . . . . . . . . . . . 6
   4.  Syntax  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   5.  Backward Compatibility  . . . . . . . . . . . . . . . . . . . . 7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9



















Shen, et al.            Expires November 24, 2010               [Page 2]


Internet-Draft   SIP Avalanche Restart Overload Control         May 2010


1.  Introduction

   A Session Initiation Protocol (SIP) [RFC3261] server can be
   overloaded for a number of different reasons.  One of them is
   avalanche restart, which is described in [RFC5390] as follows:

      Avalanche Restart: One of the most troubling sources of overload
      is avalanche restart.  This happens when a large number of clients
      all simultaneously attempt to connect to the network with a SIP
      registration.  Avalanche restart can be caused by several events.
      One is the "Manhattan Reboots" scenario, where there is a power
      failure in a large metropolitan area, such as Manhattan.  When
      power is restored, all of the SIP phones, whether in PCs or
      standalone devices, simultaneously power on and begin booting.
      They will all then connect to the network and register, causing a
      flood of SIP registration messages.  Another cause of avalanche
      restart is failure of a large network connection, for example, the
      access router for an enterprise.  When it fails, SIP clients will
      detect the failure rapidly using the mechanisms in [RFC5626].
      When connectivity is restored, this is detected, and clients re-
      registration, all within a short time period.  Another source of
      avalanche restart is failure of a proxy server.  If clients had
      all connected to the server with TCP, its failure will be
      detected, followed by re-connection and re-registration to another
      server.  Note that [RFC5626] does provide some remedies to this
      case.

   The SIP server avalanche restart overload problem is caused by the
   synchronized, simultaneous initial registration attempts after a
   failure recovery.  If the first round of registration attempts from
   all clients cause server overload, most of those registrations will
   fail.  Those clients will then by default all retry after the same
   amount of time, causing repeated server avalanche restart overload.
   [RFC5626] describes how to alleviate this situation: if the initial
   registration attempt after the boot fails, the clients wait for a
   randomized backoff time before retrying.  This mechanism reduces the
   possibility of repeated avalanche restart.  However, since all
   clients still send registration immediately after boot, it does not
   prevent the initial avalanche restart overload.

   A key method to prevent avalanche restart server overload is to have
   clients backoff before their first registration attempt.  The backoff
   intervals of each client must be carefully selected so that their
   registration attempts are spaced sufficiently far apart not to
   overload the server, and they are also not too conservative which may
   cause unnecessary client registration delays.  An individual client,
   without knowing the state information of all other peer clients and
   the registrar server, is inherently incapable of choosing such an



Shen, et al.            Expires November 24, 2010               [Page 3]


Internet-Draft   SIP Avalanche Restart Overload Control         May 2010


   appropriate backoff interval.

   This document specifies a solution to the avalanche restart overload
   problem by allowing the registrar server to instruct the clients how
   long they should wait before the initial registration upon a restart
   event.  Under this mechanism, the server estimates an avalanche
   restart backoff interval during its normal operation.  This interval
   is the minimum period of time that the server needs to serve all the
   expected registration requests after an avalanche restart, assuming
   all the registration requests are properly spaced.  In order for the
   server to convey this interval to its clients, this document defines
   a new SIP Restart-Timer header.  The registrar server places the
   avalanche restart backoff interval into the Restart-Timer header and
   inserts it into regular responses to client registration requests.
   When an avalanche restart actually happens, each client waits a
   randomly-chosen period between 0 and the avalanche restart backoff
   interval.

   This document also defines an algorithm to determine the avalanche
   restart backoff interval based on the server's processing capability
   and the number of clients it is serving.  The effectiveness of this
   algorithm depends on the assumption that both the server processing
   capability and the number of clients the server serves remain similar
   before and after the avalanche restart.  This assumption holds true
   in most cases when the registrar server before and after the
   avalanche restart is the same one, e.g., in the "Manhattan Reboots"
   scenario, and the loss and recovery of large network connection
   scenario.

   The method defined in this document is intended to be used for real
   avalanche restart situations, rather than just any local reboot or
   connection recovery.  Therefore, the device employing this mechanism
   SHOULD try to estimate the nature of the restart incidents whenever
   possible.  Some devices, especially mobile terminals, may also have
   lower layer (e.g., Physical or Data Link layer) backoff or blocking
   mechanisms during avalanche restart or network congestion.  In those
   cases, operators may also disable this application layer avalanche
   restart protection method.  Such cross-layer optimizations, however,
   are out of scope of this document.

   Throughout this document our description assumes the typical scenario
   where the clients send out REGISTER messages as the first message
   type after a restart and cause avalanche restart overload on the
   registrar server.  It should be noted that similar procedures are
   applicable to scenarios where the first message after reboot is of a
   different type and causes overload.  For example, when SIP based
   configuration mechanism is followed, the clients may first send out
   SUBSCRIBE messages to a SIP configuration server to get the registrar



Shen, et al.            Expires November 24, 2010               [Page 4]


Internet-Draft   SIP Avalanche Restart Overload Control         May 2010


   address after a reboot.  In that case, the server that determines the
   restart backoff interval needs to be the corresponding SIP
   configuration server, and the backoff mechanism could then be
   similarly applied to the sending of the initial SUBSCRIBE messages.

   This document complements other SIP server overload control
   specifications which address different aspects of the SIP server
   overload space, such as [I-D.hilt-sipping-overload],
   [I-D.shen-sipping-load-control-event-package], and
   [I-D.ietf-sipping-overload-design].


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


3.  Restart-Timer Header for Registration Responses

   This document defines the SIP Restart-Timer header for registration
   responses.  The value of the Restart-Timer header, in seconds,
   denotes the avalanche restart backoff interval, which is the minimum
   time the server needs to successfully service all likely client
   registration requests under an avalanche restart situation, assuming
   all requests are spaced evenly in time.

3.1.  Generating the Restart-Timer Header

   A SIP registrar server inserts a Restart-Timer header containing its
   most up-to-date avalanche restart backoff interval value in the
   responses to registration requests.

   Example:

       SIP/2.0 200 OK
       Restart-Timer: 300

3.2.  Determining the Restart-Timer Header Value

   A registrar server computes and updates the Restart-Timer header
   values and conveys them to the clients during its normal operations.
   Once an avalanche restart actually happens, the most recent Restart-
   Timer header value that the clients have received from the registrar
   server are used.  A registrar server MAY use the following algorithm
   for determining the appropriate Restart-Timer header value.




Shen, et al.            Expires November 24, 2010               [Page 5]


Internet-Draft   SIP Avalanche Restart Overload Control         May 2010


   During the normal operation period, the SIP registrar server
   maintains the current count of all its registrants, e.g., assuming
   the number of registered clients is R. The SIP registrar server also
   estimates its processing capacity, e.g., assuming it is C requests
   per second.  The Restart-Timer value can be set to (R/C)*(1+k), where
   k is a small coefficient that provides a capacity redundancy.  A
   recommended value of k is 0.1.

   It should be noted that change of either R or C adjusts the server
   computed Restart-Timer value.  The value C is usually stable on the
   same server and with the same registration request pattern.  The
   value R may change over time.  The server SHOULD recompute the
   Restart-Timer value whenever there is a change in either R or C,
   unless it is considered too expensive to do so, which is normally not
   the case.  Since the updated Restart-Timer value is only pushed to
   the clients when the client sends in a registration, there might be a
   short period where the server side updated Restart-Timer value and
   some client side stored Restart-Timer values are not synchronized.
   However, considering that the changing pace of R is slow, and the
   time scale between the possible happenings of avalanche restarts
   (e.g., months) is usually much larger than the interval between
   typical registration renewals (e.g., hours), these short periods of
   discrepancies are not a concern.  Therefore, in general this approach
   provides a sufficiently accurate characterization of the system
   status.  More importantly, the values of R and C are expected to
   remain constant for the same server before and after typical
   avalanche restart events, e.g., a power failure and recovery.

3.3.  Processing the Restart-Timer Header

   Before receiving the very first registration response from a new
   registrar server, the client restart backoff value for that registrar
   server is zero, i.e., the restart backoff mechanism is disabled.

   Upon receiving a response to the registration request containing the
   Restart-Timer header, a SIP client that supports this specification
   MUST check if there is an existing Restart-Timer header value for
   this registrar stored in the system.  If not, it stores the newly
   received Restart-Timer header value.  Otherwise, it compares the new
   value with the existing one and updates it if they differ.  The value
   of Restart-Timer header SHOULD be stored together with the
   corresponding identity of the server, e.g., the DNS name of the
   registrar server.  There is no separate validity period parameter for
   Restart-Timer.  The validity duration of the Restart-Timer header is
   the same as that of the corresponding registration operation.

3.4.  Using the Restart-Timer Header




Shen, et al.            Expires November 24, 2010               [Page 6]


Internet-Draft   SIP Avalanche Restart Overload Control         May 2010


   At the client side, avalanche restart backoff is disabled by default,
   unless the client that supports this specification has received a
   positive Restart-Timer header value from the corresponding registrar
   server.

   A SIP client always keeps the most updated Restart-Timer header
   value.  When this value is positive and if the client detects that it
   is about to perform the first registration with the same registrar
   server after a power-off reboot or a connection-loss recovery, the
   client SHOULD generate a uniformly distributed random interval
   between 0 and the current Restart-Timer value, and wait until the end
   of that interval to send the registration request.  However, the
   client side backoff MAY be manually disabled by a human operator when
   necessary, e.g., when the operator is expecting an urgent call, or
   when the power-off or connection-loss event is known as a local
   incident rather than a global event.

   It should be noted that the power-off reboot case requires that the
   state information about the Restart-Timer value and the registrar
   server identity be stored in a memory space that could survive power
   restart.


4.  Syntax

   The new Restart-Timer header adds the following lines to the existing
   SIP header definition.


       message-header = Restart-Timer

       Restart-Timer = "Restart-Timer" HCOLON delta-seconds



5.  Backward Compatibility

   If a registrar server supports this specification, but not all of its
   clients are upgraded, then those non-compliant clients will ignore
   the Restart-Timer header and not perform backoff.  Although it
   appears that this might give the non-compliant clients an unfair
   advantage over those clients that do perform backoff, since the non-
   compliant clients will send synchronized registration attempts to the
   registrar server and can cause server overload, they will be
   penalized by registration failures.  Depending on the number of the
   non-compliant clients vs. compliant clients, if the registrar server
   can still process requests when it does not receive registration
   storms from all the non-compliant clients, the requests from the



Shen, et al.            Expires November 24, 2010               [Page 7]


Internet-Draft   SIP Avalanche Restart Overload Control         May 2010


   compliant clients which spread apart, are more likely to succeed.


6.  Security Considerations

   The Restart-Timer header can be used by an attacker to launch a
   possible denial-of-service attack on SIP clients if the attacker can
   insert an infinitely large Restart-Timer value in the response sent
   to the clients.  In those situations, the client may generate a very
   large backoff time before it attempts to send a registration request,
   and therefore the client is subject to denial-of-service attack.
   However, this kind of attack is only applicable after a power-cycle
   reboot or failure and recovery of a large network connection, which
   is rare.  Furthermore, if the attacker can modify the registration
   request or response, that attacker can very easily prevent
   registration in any number of ways, so the Restart-Timer header does
   not introduce new types of attacks.  One method to prevent the
   registration request and response from being altered by attackers is
   to use TLS between the client and the registrar server.


7.  IANA Considerations

   [TBD]


8.  Acknowledgements

   The authors would like to thank Janet P Gunn, Parthasarathi R and
   other members of the SIPPING and SIP-OVERLOAD working group for
   useful comments.


9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

9.2.  Informative References

   [I-D.hilt-sipping-overload]



Shen, et al.            Expires November 24, 2010               [Page 8]


Internet-Draft   SIP Avalanche Restart Overload Control         May 2010


              Hilt, V. and H. Schulzrinne, "Session Initiation Protocol
              (SIP) Overload Control", draft-hilt-sipping-overload-08
              (work in progress), April 2010.

   [I-D.ietf-sipping-overload-design]
              Hilt, V., Noel, E., Shen, C., and A. Abdelal, "Design
              Considerations for Session Initiation Protocol (SIP)
              Overload Control", draft-ietf-sipping-overload-design-02
              (work in progress), July 2009.

   [I-D.shen-sipping-load-control-event-package]
              Shen, C., Schulzrinne, H., and A. Koike, "A Session
              Initiation Protocol (SIP) Load Control Event Package",
              draft-shen-sipping-load-control-event-package-04 (work in
              progress), April 2010.

   [RFC5390]  Rosenberg, J., "Requirements for Management of Overload in
              the Session Initiation Protocol", RFC 5390, December 2008.

   [RFC5626]  Jennings, C., Mahy, R., and F. Audet, "Managing Client-
              Initiated Connections in the Session Initiation Protocol
              (SIP)", RFC 5626, October 2009.


Authors' Addresses

   Charles Shen
   Columbia University
   Department of Computer Science
   1214 Amsterdam Avenue, MC 0401
   New York, NY  10027
   USA

   Phone: +1 212 854 3109
   Email: charles@cs.columbia.edu


   Henning Schulzrinne
   Columbia University
   Department of Computer Science
   1214 Amsterdam Avenue, MC 0401
   New York, NY  10027
   USA

   Phone: +1 212 939 7004
   Email: hgs@cs.columbia.edu





Shen, et al.            Expires November 24, 2010               [Page 9]


Internet-Draft   SIP Avalanche Restart Overload Control         May 2010


   Arata Koike
   NTT Service Integration Labs &
   NTT Washington DC Representative Office
   1100 13th St., NW, Suite 900
   Washington DC,   20005
   USA

   Phone: +1 202 312 1451
   Email: koike.arata@lab.ntt.co.jp










































Shen, et al.            Expires November 24, 2010              [Page 10]