No subject


Wed Jun 27 05:48:46 CEST 2012


d control is the way overload is signaled from a SIP server that is reachin=
g overload condition to its upstream neighbors. ...... Implicit overload co=
ntrol uses the absence of responses and packet loss as an indication of ove=
rload. "The Central Weather Bureau of Taiwan has implemented implicit SIP o=
verload control algorithm in their early earthquake warning system with SIP=
=2C as shown by the paper "An Efficient=20
Earthquake Early Warning Message Delivery Algorithm Using an in Time=20
Control-Theoretic Approach" in the following link.
http://www.springerlink.com/content/b6252x2k613rv211/?MUD=3DMP  We have imp=
lemented three different types of implicit SIP overload control algorithms =
using OPNET simulator (http://www.opnet.com/). Our OPNET codes are availabl=
e for non-commerical use or open-source project upon request. Please note t=
hat implicit SIP overload control algorithms only rely on the feekback of "=
200 OK"  messages=2C therefore=2C they do not require any modification on S=
IP header or RFC standardization process.   We have published an exhaustic =
literature survey on explicit and implicit SIP overload control up to the r=
elated publications until March 2011=2C because the submission deadline of =
book chapter was March 2011. The original draft of our book chapter "A Comp=
arative Study of SIP Overload Control Algorithms" is available free of char=
ge for non-commerical use or open-source project upon request.
http://www.igi-global.com/chapter/comparative-study-sip-overload-control/67=
496  If any software engineers want to implement implicit SIP overload cont=
rol in either Kamailio or OpenSIPs=2C I can cooperate with them for softwar=
e implementation. Currently I am a software engineer for cloud web service.
http://www.inbaytech.com/products.html  Best regards=2C Yang=20
 > From: mkaplan at appcomsci.com
> To: sr-users at lists.sip-router.org
> Date: Thu=2C 26 Jul 2012 15:37:40 +0000
> Subject: Re: [SR-Users] Overload Control
>=20
> Thanks=2C this is very much what I was looking for. It appears the rateli=
mit/piplimit modules offer some degree of overload control through queue dr=
ops and invite rejections based on a server's local cpu load. Some of the o=
ther overload control mechanisms described in the RFC (e.g. window based co=
ntrol and loss based control) would also be of interest to me. Not sure if =
public implementations exist or if they are restricted to research implemen=
tations. Thanks for the pointer to ratelimit nevertheless.
>=20
>=20
> -----Original Message-----
> From: sr-users-bounces at lists.sip-router.org [mailto:sr-users-bounces at list=
s.sip-router.org] On Behalf Of Alex Balashov
> Sent: Wednesday=2C July 25=2C 2012 2:39 PM
> To: sr-users at lists.sip-router.org
> Subject: Re: [SR-Users] Overload Control
>=20
> But also=2C check out this module:
>=20
> http://www.kamailio.org/docs/modules/3.3.x/modules/pipelimit.html
>=20
> On 07/25/2012 02:33 PM=2C Kaplan=2C Michael A wrote:
>=20
> > Sure - I'm referring to mechanisms for the server to advertise to upstr=
eam neighbors to reduce request rates. This could include methods that appe=
ar in RFC 6357 (e.g. rate-limits=2C window-based control=2C loss-rate enfor=
cement). I suppose the try-again-after method would be of interest as well.
> >
> >
> > -----Original Message-----
> > From: sr-users-bounces at lists.sip-router.org=20
> > [mailto:sr-users-bounces at lists.sip-router.org] On Behalf Of Alex=20
> > Balashov
> > Sent: Wednesday=2C July 25=2C 2012 2:29 PM
> > To: sr-users at lists.sip-router.org
> > Subject: Re: [SR-Users] Overload Control
> >
> > Can you elaborate as to what you mean by that term=2C "overload control=
"?
> >
> > On 07/25/2012 01:49 PM=2C Kaplan=2C Michael A wrote:
> >
> >> Folks=2C
> >>
> >> I'm trying to figure out if either Kamailio or OpenSIPs provides the=20
> >> various overload control algorithms recommended in the IETF or=20
> >> elsewhere. I haven't found documentation to this effect. Has anyone=20
> >> looked into this or used such techniques?
> >>
> >> Thanks=2C
> >>
> >> Mike
> >>
> >>
> >>
> >> _______________________________________________
> >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing=20
> >> list sr-users at lists.sip-router.org=20
> >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >>
> >
> >
> > --
> > Alex Balashov - Principal
> > Evariste Systems LLC
> > 235 E Ponce de Leon Ave
> > Suite 106
> > Decatur=2C GA 30030
> > Tel: +1-678-954-0670
> > Fax: +1-404-961-1892
> > Web: http://www.evaristesys.com/=2C http://www.alexbalashov.com/
> >
> > _______________________________________________
> > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing=20
> > list sr-users at lists.sip-router.org=20
> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >
> > _______________________________________________
> > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing=20
> > list sr-users at lists.sip-router.org=20
> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
> >
>=20
>=20
> --
> Alex Balashov - Principal
> Evariste Systems LLC
> 235 E Ponce de Leon Ave
> Suite 106
> Decatur=2C GA 30030
> Tel: +1-678-954-0670
> Fax: +1-404-961-1892
> Web: http://www.evaristesys.com/=2C http://www.alexbalashov.com/
>=20
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list s=
r-users at lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/li=
stinfo/sr-users
>=20
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
 		 	   		  =

--_d19812ea-8f74-4fa3-948f-fbce64749633_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Tahoma
}
--></style></head>
<body class=3D'hmmessage'><div dir=3D'ltr'>
Dear all=2C<BR>&nbsp=3B<BR>&nbsp=3B<BR>&gt=3BKaplan=2C Michael A wrote:<br>=
&gt=3B Sure - I'm referring to mechanisms for the server to advertise to up=
stream neighbors to reduce request rates. This could include methods that a=
ppear &gt=3B in RFC 6357 (e.g. rate-limits=2C window-based control=2C loss-=
rate enforcement). I suppose the try-again-after method would be of interes=
t as well.<br>&gt=3B<BR>IETF RFC 6357 "Design Considerations for Session In=
itiation Protocol (SIP) Overload Control"<br>Can be found in the following =
link.<br><a href=3D"http://tools.ietf.org/rfc/rfc6357.txt">http://tools.iet=
f.org/rfc/rfc6357.txt</a><BR>&nbsp=3B<BR>Please note that mechanisms for th=
e server to advertise to upstream neighbors to reduce request rates must mo=
dify SIP header. This is called "Explicit Overload Control Feedback" in RFC=
6357. Unfortunately Changing the SIP header requires a time-consuming stand=
ardization process=2C because all the SIP servers from different service pr=
oviders in different countries have to implement new SIP with new headers.&=
nbsp=3B <BR>&nbsp=3B<BR>&nbsp=3B<BR>&nbsp=3B<BR>&gt=3BKaplan=2C Michael A w=
rote:<br>&gt=3BSome of the other overload control mechanisms described in t=
he RFC (e.g. window based control and loss based control) would also be of =
interest to me. Not sure if public implementations exist or if they are res=
tricted to research implementations. <BR>Yes. "Explicit Overload Control Fe=
edback" proposed by RFC6357 are restricted to research implementations. Pub=
lic implementations require cooperation from all the service providers of S=
IP. However=2C implicit overload control does not require any modification =
of SIP header and time-consuming standardization process. Any SIP server ca=
n implement implicit overload control. <BR>&nbsp=3B<BR>&nbsp=3B<BR>&gt=3BAl=
ex Balashov wrote:<br>&gt=3BYou can always construct such a reply yourself=
=2C and append headers to it.<BR>Yes. But appending headerers requires RFC =
standardization process and cooperation from all the service providers of S=
IP at different countries all over the world.<br><BR>&nbsp=3B<br>From FRC 6=
357=2C "The main difference between explicit and implicit overload control =
is the way overload is signaled from a SIP server that is reaching overload=
 condition to its upstream neighbors. ...... Implicit overload control uses=
 the absence of responses and packet loss as an indication of overload. "<B=
