Subject: [Sip] Outbound and STUN Keep Alive

From: Cullen Jennings <[email-masked]>
Date: Sun, 12 Feb 2006 15:34:31 -0800

There has been a few threads about keep alives in outbound.... I will start
a thread here.

For UDP, I think STUN is clearly the best choice. It's the only thing that
is quick and works when the NAT reboots.

For TCP, there is the the option to use STUN the same as UDP.

There might be another solution for TCP. I'll call it the Double CRLF.
Basically the UA sends a CRLF, when the proxy receives this, it must sends a
CRLF within 1 second.  If the UA does not get back the CRLF within 6 seconds
of sending the first one, it considers the connection dead.

First questions is, does Double CRLF work?

Second questions is, given we have to do STUN for UDP, would we want to do
something different for TCP?

_______________________________________________
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: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 13 Feb 2006 09:35:58 -0600

Cullen Jennings wrote:
> There has been a few threads about keep alives in outbound.... I will
> start a thread here.
> 
> For UDP, I think STUN is clearly the best choice. It's the only thing
> that is quick and works when the NAT reboots.
> 
> There might be another solution for TCP. I'll call it the Double
> CRLF. Basically the UA sends a CRLF, when the proxy receives this, it
> must sends a CRLF within 1 second.  If the UA does not get back the
> CRLF within 6 seconds of sending the first one, it considers the
> connection dead.
> 

Cullen: The purpose of the CRLF is to keep the NAT binding alive by
having the NAT periodically see traffic traversing through it, yes?
If so, the binding is kept alive by the CRLF going from the UA->Proxy.
I am not sure what the CRLF from Proxy->UA accomplishes.  Furthermore,
existing proxies may ignore incoming CRLF, but they certainly do not
generate one in the upstream direction when they get a CRLF...

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
_______________________________________________
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, 13 Feb 2006 11:11:37 -0500

I do think the double CRLF will work.

However, the transaction ID in stun makes it easier to correlate 
requests and responses. After all, whether you choose to call it that or 
not, the double CR/LF is a transaction, and you are setting times on 
transaction timeouts here. Thats all easier with a proper transaction.

The double CRLF lacks the MAPPED-ADDRESS from stun, which is needed for 
UDP only. It is needed there to detect nat reboots. If a nat reboots, 
tcp data transmissions (i.e, the STUN keepalives or CRLF) will be 
discarded since there is no matching context. But, for UDP, they create 
a new binding and are passed through. The MAPPED-ADDRESs is needed in 
UDP to detect this case.

That said, there is no benefit to the double CRLF over STUN. Its not 
backwards compatible in that the server still has to know how to do it. 
I think having one solution is easier than two.

-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: Hisham Khartabil <[email-masked]>
Date: Mon, 13 Feb 2006 18:01:41 +0100

The advantages of using STUN for this is that it works for all 
application layer protocols that need a keepalive mechanism for NAT 
bindings (thats why I suggested privately to Cullen to move this part 
of the I-D into a separate draft and submit it in BEHAVE).

If we want a SIP specific solution, then I would suggest (well, not 
entirely my idea. It has been suggested before) a new SIP method that 
achieves what STUN achieves for those NATs that reboot. Something like

NATKEEPALIVE

The contact in the 200 OK returns the new external port (and IP 
address) assigned. The only advantage to this is that we do not use the 
same port for both SIP and STUN and we avoid having to extend parsers 
to support that and create a link between SIP parsers and STUN parsers.

Regards,
Hisham

On Feb 13, 2006, at 12:34 AM, Cullen Jennings wrote:

> start

---

From: "Sean Olson" <[email-masked]>
Date: Mon, 13 Feb 2006 09:06:51 -0800

[Sean] Yes, quite well

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 13 Feb 2006 16:12:11 -0500

The problem is, once you say its a SIP method, you nede to do ALL of the 
processing associated with any SIP transaction - the parsing, state 
machinery, authentication, proxy-require checks, max-forward checks, and 
so on. Given the frequency with which this message comes, you really, 
really, really want to optimize this.

-Jonathan R.

