Subject: [p2p-sip] [Sip] Myth Busters: Episode 1, Is STUN request processing faster than a SIP PING requestprocessing? (P2PSIP possibilities)

From: slavitch at objectworld.com (Michael Slavitch)
Date: Mon, 6 Mar 2006 12:48:27 -0500

Hisham;

Love the code and the numbers. We'll try our luck here and compare. This
is the first time in a long time that our engineers and our testers were
equally happy (and not grumpy) after I forwarded them an email from an
IETF WG list.  

I hope that this is the start of a trend. It allows us to ask and answer
firm questions with real data in real implementations.

On another note, if 'it was not really part of SIP', but part of a 'P2P
Overlay mechanism' a lot of difficult things would begin to go away,
especially if part of the capability of P2PSIP offered a client adaptor
service for low-function SIP user agents or proxies. For that reason I'm
forwarding this email to the p2psip list, as people there will have an
interest in this discussion and especially the sample code and the test
results.

http://mice.cs.columbia.edu/getTechreport.php?techreportID=388  has an
interesting description of client adaptors in a peer to peer
environment, something that would offer great benefit if implemented in
P2PSIP.

Regards

Michael

Michael Slavitch           Lead, Strategic Initiatives 
slavitch at objectworld.com   Objectworld Communications Corp. 
+1.613.599.9698 .225       Ottawa, Ontario, Canada

-----Original Message-----
From: Bharrat, Shaun [mailto:SBharrat at sonusnet.com] 
Sent: March 6, 2006 10:35 AM
To: Hisham Khartabil; sip at ietf.org
Cc: Alan Duric; Dusan Stevanovic
Subject: RE: [Sip] Myth Busters: Episode 1,Is STUN request processing
faster than a SIP PING requestprocessing?

Hisham:

Glad to see actual code and test results. It is a _welcome_ sight to
have full information and numbers based on real code.

Now that I understand what is actually being done, I guess my question
is why you would have expected the numbers to be any different? Please
correct me if I am misunderstanding anything in what you have done. This
is not doing ANY sip processing - it just finds the first \r\n and then
copies everything beyond that (with a 200 + contact header prepended)
into the response. There is no VIA processing (guess we don't need to
add received= or rport?), no Content-Length processing (how does it work
for TCP?), etc.

If we are "allowed" to skip the SIP processing (i.e. it's not really a
SIP packet), then I agree that we can make the processing time of a PING
arbitrarily close to a STUN packet processing. However, if we are not, I
don't agree that this is a valid comparison of a SIP-based keepalive
versus a STUN based keepalive.

My 2c

Thanks and cheers,
Shaun

www.sonusnet.com

> -----Original Message-----
> From: Hisham Khartabil [mailto:hisham.khartabil at telio.no]
> Sent: Monday, March 06, 2006 10:02 AM
> To: sip at ietf.org List
> Cc: Alan Duric; Dusan Stevanovic
> Subject: [Sip] Myth Busters: Episode 1,Is STUN request processing 
> faster than a SIP PING requestprocessing?
> 
> 
> 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
sip-implementors at cs.columbia.edu for questions on current sip Use
sipping at ietf.org for new developments on the application of sip

--

-----------------------------------------------

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. 

Any views, opinions and content presented in this e-mail are solely those of the author and may not represent those of Objectworld Communications Corp.