R>The Central Weather Bureau of Taiwan has implemented implicit SIP overloa=
d control algorithm in their early earthquake warning system with SIP=2C as=
 shown by the paper "<a title=3D"Link to Chapter" href=3D"http://www.spring=
erlink.com/content/b6252x2k613rv211/">An Efficient=20
Earthquake Early Warning Message Delivery Algorithm Using an in Time=20
Control-Theoretic Approach</a>" in the following link.<br><a href=3D"http:/=
/www.springerlink.com/content/b6252x2k613rv211/?MUD=3DMP">http://www.spring=
erlink.com/content/b6252x2k613rv211/?MUD=3DMP</a><BR>&nbsp=3B<BR>&nbsp=3B<B=
R>We have implemented three different types of implicit SIP overload contro=
l algorithms using OPNET simulator (<a href=3D"http://www.opnet.com/">http:=
//www.opnet.com/</a>). Our OPNET codes are available for non-commerical use=
 or open-source project upon request. Please note that implicit SIP overloa=
d control algorithms only rely on the feekback of "200 OK"&nbsp=3B messages=
=2C therefore=2C they do not require any modification on SIP header or RFC =
standardization process. <BR>&nbsp=3B<BR>&nbsp=3B<BR>We have published an e=
xhaustic literature survey on explicit and implicit SIP overload control up=
 to the related publications until March 2011=2C because the submission dea=
dline of book chapter was March 2011. The original draft of our book chapte=
r "A Comparative Study of SIP Overload Control Algorithms" is available fre=
e of charge for non-commerical use or open-source project upon request.<br>=
<a href=3D"http://www.igi-global.com/chapter/comparative-study-sip-overload=
-control/67496">http://www.igi-global.com/chapter/comparative-study-sip-ove=
rload-control/67496</a><BR>&nbsp=3B<BR>&nbsp=3B<BR>If any software engineer=
s want to implement implicit SIP overload control in either Kamailio or Ope=
nSIPs=2C I can cooperate with them for software implementation. Currently I=
 am a software engineer for cloud web service.<br><a href=3D"http://www.inb=
aytech.com/products.html">http://www.inbaytech.com/products.html</a><BR>&nb=
sp=3B<BR>&nbsp=3B<BR>Best regards=2C<BR>&nbsp=3B<BR>Yang&nbsp=3B<br>&nbsp=
=3B<BR><div><div id=3D"SkyDrivePlaceholder"></div>&gt=3B From: mkaplan at appc=
omsci.com<br>&gt=3B To: sr-users at lists.sip-router.org<br>&gt=3B Date: Thu=
=2C 26 Jul 2012 15:37:40 +0000<br>&gt=3B Subject: Re: [SR-Users] Overload C=
ontrol<br>&gt=3B <br>&gt=3B Thanks=2C this is very much what I was looking =
for. It appears the ratelimit/piplimit modules offer some degree of overloa=
d control through queue drops and invite rejections based on a server's loc=
al cpu load. Some of the other overload control mechanisms described in the=
 RFC (e.g. window based control and loss based control) would also be of in=
terest to me. Not sure if public implementations exist or if they are restr=
icted to research implementations. Thanks for the pointer to ratelimit neve=
rtheless.<br>&gt=3B <br>&gt=3B <br>&gt=3B -----Original Message-----<br>&gt=
=3B From: sr-users-bounces at lists.sip-router.org [mailto:sr-users-bounces at li=
sts.sip-router.org] On Behalf Of Alex Balashov<br>&gt=3B Sent: Wednesday=2C=
 July 25=2C 2012 2:39 PM<br>&gt=3B To: sr-users at lists.sip-router.org<br>&gt=
=3B Subject: Re: [SR-Users] Overload Control<br>&gt=3B <br>&gt=3B But also=
=2C check out this module:<br>&gt=3B <br>&gt=3B http://www.kamailio.org/doc=
s/modules/3.3.x/modules/pipelimit.html<br>&gt=3B <br>&gt=3B On 07/25/2012 0=
2:33 PM=2C Kaplan=2C Michael A wrote:<br>&gt=3B <br>&gt=3B &gt=3B Sure - I'=
m referring to mechanisms for the server to advertise to upstream neighbors=
 to reduce request rates. This could include methods that appear in RFC 635=
7 (e.g. rate-limits=2C window-based control=2C loss-rate enforcement). I su=
ppose the try-again-after method would be of interest as well.<br>&gt=3B &g=
t=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B -----Original Message-----<br>&gt=3B=
 &gt=3B From: sr-users-bounces at lists.sip-router.org <br>&gt=3B &gt=3B [mail=
to:sr-users-bounces at lists.sip-router.org] On Behalf Of Alex <br>&gt=3B &gt=
=3B Balashov<br>&gt=3B &gt=3B Sent: Wednesday=2C July 25=2C 2012 2:29 PM<br=
>&gt=3B &gt=3B To: sr-users at lists.sip-router.org<br>&gt=3B &gt=3B Subject: =
Re: [SR-Users] Overload Control<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B Can you e=
laborate as to what you mean by that term=2C "overload control"?<br>&gt=3B =
&gt=3B<br>&gt=3B &gt=3B On 07/25/2012 01:49 PM=2C Kaplan=2C Michael A wrote=
:<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B&gt=3B Folks=2C<br>&gt=3B &gt=3B&gt=3B<b=
r>&gt=3B &gt=3B&gt=3B I'm trying to figure out if either Kamailio or OpenSI=
Ps provides the <br>&gt=3B &gt=3B&gt=3B various overload control algorithms=
 recommended in the IETF or <br>&gt=3B &gt=3B&gt=3B elsewhere. I haven't fo=
und documentation to this effect. Has anyone <br>&gt=3B &gt=3B&gt=3B looked=
 into this or used such techniques?<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B=
&gt=3B Thanks=2C<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B Mike<br>&gt=
=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B&gt=3B<br>&gt=3B &g=
t=3B&gt=3B _______________________________________________<br>&gt=3B &gt=3B=
&gt=3B SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing <=
br>&gt=3B &gt=3B&gt=3B list sr-users at lists.sip-router.org <br>&gt=3B &gt=3B=
&gt=3B http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users<br>&gt=
=3B &gt=3B&gt=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B --<br>&=
gt=3B &gt=3B Alex Balashov - Principal<br>&gt=3B &gt=3B Evariste Systems LL=
C<br>&gt=3B &gt=3B 235 E Ponce de Leon Ave<br>&gt=3B &gt=3B Suite 106<br>&g=
t=3B &gt=3B Decatur=2C GA 30030<br>&gt=3B &gt=3B Tel: +1-678-954-0670<br>&g=
t=3B &gt=3B Fax: +1-404-961-1892<br>&gt=3B &gt=3B Web: http://www.evaristes=
ys.com/=2C http://www.alexbalashov.com/<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B _=
______________________________________________<br>&gt=3B &gt=3B SIP Express=
 Router (SER) and Kamailio (OpenSER) - sr-users mailing <br>&gt=3B &gt=3B l=
ist sr-users at lists.sip-router.org <br>&gt=3B &gt=3B http://lists.sip-router=
.org/cgi-bin/mailman/listinfo/sr-users<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B __=
_____________________________________________<br>&gt=3B &gt=3B SIP Express =
Router (SER) and Kamailio (OpenSER) - sr-users mailing <br>&gt=3B &gt=3B li=
st sr-users at lists.sip-router.org <br>&gt=3B &gt=3B http://lists.sip-router.=
org/cgi-bin/mailman/listinfo/sr-users<br>&gt=3B &gt=3B<br>&gt=3B <br>&gt=3B=
 <br>&gt=3B --<br>&gt=3B Alex Balashov - Principal<br>&gt=3B Evariste Syste=
ms LLC<br>&gt=3B 235 E Ponce de Leon Ave<br>&gt=3B Suite 106<br>&gt=3B Deca=
tur=2C GA 30030<br>&gt=3B Tel: +1-678-954-0670<br>&gt=3B Fax: +1-404-961-18=
92<br>&gt=3B Web: http://www.evaristesys.com/=2C http://www.alexbalashov.co=
m/<br>&gt=3B <br>&gt=3B _______________________________________________<br>=
&gt=3B SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing l=
ist sr-users at lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailm=
an/listinfo/sr-users<br>&gt=3B <br>&gt=3B _________________________________=
______________<br>&gt=3B SIP Express Router (SER) and Kamailio (OpenSER) - =
sr-users mailing list<br>&gt=3B sr-users at lists.sip-router.org<br>&gt=3B htt=
p://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users<br></div> 		 	  =
 		  </div></body>
</html>=

--_d19812ea-8f74-4fa3-948f-fbce64749633_--



More information about the sr-users mailing list