Hisham Khartabil wrote:

> bindings (thats why I suggested privately to Cullen to move this part of 
> the I-D into a separate draft and submit it in BEHAVE).
> 
> The contact in the 200 OK returns the new external port (and IP address) 
> assigned. The only advantage to this is that we do not use the same port 
> for both SIP and STUN and we avoid having to extend parsers to support 
> that and create a link between SIP parsers and STUN parsers.
> 
> Regards,
> Hisham
>

---

From: "Frank W. Miller" <[email-masked]>
Date: Mon, 13 Feb 2006 18:25:25 -0500

Actually, I would make the opposite argument.  Given the frequency with
which you are going to do this, you basically don't care how much
overhead there is associated with it.

If its treated like just another end-to-end NIT, most implementations
will have a very simple time adding it.  All the machinery to do it is
already there.

Double CRLF sounds like a hack to me.  We all know there are long
periods of time in which signaling traffic might not be flowing.  We
also know that there is at least one very good reason to have periodic
signaling traffic occur.  I would propose that we just add a PING
message to handle that.  Maybe I'll even throw together a strawman
proposal for it, it should be fairly trivial to do.

FM

---

From: Dean Willis <[email-masked]>
Date: Mon, 13 Feb 2006 19:31:12 -0600

> First questions is, does Double CRLF work?

Sortof, maybe. Lacking a transaction code or sequence number,  It  
doesn't tell the UA whether the response being seen is for the most  
recent probe, an older probe, a duplicate response to an older probe,  
or just a completely unrelated CRLF being sent because the server is  
having hiccups.

And you have to mod the "server" to echo CRLF, which it would  
currently silently discard.

Retrofitting onto older SIP stacks would be hard, because the APIs  
don't let you send null strings, nor do the inform the app when such  
are received.

> something different for TCP?

Well, there's still the question of reliably demuxing STUN from SIP  
over TCP, and the question of API refitting. Both can be solved.

Is there enough here to suggest that a very-lightweight SIP  
transaction (like OPTIONS with less overhead) would have benefits  
over STUN in the keepalive capacity? It might be easier to implement  
on old stacks, but I can't imagine it would scale as well for large  
installations.

A SIP transaction would provide the option of forcing a re- 
authentication on keepalive, which might be of interest to some people.

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 13 Feb 2006 16:39:52 -0800

I'm think that double CRLF or STUN will work better than a new SIP method.
The problem is performance. I think the STUN requests will be 10 to 100
times faster than a SIP method. Given the frequency of these we are talking
about, using a SIP method would require deployments to have way more edge
proxies.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 13 Feb 2006 16:42:28 -0800

On 2/13/06 7:35 AM, "Vijay K. Gurbani" <[email-masked]> wrote:

> I am not sure what the CRLF from Proxy->UA accomplishes.
The point of the CRLF from Proxy to UA was only to allow the UA to know that
it's connection to the Proxy was lost and that incoming phone calls would
not work unless it when and registered again.

> Furthermore,

Yes - agree - all of these require changes on both UA and Proxy side.

---

From: "Frank W. Miller" <[email-masked]>
Date: Mon, 13 Feb 2006 21:06:19 -0500

I took the liberty of putting together a new draft that proposes the
PING method.  The draft is at http://www.cornfed.com/ping.txt.  Comments
welcome!

FM

---

From: [email-masked]
Date: Tue, 14 Feb 2006 10:42:44 +0530

will OPTIONS method not work for the same? Instead of sending an CRLF we can also send an OPTIONS method to refresh the NAT binding. If i am not wrong then OPTIONS method was discared because of the processing of the SIP message for keeeping the NAT binding alive. Hence, CRLF was considered. But CRLF is not backward compatible i.e. it does not provide MAPPED ADDRESS. Now bringing in the PING method would again be introducing a SIP message based processing which would lead to poor performance.

Regards,

--Vikram

"Frank W. Miller" <[email-masked]>

"Frank W. Miller" <[email-masked]>

Sent by: [email-masked]

02/14/2006 04:55 AM

Please respond to

[email-masked]

To

