Subject: Re: [sip-overload] Fwd: draft-shen-sipping-avalanche-restart-overload-00

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 2 Feb 2010 08:27:07 +0530

Hi Charles,
 
The draft looks good. I have few comments:
 
1) The proposed mechanism assumes that UA have the capability to store the configuration in memory. This may not be appropriate in case of UA with zero SIP configuration and configuration is downloaded from config server. In case default register restart timer (say 5 or 10 sec) is mentioned in UA configuration, this problem may be solved.
 
2) Sec 4.3 assumes that Register will be the first message by UA. In case SIP based configuration mechanism is followed, SUBSCRIBE will be send by UA to SIP configuration server to get Registrar address and other SIP related configuration and REGISTER message follows next. In this scenario, SUBSCRIBE should have restart-timer rather than REGISTER. 
 
Thanks
Partha

________________________________

From: [email-masked] on behalf of Charles Shen
Sent: Thu 12/3/2009 8:01 PM
To: [email-masked]
Cc: Arata Koike; Henning Schulzrinne
Subject: [sip-overload] Fwd: draft-shen-sipping-avalanche-restart-overload-00

Hi all, we've submitted the following draft, comments appreciated.

A Mechanism for Session Initiation Protocol (SIP) Avalanche Restart
Overload Control

http://tools.ietf.org/html/draft-shen-sipping-avalanche-restart-overload-00

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 Register-Restart header in registration
  responses.  Once an avalanche restart actually occurs, the clients
  perform backoff based on the previously received Register-Restart
  header value before sending out the first registration attempt.
  Thus, the mechanism spreads all the initial client registration
  requests and prevents them from overloading the registrar server.

Thanks

Charles
_______________________________________________
sip-overload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sip-overload

---

From: Charles Shen <[email-masked]>
Date: Thu, 4 Feb 2010 15:56:22 -0500

Hi Partha: thanks for the comments, please see inline.

On Mon, Feb 1, 2010 at 9:57 PM, Parthasarathi R (partr) <[email-masked]> wrote:
> 1) The proposed mechanism assumes that UA have the capability to store the
> configuration in memory. This may not be appropriate in case of UA with zero
> SIP configuration and configuration is downloaded from config server. In
> case default register restart timer (say 5 or 10 sec) is mentioned in UA
> configuration, this problem may be solved.

But shouldn't the UA normally have some flash memory (e.g., storing
the initial server to contact after boot-up)? In that case, couldn't
the timer information be stored in those flash memory as well?

> 2) Sec 4.3 assumes that Register will be the first message by UA. In case
> SIP based configuration mechanism is followed, SUBSCRIBE will be send by UA
> to SIP configuration server to get Registrar address and other SIP related
> configuration and REGISTER message follows next. In this scenario, SUBSCRIBE
> should have restart-timer rather than REGISTER.

This is a very good point. We might then think of revising the name of
the new header from  REGISTER-RESTART to RESTART-TIMER instead to make
it more generic.

Thanks!

Charles

> Subject: [sip-overload] Fwd:
> draft-shen-sipping-avalanche-restart-overload-00
>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 8 Feb 2010 09:32:08 +0530

Hi Shen,
 
In case of zero configuration entity (SIP UA), DHCP discovery mechanism is used to discover the configuration server. The configuration server may use SIP or non-SIP mechanism. In these deployment, Entity will not have any configuration information within itself. I mentioned this caveat as most of these entities will not have mechanism to upload the configuration to configuration server which means that these entities only download the configuration from config server. I may be looking from one of the deployment scenario, Let others comments whether this deployment has to be considered.
 
Thanks
Partha

From: [email-masked] on behalf of Charles Shen
Sent: Fri 2/5/2010 2:26 AM
To: Parthasarathi R (partr)
Cc: [email-masked]; Arata Koike; Henning Schulzrinne
Subject: Re: [sip-overload] Fwd: draft-shen-sipping-avalanche-restart-overload-00

Thanks!

Charles