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

From: "Francois Audet" <[email-masked]>
Date: Wed, 15 Feb 2006 19:22:34 -0600

Exactly my view.

I really don't see why processing a PING method would be any more
resource-intensive because of "parsing" or whatever than processing
a STUN message (binary) that happens to run on the same port
the rest of the SIP protocol runs on.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hisham Khartabil
> Sent: Wednesday, February 15, 2006 05:16
> To: Cullen Jennings
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Sip] Outbound and STUN Keep Alive
> 
> 
> This is all theory and guesstimates. We'll try to prototype these 
> things and get back to the list with hard numbers to prove or 
> disprove 
> the 2 theories. If anyone willing to co-operate on this, 
> please contact 
> me.
> 
> Regards,
> Hisham

_______________________________________________
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: Wed, 15 Feb 2006 20:19:42 -0600

> the rest of the SIP protocol runs on.

Well, I'm sure there's at least SOME difference. How much remains to  
be determined.

I have a preliminary report from one of the performance people who's  
working with Jonathan. He did some saturation testing comparing the  
STUN operation to receiving, discarding, and 200oking a short MESSAGE  
request (roughly analogous to how PING processing would work if it  
were heavily optimized).

These initial results show at least a 3x difference, much of which is  
attributable to the parsing overhead. Once the MESSAGE request is  
liberated from its framing, it still has to be parsed enough to  
recognize it as a discardable message and figure out where to send  
the 200 OK response (which requires parsing Via header fields). Then  
the 200 OK response has to be constructed, which is pretty  
straightforward but still requires several times more string  
operations than the STUN response does. This testing was done on a  
very mature Java stack implementation, the SIP part of which has been  
highly optimized.

Now I'll also have to say I don't completely trust these results --  
they're preliminary, I have doubts about the STUN optimization, and I  
think we were hitting interface saturation on a 100 M ethernet. My  
gut feel is that the gap will widen above 3x as the testing (and  
implementation) gets better.

Is 3x significant? I suppose that depends on your business model and  
per-box overhead. It also changes the inflection points at which one  
has to go from single or paired-box models to high-availability  
clustering approaches with state replication, and THAT is a  
significant delta, if you;re not already past it.

--
Dean