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

From: Hisham Khartabil <[email-masked]>
Date: Mon, 6 Mar 2006 16:02:15 +0100

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

---

From: Dean Willis <[email-masked]>
Date: Mon, 6 Mar 2006 17:58:34 -0600

On Mar 6, 2006, at 9:02 AM, Hisham Khartabil 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

Time alone is probably an insufficient determinant of performance in  
this case. I'm far more interested in how the alternatives affect the  
throughput, at saturation, of the node involved. As a secondary  
matter, I'm interested in how the methods affect the recovery of an  
overloaded node.

--
Dean

---

From: "Brett Tate" <[email-masked]>
Date: Mon, 6 Mar 2006 20:49:50 -0500

> Time alone is probably an insufficient determinant of 
> performance in this case. I'm far more interested in 
> how the alternatives affect the throughput, at saturation, 
> of the node involved. 

Thus far assuming it meets the requirements, I haven't heard of anything
that would beat the "double CRLF" mechanism in this category for connection
oriented transports.

> As a secondary matter, I'm interested in how the methods 
> affect the recovery of an overloaded node.

I'm not aware of much distinction among the proposals.

The SIP 503 response works ok.  And after
draft-rosenberg-sipping-overload-reqs is resolved; hopefully the 503
response (or alternate solution) will work better.

The "double CRLF" and STUN mechanisms would likely cause less overload.  And
if an overload causes the connection/binding to be suspect, the subsequent
SIP request could trigger a 503 when needed.

And depending upon how the mechanism is tied to the rest of the SIP
messaging over the connection, potentially nothing extra really needs to be
sent over the connection/binding as long as something is being sent and
received frequent enough.

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 12 Mar 2006 12:08:43 -0800

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.