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 <pkyzi...@alum.mit.edu
<mailto: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>
[mailto:sip- <mailto:sip->
implementors-boun...@lists.cs.columbia.edu
<mailto: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
<mailto: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
<mailto:Sip-implementors@lists.cs.columbia.edu>
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
<https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
<mailto:Sip-implementors@lists.cs.columbia.edu>
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
<https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
<mailto:Sip-implementors@lists.cs.columbia.edu>
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
<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
