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

[Janet P Gunn <[e-mail]>]

I have an overall concern for this draft in that it attempts to find a 
solution for a specific situation, without sufficiently addressing the 
(negative) unintended consequences in a variety of other situations.

The basic problem is that the behavior which helps in an “avalanche 
restart” scenario is  “bad for business” in a wide variety of other 
restart scenarios, and it is highly unlikely that either the user or the 
user agent can determine which is which.
For instance, the “example” in section 3.1 suggests that 300 seconds (5 
minutes) is a reasonable value for the restart backoff interval (thus the 
average backoff would be 2.5 minutes).
This is entirely plausible for an “avalanche restart” event.  But I don’t 
think it will be acceptable, to either the users or the Service Providers, 
every time a mobile User Agent needs to register due to a “power off 
recovery” or a “connection loss recovery”. 
The draft suggests that the client side backoff MAY be disabled by  the 
human operator.  But, in the vast majority of cases, the human operator 
has no way of knowing whether it is an isolated re register or an 
avalanche event.   I suspect that the vast majority of users would be 
oblivious, and never disable it, and that the more sophisticated users, 
who know about it, would always disable it.  Even the knowledgeable but 
considerate user is unlikely to know whether this is a local, “only me” 
re-connection, or an avalanche.
The Service providers are unlikely to be willing to sacrifice an average 
of 150 seconds of potentially billable calls  on every power up or 
connection re-establishment.  And if it provided a rival  Service Provider 
the opportunity to  offer  “Up to 300 seconds faster initial connection” 
the marketing department would never permit it.
A noble attempt to address a real problem, but I fear it is defeated by 
the devil of “unintended consequences”
Janet

[e-mail] wrote on 12/03/2009 09:31:11 AM:

> Charles Shen <[e-mail]> 
> Sent by: [e-mail]
> 
> 12/03/2009 09:31 AM
> 
> To
> 
> [e-mail]
> 
> cc
> 
> Arata Koike <[e-mail]>, Henning Schulzrinne 
> <[e-mail]>
> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-overload