Jonathan Rosenberg <[email-masked]>

cc

Cullen Jennings <[email-masked]>, "[email-masked]" <[email-masked]>

Subject

Re: [Sip] Outbound and STUN Keep Alive

already there.

FM

> >> that

> >> Basically the UA sends a CRLF, when the proxy receives this, it must

> >> sends a

> >> CRLF within 1 second.  If the UA does not get back the CRLF within 6

> >> seconds

> >> Second questions is, given we have to do STUN for UDP, would we want

> >> to do

*********************** FSS-Unclassified ***********************

---

From: Dean Willis <[email-masked]>
Date: Tue, 14 Feb 2006 01:10:32 -0600

[email-masked] wrote:
> will OPTIONS method not work for the same? Instead of sending an CRLF we 
> can also send an OPTIONS method to refresh the NAT binding. If i am not 
> wrong then OPTIONS method was discared because of the processing of the 
> SIP message for keeeping the NAT binding alive. Hence, CRLF was 
> considered. But CRLF is not backward compatible i.e. it does not provide 
> MAPPED ADDRESS. Now bringing in the PING method would again be 
> introducing a SIP message based processing which would lead to poor 
> performance.

We've demonstrated successfully slaying proxies by bombing them with 
OPTIONS requests.

Back in the "early days" of dynamicsoft, our first proxies were 
processing 7 INVITE/200/ACK/BYE/200 non-authenticated transaction 
sequences or about 20 OPTIONS transactions per second. They've of course 
gotten much faster, but the proportions have stayed pretty much the same.

So you can see that in models where a typical SIP transaction load might 
be 5 transactions per hour per node, adding another 60 OPTIONS 
transactions per hour per node might reduce your edge-proxy scalability 
by on the order of 13-1, or roughly a 93% performance hit. That's a big hit.

Cullen thinks that stun transactions have substantially less impact on 
the proxy. I haven't seen real-world benchmarks comparing a proxy doing 
"normal" SIP to a proxy demuxing SIP and STUN and interleaving requests 
one  a 1-12 interleave. If anybody has done this and has numbers, I'd be 
thrilled to see them.

I'm guessing a stripped down SIP "PING" might take 1/2 the CPU of an 
OPTIONS, at the very best. That would still give us something like an 
80% performance penalty.

If Cullen is right and the STUN work takes 1/10th of OPTIONS (or less), 
then we'd clearly have an advantage in favor of STUN. Using my numbers 
above, that would be just over a 50% performance hit on the proxy versus 
not doing keepalives, which I think is tolerable given the benefits of 
keepalive.

--
Dean

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 14 Feb 2006 08:36:35 -0600

Cullen Jennings wrote:
>>  having the NAT periodically see traffic traversing through it,
>> yes? If so, the binding is kept alive by the CRLF going from the
>> UA->Proxy. I am not sure what the CRLF from Proxy->UA accomplishes.
>> 
> 
> The point of the CRLF from Proxy to UA was only to allow the UA to
> know that it's connection to the Proxy was lost and that incoming
> phone calls would not work unless it when and registered again.

OK; so we are essentially doing two things with the double CRLF:
keep the NAT bindings alive and implement some sort of heartbeat
mechanism.

- vijay

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 14 Feb 2006 07:21:37 -0800

I think that Dean brings up some very good points below - it's not clear
that double CRLF will work. It could very well detect the connection was
"live" when really it just had some old CRLF junk that got backlogged.

Unless someone has a compelling argument that double CRLF will work, I don't
think I am going to bother to write it up.

Cullen

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 14 Feb 2006 07:29:14 -0800

Just to be clear on how often we are doing this ... At the last IETF folks
said we needed to do the ping every 15 seconds. So for a relatively small
deployment with 2 million users, we are looking at like 130 thousand
transactions per second. This is achievable with one or two STUN servers but
is going to take a rack full of proxies to do it with full SIP requests.

---

From: "Frank W. Miller" <[email-masked]>
Date: Tue, 14 Feb 2006 11:24:04 -0500

> is going to take a rack full of proxies to do it with full SIP requests.

