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

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 17 Mar 2006 02:59:02 -0600

STUN with magic binary cookie is hack too. That looks to me going back
to binary protocols and defeating the purpose of text based SIP
protocol. Another point  "Every application protocol 
should take of its own mess using its own primitives" . Within SIP too
all headers doesn't 
apply to all methods, we are doing this to achive the performance. So
PING is lesser evil than
STUN.

Thx
Samir

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]] 
Sent: Thursday, March 16, 2006 11:05 AM
To: Srivastava, Samir [SC100:8826:EXCH]; Christer Holmberg (JO/LMF);
Hisham Khartabil; [email-masked]
Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN
requestprocessingfaster than a SIP PING request processing?

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.

On 3/14/06 10:18 PM, "Samir Srivastava" <[email-masked]> wrote:

> 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: "Christian Jansson" <[email-masked]>
Date: Fri, 17 Mar 2006 10:49:16 +0100

> Samir wrote:
>STUN with magic binary cookie is hack too.That looks to me going back
>protocol. 

So in principal you rather have something that is human readable than
something that works better in reality?

>Another point  "Every application protocol
>should take of its own mess using its own primitives" .

You mean we should for example also use SIP instead of DNS, DHCP, and
RTP? In general I think it is better to use a tool that is designed for
the problem.

>Within SIP too all headers doesn't
>apply to all methods, we are doing this to achive the performance.

SIP parsing and performance are not optimized, that is a fact. SIP and
human readability on the other hand... but who cares.

>So PING is lesser evil than STUN.

If PING was SIP I would have no problem with it, but as it is defined
right now PING is not SIP even though the draft wants it to be. And I do
not think we should standardize things that are plain wrong just because
it for the moment does not seem to introduce any enormous problems.

I think we have 3 real options:
1. Double CRLF
2. A new real SIP method
3. STUN

Bad ideas:
4. Using OPTIONS is a bad idea as it has another purpose, and adding new
method would cost us nothing and it would be very clear what was going
on.
5. Using PING as it is being discussed right now is not an option as
long as it is not SIP as it claims to be. I do not want to see any more
discussions of non-SIP things that just looks like SIP anymore.

/ Christian Jansson

---

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 17 Mar 2006 14:24:20 -0600

Inline below.

Thx
Samir

-----Original Message-----
From: Christian Jansson [mailto:[email-masked]] 
Sent: Friday, March 17, 2006 1:49 AM
To: Srivastava, Samir [SC100:8826:EXCH]; Cullen Jennings; Christer
Holmberg (JO/LMF); Hisham Khartabil; [email-masked]
Subject: RE: [Sip] Myth Busters: Episode 1,Is STUN
requestprocessingfaster than a SIP PING request processing?

SS>> If you want something works better i.e. real high performance.
Invent something similar to 
     H.323 with SIP features and have fun.  Why we have all XML
extensions for presence and SAML 
     etc, use ASN.1 ? SIP is ASCII based protocol.  So we better stick
to that. We wanted to find
     a solution within SIP boundaries. More below.

>Another point  "Every application protocol should take of its own mess 
>using its own primitives" .

SS>> I think I wasn't explaintary enough on this. Every protocol plays
its own role for which 
     they are designed. You streteched too far to include DNS, DHCP
etc... My position was "SIP
     port NAT  binding should be refreshed by SIP. There may be other
STUN clients too. If they
     also see the same problem what we are going to do."  That was the
reason for my related 
     question earlier for online gaming. How on line gaming protocols
use STUN and what they do 
     for muxing and keep alive. This will give us real life experience
of the same problem faced
     by another application protocol. We might have SIP UA and Gaming
Application running 
     simulatenously on the same physical device. Whether there will be
always multiple STUN 
     clients sitting on different ports, or we will be doing muxing
there too ? Any guidelines ?

     Any gaming protocol expert on the list to share the experience ?
     
     With SIP PING method, we can easily find out the traffic stats from
SIP MIB for overload and
     congestion. How we will find stats of STUN Keep alive load in a
out-of-band manner ?

SS>> You can create a tool to do binary to ASCII (or whatever
interpretation you want ) conversion.
     Earlier you were asking for performance, here you don't care. 

     Can somebody present me an application for Require and
Proxy-Require for PING which cannot be
     done with existing OPTIONS. If you need to find capabilities etc,
use existing OPTIONS with 
     Require and Proxy-Require. Purpose of PING is to do heart beat
only. I will reiterate in the
     purist sense it might looks like SIP, but it is better than pure
binary cookie and leave the
     floor for community to decide.

Bad ideas:
4. Using OPTIONS is a bad idea as it has another purpose, and adding new
method would cost us nothing and it would be very clear what was going
on.
5. Using PING as it is being discussed right now is not an option as
long as it is not SIP as it claims to be. 

I do not want to see any more discussions of non-SIP things that just
looks like SIP anymore.
SS>> You are too quick in stopping the discussion while discussing the
merits / demerits .

/ Christian Jansson