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

From: "Samir Srivastava" <[email-masked]>
Date: Wed, 15 Mar 2006 00:18:29 -0600

We cannot differentiate whether OPTIONS is for keep alive or for other
purpose without parsing it 
completely. It might have Require and Proxy Require too. That was the
sole purpose of dedicated new message.

How gaming protocols use STUN i.e. muxing, keep alives ? We might have
Gaming Application and SIP
UA on the same physical Device.

Thx
Samir

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]] 
Sent: Tuesday, March 14, 2006 7:22 PM
To: Christer Holmberg (JO/LMF); Hisham Khartabil; [email-masked]
Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN
requestprocessingfaster than a SIP PING request processing?

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

On 3/14/06 4:48 AM, "Christer Holmberg (JO/LMF)"
<[email-masked]> wrote:

> 
> 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

_______________________________________________
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: Thu, 16 Mar 2006 11:04:52 -0800

If you are going to make the new message so that it is not part of SIP, ie
things like Proxy-Require are not used, then it is basically a new protocol
and it sounds very similar to just doing some other new protocol over the
same transport as the SIP stuff.