I've not heard these numbers and they are interesting.  However, lets
assume that a "rack full of proxies" is 8-10 4U servers.  Your at
approximately 4x-5x the hardware cost.  If we're talking Sparc or PC
servers of reasonable quality, we're probably talking an additional
$10K, maybe $15K, of server hardware which in a 2 million user
deployment is very likely in the noise.

The other option of course is to spend some time optimizing your
implementation.  For example, it seems reasonable to put in a fast path
for OPTIONS and/or PING parsing and turnaround.

My point here is, double CRLF and port sharing are expedient solutions.
The "right thing to do" is to have the protocol that is having the
problem solve the problem.  IMHO, STUN is for NAT discovery, the
protocols that traverse the NAT should be responsible for dealing with
the NAT traversal.

FM

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 14 Feb 2006 12:32:01 -0800

> deployment is very likely in the noise.

I usually mean some crappy low end 1U Linux box with a processor that is
about 75% the speed of whatever the fast thing Intel makes is so, to your
point, much cheaper than 10k.

However, the costs seems to all be operationally not capital - I'm not a
service provider but I'm sure some will be willing to comment. When you are
talking about 10s of million IM users that all pay exactly zero for the
service, people seem to get fairly concerned about the number of servers.
I'm generally not a fan of arguments of the form "we could not do the right
thing because we had to optimize it to run on a 4Mhz 386 with 160 octets of
memory" but in this case, I'm doubtful that protocol elegance is going to
win over significant operation const reductions.

> for OPTIONS and/or PING parsing and turnaround.

Right - once we decide that we are going to have to optimize something, we
start looking at what and what protocol designs could make it easier. Way
back a bunch of us when down this path. We firt noted that in a proxy, it
looks like over 80% of time processing anything is in SIP stack. So doing
anything was going to have to happen underneath the SIP parser. This was a
bummer - it means we have to change the SIP stacks. We then considered what
would we want that we could parse really fast at the bottom of the stack. A
binary encoded TLV record looked really appealing. Not surprisingly, STUN
had selected exactly that for more or less the same reasons.

> protocols that traverse the NAT should be responsible for dealing with

I think I am with you about doing the right thing and making SIP work
through NATs. So we go and add a shim underneath the typical SIP parser
that can deal with the NAT stuff. It needs to have a PING/PONG style
liveness test for TCP and UDP. For UDP it also needs to report the perceived
public address and port. It needs to be fast and deal with high volume of
requests. 

If you go and design something to meet these requirements, would you come
back with anything that was different (in a way that was better) that STUN?

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 14 Feb 2006 16:13:09 -0500

Actually, STUN is for everything BUT NAT discovery these days.

As you may know, a revision of RFC3489 has been under development in 
behave for some time. One of the major changes we made almost a year 
back was to remove the entire NAT discovery and NAT type classification 
from STUN. It has been found to be unreliable, brittle, and a poor 
solution for many reasons that are well documented. As such, the draft 
is now focusing on a toolkit-like approach for nat traversal. We have 
been using STUN in ways that are a bit different than its original 
nat-type detection, including with ICE (where its muxed with RTP for the 
same reasons we mux with SIP here), and for address allocation from 
servers without the type detection.

-Jonathan R.

---

From: Dean Willis <[email-masked]>
Date: Tue, 14 Feb 2006 15:18:37 -0600

I've noticed a common thread in this discussion about SIP and STUN.  
Lots of people commenting on it don't understand WHY we're talking  
about it, so it sounds strange to them. It might well BE strange, but  
it helps to have the background.

That's ok. It's why we write drafts. And why we read them.

The topic under discussion is in the "Outbound" draft:

http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-01.txt

Keepalive requirements are discussed in section 3.5.

Detecting flow failures is discussed in section 4.2

Processing of STUN requests in parallel with SIP is discussed in  
section 7.1

--
Dean

---

From: Hisham Khartabil <[email-masked]>
Date: Wed, 15 Feb 2006 14:16:05 +0100

This is all theory and guesstimates. We'll try to prototype these 
things and get back to the list with hard numbers to prove or disprove 
the 2 theories. If anyone willing to co-operate on this, please contact 
me.

