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

From: "Michael Procter" <[email-masked]>
Date: Mon, 6 Mar 2006 16:18:51 -0000

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

Regards,

Michael Procter

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Mon, 06 Mar 2006 13:59:07 -0500

inline.

Michael Procter wrote:

> 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
> therefore purely an implementation issue, not a protocol

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

---

From: "Frank W. Miller" <[email-masked]>
Date: Mon, 06 Mar 2006 20:37:34 -0500

> SIP, and there are no retransmits. So, there is a timeout. We'll have a 

The dropping of retransmits was just added to the draft.  The reason was
that the duration that can occur between retransmissions in a NIT can be
longer than what people were interested in for the NAT refresh interval,
which was 15 seconds IIRC.

You're point about stateful proxies is an interesting one.  I'd also be
interested in hearing about any experiences with implementations that do
this and what kind of performance impacts have been observed on these
stateful proxies.  What I mean is, lets assume we have a stateful proxy
that gets into a situation where its got alot of outstanding
transactions that its tracking for some reason.  What kind of
performance hits are seen at that node, are there any?  If the condition
that caused the backup to occur clears, how long does the transient
survive at the proxy?

If we believe that dropping the retransmission behavior will seriously
impact compatibility with 3261, we can of course change it back so the
PING is retransmitted the same as any other request.

Another possibility is to use NIT retransmissions but to simply modify
the backoff so it never exceed 15 seconds.  Such a compromise will
likely cause fewer problems with intervening proxies and would meet the
desire to have some outbound traffic every 15 seconds.

The issue with this of course is that it bumps up the potential load on
intervening servers during times when you want it to be bumped up the
least.

WRT to authentication, I believe it just doesn't make any sense to
challenge a PING.  It should be a short lived transient transaction that
may or may not have anything to do with a session.  If the PING is
challenged, e.g. by an older implementation, the UAC should just give up
and accept the 401 or 407 as the response.  As far as blacklisting, I'm
not sure what that means?  Do you mean that the proxy is going to start
dropping the PINGs on the floor rather than sending back some kind of
response?  Or do you mean that the Service Provider will cut off the
network access or something?

As far as STUN is concerned, IMHO, and its just MHO, multiplexing STUN
and SIP is a much worse idea than trying to do something within the SIP
protocol framework.  I've already said that I believe STUN is a NAT
discovery protocol only and that other functions should be done
somewhere else.  We just differ on that point.  However, its clear that
NAT discovery is at least one function of STUN and that NAT discovery is
and will be required by other Internet protocols.  For this reason
alone, multiplexing it with SIP is too SIP-centric and does not make
sense because any other protocol that needs STUN will bang into this
architectural decision.

FM

---

From: Dean Willis <[email-masked]>
Date: Mon, 6 Mar 2006 19:55:13 -0600

> network access or something?

Go to the bank. Insert your ATM card. Enter your PIN wrong a few times.

You've been blacklisted. And you no longer have an ATM card, in most  
instances. Also, your picture has been taken and sent to Security,  
and they'll be calling you.

Systems using this sort of defense will assume that the sending node  
is an attacker, and either actuate alarms or defensively start  
dropping requests from that node, or both. This leads to some  
interesting DOS opportunities, of course. Especially with UDP.

--
Dean