Subject: RE: [Sip] Outbound and STUN Keep Alive

From: "Francois Audet" <[email-masked]>
Date: Thu, 16 Feb 2006 17:39:40 -0600

Those numbers are flawed.

Processing a PING request is (if you optimize it properly) a lot
less intensive then processing, say, an INVITE request or any other
normal request.

For one thing, PING is not forwarded anywhere. It is analogous to STUN
if you want to optimize it to the extreme (i.e., you just send a 
200 every time you see it).

There is no DNS resolution, no forking, no complex check for the
message itself since it is not going to impact the far end. 

Furthermore, the vast majority of SIP calls will be much more than
just INVITE/100/200 or whatever your model used for the calculation.
You need to add 180, PRACK/200, the re-INVITE as per STUN, 
pre-condition, also add the re-INVITE/200s or UPDATE/200 that 
occurs as per session-timer (which is dependent on the duration of a
call).

Then there is all the NOTIFYs for various packages flying from
everywhere (config framework, dialog package, regevent, and of 
course, the biggest one, your presence info from all your buddies).

Oh yeah, and IM too...

Then maybe you proxy need to record call traces that include 
everything except PINGs?

Then you need to account for reality... For example, what if the 
originator of the session is, say, not very SIP compliant, and the
proxy needs to spend some time fixing the protocol? I could name
some SIP phones in that category.

A side benefit is that if you are a "smaller" SIP proxy where this 
optimization is not an issue, then you don't have to worry about
it. Same thing for a UAC. Simple to implement.

If you really want to optimize PING, you could use some of the
same techniques talked about earlier for STUN: look for the 
magic cookie (in this case, binary-equivent of ASCII-PING as the first
bytes. You can precompute the answer (inserting the via field). You
really don't have to process PING the same way you process everything
else.

> On Feb 16, 2006, at 12:40 PM, Francois Audet wrote:
> > How big of a fraction of the overall load on "real-life" proxy is 
> > keep-alive is the more important question.
> 
> It's potentially a dominate proportion. An average phone might place  
> less than 5 calls per hour (actually, less than 1 per hour is 
> common)  
> but do 120 keepalive operations per hour, or even 240 if we 
> adopt the  
> 15-second suggestion.
> 
> So, keepalive could represent more than 98% of the transaction load  
> on an edge proxy, in terms of SIP transactions.
> 
> Reducing 98% of the load by 1/3 represents a more than 30% overall  
> performance boost. That may be worth talking about. Reducing it by  
> 90% would be worth celebrating with fireworks and free beer.
> 
> --
> Dean
> 
> 
> 
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Dean Willis <[email-masked]>
Date: Fri, 17 Feb 2006 11:54:28 -0600

> less intensive then processing, say, an INVITE request or any other

The 3-1 number was based on a short-circuited stack that did no  
processing of the MESSAGE request and just responded as quickly as  
possible.

Now, maybe it could be optimized a little bit more, but I suspect not  
much.

--
Dean