Hi Paul, When dealing with a similar problem we have approached it on our edge proxies similar to traffic flow queuing disciplines (GRED to be precise). An edge proxy would measure average registration processing time for a back end registration server. When average processing time exceeds the normal processing time limit (100 ms in our case), the edge proxy will start randomly refusing a gradually increasing percentage of the registration messages. When average processing time exceeds the overload processing time limit (250 ms in our case), the edge proxy will refuse all registration messages. When registration messages were refused, proxy would send a 500 error response with Retry-After header set to a random value between 30 and 60 s.
Regards, _____________ Roman Shpount On Wed, Aug 10, 2016 at 11:00 AM, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote: > I refreshed my memory on that draft. It proposes a new header field for > the registrar to tell the UA what to do after a failure. That may indeed be > necessary for an ideal solution. > > Does anyone know of a documented approach using only *existing* sip > features? > > Thanks, > Paul > > > On 8/10/16 10:45 AM, Paul Kyzivat wrote: > >> Thanks to Volkan and Brett for this reference. I'll review it. >> >> Anybody else have something different? >> >> Thanks, >> Paul >> >> On 8/10/16 10:35 AM, Brett Tate wrote: >> >>> Hi Paul, >>> >>> The topic is discussed within draft-shen-soc-avalanche-restart-overload; >>> however I don't recall why the draft didn't progress further within >>> soc or >>> dispatch. >>> >>> -----Original Message----- >>>> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- >>>> implementors-boun...@lists.cs.columbia.edu] On Behalf Of Paul Kyzivat >>>> Sent: Wednesday, August 10, 2016 10:08 AM >>>> To: Sip-implementors@lists.cs.columbia.edu >>>> Subject: [Sip-implementors] backoff algorithms to prevent registration >>>> storms? >>>> >>>> Strategies for preventing registration storms (e.g., after a major power >>>> outage and recovery) have been discussed from time to time. >>>> >>>> Can anyone point me to specific documentation of such schemes? Ideally a >>>> >>> spec >>> >>>> that can be referenced, but failing that I'll be happy with pointers to >>>> thorough email discussions or non-standard implementations. >>>> >>>> Thanks, >>>> Paul >>>> _______________________________________________ >>>> Sip-implementors mailing list >>>> Sip-implementors@lists.cs.columbia.edu >>>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >>>> >>> >>> >> _______________________________________________ >> Sip-implementors mailing list >> Sip-implementors@lists.cs.columbia.edu >> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >> >> > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
