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

From: "Francois Audet" <[email-masked]>
Date: Tue, 7 Mar 2006 19:38:54 -0600

The point is not really backward compatibility. The point is that I can 
choose to implement this using NORMAL SIP.

What it allows me to do, if I am not concerned about optimizing the PING
processing as Hisham's, is to implement this on a SIP PING server (which
may or may not be the edge proxy). I can just treat it as a new
method with processing that happens to be quite simple (i.e., I can 200
it). 

If I am an "Enterprise" SIP vendor, and I'm doing a simple SIP product,
I can
implement this in no time. Since the scale is small, there is no reason
to
"optimize" the PING method processing. Not every SIP implementation in
the
world is going to be a massive SIP service provider. Lot's of people out
there
will have smaller scale offering.

If on the other hand, I am doing a large scale SIP offering, and I need
to
keep the keep-alive very liteweight, then I can do exactly what Hisham
has 
demonstrated. 

I will note that we have also implemented the same idea in real
live large-scale systems and have found that PING processing to be
minimal. I'm glad to see that Hisham proved the same thing.

On the client side, there is also an advantage that it is trivial to
implement.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Monday, March 06, 2006 10:59
> To: Michael Procter
> Cc: [email-masked]; Bharrat, Shaun; Alan Duric; Dusan Stevanovic
> Subject: Re: [Sip] Myth Busters: Episode 1, Is STUN request 
> processing fasterthan a SIP PING requestprocessing?
> 
> 
> inline.
> 
> Michael Procter wrote:
> 
> > Bharrat, Shaun wrote:
> > 
> >>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?
> > 
> > [...]
> > 
> >>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.
> > 
> > 
> > I think the point is that the message has sufficient SIP 
> headers that 
> > it can be parsed and rejected (501) by a stack that doesn't support 
> > the extension.  A rejection is an acceptable response to the PING 
> > request,
> > 
> > So, the PING request is in some sense backwards-compatible with 
> > existing code.
> 
> Thats my beef with this whole thing. That its "in some sense" 
> backwards 
> compatible, but not really.
> 
> You are taking something that LOOKS like SIP, but is 
> fundamentally NOT 
> SIP, and sending to a server in the hopes that the right 
> thing happens. 
> However, in the real world, odd things will always happen. 
> Let me give 
> some examples.
> 
> UAC sends the PING request to its proxy. Proxy doesnt support 
> the method 
> but forwards it on to another proxy, ignorning max-forwards (some 
> elements do this, as they serve as 'fronts' to the real 
> proxy). Packet 
> is lost. Well, you've changed the retransmit rules for PING 
> from normal 
> SIP, and there are no retransmits. So, there is a timeout. 
> We'll have a 
> nice race condition, first of all, since the outbound proxy, having 
> thought this was normal SIP, will generate a 408 at some point, but 
> probably after the UAC gives up. Depends on how you define 
> your new PING 
> protocol transaction timers relative to real sip. Assuming 
> though that 
> the UAC times out first, the UAC will think that its proxy is 
> down, but 
> its not. Seems really bad to me.
> 
> Here's another funny case. PING goes to a proxy, which doesn't know 
> about PING, but wants to authenticate the request. So, it 
> responds with 
> a 401 and challenges the request. Well, you might say it 
> worked fine - 
> nat binding kept alive. However, many proxies will set off 
> alarms with 
> their intrusion detection systems on repeated 401 messages 
> from the same 
> source IP, so your client may find itself banned from the 
> network pretty 
> quickly.
> 
> Both of these problems can be fixed by putting Proxy-Require 
> and Require 
> in. However, that defeats the whole point of this mechanism, to be 
> "backwards compatible" with existing SIP. So, if you do that, may as 
> well use STUN.
> 
> So, to be clear, I think that this whole idea of something that looks 
> like SIP, but isn't, in the supposed hopes of being "backwards 
> compatible" with existing equipment, is a big, big mistake, and will 
> result in all kinds of unpredicable and really hard to debug 
> problems in 
> the real world.
> 
> 
> 
>   Of course, newer implementations may choose to
> > optimise the processing for it, so that they can get 
> performance that 
> > is equivalent to STUN, but there is no need to do so for 
> the feature 
> > to work.  Implementing the fast-path processing is 
> therefore purely an 
> > implementation issue, not a protocol compliance issue.
> 
> Wrong, as I have pointed out. As soon as you make a change 
> that alters 
> MUST-strength processing in clients (as the PING method has), 
> you have 
> introduced interoperability problems.
> 
> -Jonathan R.
> 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Cisco Fellow                                   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> [email-masked]                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com
> 
> _______________________________________________
> 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