Paul, I have mentioned this to your before, we also did registration message caching in our edge proxies to reduce the load on the back end registration servers. In our particular deployment, we did not show all the registrations for the AOR to the end point and we could cash the client credentials, which allowed for fairly efficient in-memory caching. Furthermore, in this deployment, edge proxies were responsible for inbound SIP message rate limiting (per IP and per /24 network), TLS to UDP proxy between the client and the back end, and overload protection which was based on the described algorithm. One thing to note was that a failure of the edge proxy often caused a load spike on other edge proxies due to clients detecting the TLS flow failure and re-registering, The overload protection algorithm was primarily in place to handle such load spikes gracefully.
Regards, Regards, _____________ Roman Shpount On Wed, Aug 10, 2016 at 3:35 PM, Paul Kyzivat <[email protected]> wrote: > Roman, > > Interesting. That takes the load off the registrars, but the edge proxies > still must handle it. > > Thanks, > Paul > > On 8/10/16 1:40 PM, Roman Shpount wrote: > >> 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 <[email protected] >> <mailto:[email protected]>> 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: [email protected] >> <mailto:[email protected]> >> [mailto:sip- <mailto:sip-> >> [email protected] >> <mailto:[email protected]>] On >> Behalf Of Paul Kyzivat >> Sent: Wednesday, August 10, 2016 10:08 AM >> To: [email protected] >> <mailto:[email protected]> >> 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 >> [email protected] >> <mailto:[email protected]> >> https://lists.cs.columbia.edu/ >> mailman/listinfo/sip-implementors >> <https://lists.cs.columbia.edu >> /mailman/listinfo/sip-implementors> >> >> >> >> _______________________________________________ >> Sip-implementors mailing list >> [email protected] >> <mailto:[email protected]> >> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >> <https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors> >> >> >> _______________________________________________ >> Sip-implementors mailing list >> [email protected] >> <mailto:[email protected]> >> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >> <https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors> >> >> >> > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
