Subject: RE: [Sip] Myth Busters: Episode 1, Is STUN request processingfaster than a SIP PING request processing?

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 14 Mar 2006 13:48:16 +0100

Hi,

Without commenting on the "speed" issue, IF we want to use a SIP based
solution I would prefear a dedicated one, instead of re-using OPTIONS.

Like I said earlier, IF the edge proxy "understands" the mechanism, and
IF it knows the request does not need to be forwarded, it can choose to
terminate it. Yes, it's b2bua behaviour, but still. I do not want a
solution that forces me to overload the rest of the network with the
keep-alive requests - no matter what mechanism is used - and therefor
OPTIONS is not a good solution, because since OPTIONS would also be used
for non-keep-alive purposes it would always have to be forwarded.

Another solution, as I mentioned earlier, would be that the keep-alives
are addressed to the edge proxy (or whatever entity on the other side of
the NAT). Then it would be "normal SIP", without any b2bua behavior.

Regards,

Christer

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]] 
Sent: 12. maaliskuuta 2006 22:09
To: Hisham Khartabil; [email-masked]
Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN request
processingfaster than a SIP PING request processing?

You results don't look right to me. I can't really test very well on my
notebook computer but with STUN on a apple powerbook I am getting 16,000
TPS at about 30% CPU. Who knows what I could get with an intel processor
:-) Your results look like 6 to 10k TPS. When people quote ms I never
have any clue if they are including the kernel time, it it is a latency
or what. The number we need here is aggregate throughput, not latency so
actual transactions per second on some suitable box might be the easies
to compare.
Similarly, the rates of OPTIONS also looked fairly slow so perhaps I
just don't get what you are measuring.

Ignoring that, when I look at the code, I can't see any particular
reason that the speed of PING would not be roughly the same as STUN. The
problem is this violates RFC 3261 in so many ways that you can barely
make a list of them all. Once you do the processing to make this
consistent with existing things, the performance will drop significantly
- my guess is that it would drop to roughly the same rate as OPTION.

On 3/6/06 10:02 AM, "Hisham Khartabil" <[email-masked]>
wrote:

> I promised to come back with hard real numbers on how long it will 
> take for a server to process and STUN request vs a SIP PING request
> 
> Myth: processing a STUN request is 10 to 100 times faster than a SIP 
> PING request
> 
> Assumptions:  - SIP PING request is processed early in the stack and 
> bypasses any unnecessary validations.
>                - SIP PING response carries in the contact header the 
> IP address and port as appears in the IP packet (source IP and port).
> 
> We implemented the PING request as described above in the reSIProcate 
> stack. Attached you will find the c++ file where the changes were
made.
> STUN was already implemented in the reSIProcate stack and used as is.
> 
> Below you will see the findings:
> 
> STUN request processing: 0.15 - 0.2 ms SIP PING request processing: 
> 0.1 - 0.2 ms SIP OPTIONS request: 7 ms SIP REGISTER request: 7 ms
> 
> The measurement was taken between the time a request appeared on 
> ethereal and its response appearing on ethereal. Average was taken 
> manually.
> 
> As you can see, SIP PING requests were sometimes faster to process 
> that STUN requests, but never slower. Actually the SIP PING requests 
> on average were faster to process.
> 
> Myth Busted!!!! :)
> 
> Regards,
> Hisham
> P.S. It took 15 mins to modify the sip stack to do the PING response.
> 
> _______________________________________________
> 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

_______________________________________________
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

_______________________________________________
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: Cullen Jennings <[email-masked]>
Date: Tue, 14 Mar 2006 19:22:23 -0800

Options would not be forwarded if it was sent to the edge proxy.