Regards,
Hisham

---

From: Pekka Pessi <[email-masked]>
Date: Wed, 15 Feb 2006 14:50:11 +0200

Dean Willis <[email-masked]> writes:
>> MAPPED ADDRESS. Now bringing in the PING method would again be introducing
>> a SIP message based processing which would lead to poor performance.

>We've demonstrated successfully slaying proxies by bombing them with OPTIONS
>requests.

>Back in the "early days" of dynamicsoft, our first proxies were processing 7
>INVITE/200/ACK/BYE/200 non-authenticated transaction sequences or about 20
>OPTIONS transactions per second. They've of course gotten much faster, but
>the proportions have stayed pretty much the same.

>So you can see that in models where a typical SIP transaction load might be
>5 transactions per hour per node, adding another 60 OPTIONS transactions per
>hour per node might reduce your edge-proxy scalability by on the order of
>13-1, or roughly a 93% performance hit. That's a big hit.

Of course, that is the relative performance hit that you will see
on a 100 Mb/s ethernet, which I think is the bottleneck on most
SIP servers. You do lot of OPTIONS, you use all you bandwidth
receiving OPTIONS, right? ;-)

On more serious discussion, you use roughly the same number of
packets and system calls to process a STUN request as when
processing OPTIONS, The bottleneck is not in the CPU doing SIP or
STUN parsing but (hopefully) somewhere else, like your memory bus
or network I/O. Both SIP and STUN parser and processing code fit
nicely in your cache nowadays, mixed STUN/SIP server losing
because it has to fit both SIP and STUN parser code in its cache.

Of course, a hypothetical SIP server implemented in Perl and
heavily relying in shell scripting might be a different story.

--Pekka

-- 
http://sofia-sip.sf.net

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 15 Feb 2006 12:04:59 -0500

The bandwidth aspect of this is important too. The STUN request in 
question here is 20 bytes, and the response is 36. A SIP OPTIONS request 
and response is probably around 300-400 bytes. At a rate of a keepalive 
every 15 seconds, you end up with 320 bps per subscriber for OPTIONS, 
and 3.8 bps for STUN (not counting IP/UDP overheads). Its interesting to 
compare this to 'useful' traffic. Assuming .1 erlangs and a hold time of 
3m during the busy hour, you get 5.5e-4 calls per second per subscriber. 
With a INV/200/ACK BYE/200 sequence, and assuming 1kB for INV/200 and 
300B for the others, thats 2.9 kB total per call, and thus 12.76 bps per 
subscriber. As a consequence, with the OPTIONS approach, you have a 
bandwidth overhead of 320/12.76 which is 25, or 2500%!!!! WIth STUN, 
this is a still painful but palatable 3.8/12.76 = 30%.

To put that in perspective, a server supporting 100k subscribers would 
require 1.2 Mbps access for useful signaling, and an additional 32 Mbps 
just for the useless OPTIONS message. To make sure you are nowhere near 
(i.e. not within 50%) of link saturation, this comes close enough to the 
limit of 100M ethernet that you'd probably need to jump to GiGE, whereas 
10M ethernet would suffice with STUN keepalives.

-Jonathan R.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 14 Feb 2006 08:00:34 -0800

I don't see any reason that the PING will work better than just sending
OPTIONS

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 17 Feb 2006 14:14:26 -0500

> I don't see any reason that the PING will work 
> better than just sending OPTIONS

It doesn't have to be PING or PING as currently defined.  It could be any
new SIP method which by definition indicates that parsing the rest of the
message is ok but not really needed.

The problem with OPTIONS is that it requires the typical full processing to
identify the target, identify a willing to produce a successful response,
produce the full successful OPTIONS data, and adhere to potential forking
concerns.

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 20 Feb 2006 10:50:26 +0100

Forget about OPTIONS as an option for nat keepalives. It has a specific 
job to do and proxies/UAs have code already built in to handle it. It 
is a bad idea to try to optimise OPTIONS for the purpose of keepalives, 
imo.

Hisham