Subject: RE: [Sip] Outbound and STUN Keep Alive

From: "Francois Audet" <[email-masked]>
Date: Thu, 16 Feb 2006 12:40:44 -0600

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Wednesday, February 15, 2006 21:00
> To: [email-masked]
> Cc: Dean Willis; Audet, Francois [SC100:9T51:EXCH]; Cullen 
> Jennings; [email-masked]
> Subject: Re: [Sip] Outbound and STUN Keep Alive

> I would argue that 3x is already good enough to make this worthwhile.

I can't really comment on the 3x claim.

However, assuming that it is true, I am still not sure that in the total
scheme of things that the proxy needs to do, that it would make
a significant difference.

The 3x assertion is comparing just the STUN-in-SIP vs. PING 
keep-alive process.

How big of a fraction of the overall load on "real-life" proxy is 
keep-alive is the more important question.

I find it quite bizarre that we are so worried about using a binary
protocol for keep-alive, while we went complete the other way for
everything else in SIP (increasing amount of subscribtions to various
complex XML packages as a example).

Our experience with an (optimized) PING mechanism on large scale 
deployment and PING for keep alive is not seen as affecting 
significantly overall processing requirements on proxies.

Of course, I understand that all SIP proxies are not equal, and that
it could be much different on other types of proxies (e.g., where
the ratio of idle calls to active calls is extremely big, or where
the proxy is extremely lightweight). 

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Thu, 16 Feb 2006 13:23:46 -0600

> keep-alive is the more important question.

It's potentially a dominate proportion. An average phone might place  
less than 5 calls per hour (actually, less than 1 per hour is common)  
but do 120 keepalive operations per hour, or even 240 if we adopt the  
15-second suggestion.

So, keepalive could represent more than 98% of the transaction load  
on an edge proxy, in terms of SIP transactions.

Reducing 98% of the load by 1/3 represents a more than 30% overall  
performance boost. That may be worth talking about. Reducing it by  
90% would be worth celebrating with fireworks and free beer.

--
Dean

---

From: "Gary Gan" <[email-masked]>
Date: Thu, 16 Feb 2006 16:23:01 -0500

I don't know why the double CRLF is not enough for keep-alive.

1. It doesn't need the response from the server to keep the NAT binding   
   alive. Am I wrong on this? 
2. It is small, not much network traffic is introduced.
3. Little CPU is required, for the SIP server just simply ignores it,
   because it is considered as an invalid SIP message.
4. The SIP binding is refreshed by the keep-alive SIP Register message.

The only problem I can think of is that the UA doesn't know if the server is
down between now and the next SIP REGISTER is sent. 

Gary Gan
Sr. Software Developer

Clique Communications, LLC
205 Rockingham Row
Princeton Forrestal Village
Princeton, NJ 08540
Phone: 609-564-0206

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
Willis
Sent: Thursday, February 16, 2006 2:24 PM
To: Francois Audet
Cc: Cullen Jennings; [email-masked]; [email-masked]
Subject: Re: [Sip] Outbound and STUN Keep Alive

--
Dean

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 16 Feb 2006 14:02:43 -0800

> down between now and the next SIP REGISTER is sent. 

But it is important to know this. When it happens, no INVITE or NOTIFY
can be received until the next REGISTER/SUBSCRIBE. This was already bad
when the INVITE was not received, but there is more and more services
using SUB/NOT - presence, mwi, ua-profile, etc...

We also saw this problem with some ADSL providers, especialy in Europe,
 that are changing the DHCP IP address each nigh (server reboot?)

-- 
Marc Petit-Huguenin
Home: [email-masked]
Professional: [email-masked]
Work: [email-masked]

---

From: Dean Willis <[email-masked]>
Date: Thu, 16 Feb 2006 16:19:51 -0600

> down between now and the next SIP REGISTER is sent.

Right, that's exactly the problem we're trying to solve. Keeping the  
NAT alive is only half the problem -- knowing when it has died and we  
need to renegotiate is the other half.

Sure, we could REGISTER every 15 seconds, but I'm POSITIVE that's  
going to slow things down . . .

--
Dean

---

From: Darshan Bildikar <[email-masked]>
Date: Fri, 17 Feb 2006 16:47:36 +0530

Couldn't this problem also be solved using some kind of multicast mechanism?

All SIP UA's registered to a proxy form a multicast group and express an
interest in receiving keep alive multicast packets.. The proxy sends out
keep alive packets to a multicast IP...

The UA's have a timeout mechanism ... say they don't receive keep alive
packets for a pre defined duration (say one minute) then they consider the
link broken. Load on the proxy is also greatly reduced. 

Am thinking only from the point of view of a keep alive mechanism... not
refreshing NAT bindings. 

Just a thought.

Darshan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
Willis
Sent: Friday, February 17, 2006 3:50 AM
To: Gary Gan
Cc: 'Cullen Jennings'; [email-masked]; 'Francois Audet'; [email-masked]
Subject: Re: [Sip] Outbound and STUN Keep Alive

--
Dean

_______________________________________________
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: "Gary Gan" <[email-masked]>
Date: Thu, 16 Feb 2006 21:09:37 -0500

Are we overkilling this issue by inventing a new keep-alive mechanism that
could potentially overload the server by 90% more, just to resolve a
down-time situation, which can be automatically recovered anyway but just
delayed for a few minutes? But I have to agree that some UA implementation
defaults the SIP REGISTER expiry time to 1 hour, in which case the problem
would be more severe.  

So the problem becomes the UA polling for the healthy of the server,
probably the healthy of the logical UDP binding. To let the server echo the
simple keep-alive, such as CRLF, probably is enough for this issue. It
doesn't introduce too much overhead to the server and network.
Theoretically, the echo back CRLF can get lost, but it can be handled in the
UA side by retransmitting the keep-alive polling when it can not find the
response. If it fails a few times, the UA can declare the server down, out
of service. 

By introducing the multiplexing of STUN server with SIP server for the
purpose of keep-alive, I don't see obvious more benefits than a simple
PING/PONG mechanism. I agree to use STUN, ICE on the side to solve the
firewall traversal. But it would be only per restart of UA or per call
basis. Not constant polling even when it is idle.

Some IP service provider may change the NAT IP address on the daily basis,
but I don't believe it would change it when there is a keep-alive message
going on in a period of like 15 seconds, even though the message is short.

Gary Gan
Sr. Software Developer

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Thursday, February 16, 2006 5:20 PM
To: Gary Gan
Cc: 'Francois Audet'; 'Cullen Jennings'; [email-masked]; [email-masked]
Subject: Re: [Sip] Outbound and STUN Keep Alive

--
Dean

---

From: Darshan Bildikar <[email-masked]>
Date: Fri, 17 Feb 2006 09:36:35 +0530

Just a thought.

Darshan

-----Original Message-----

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 17 Feb 2006 11:53:37 -0500

No, multicast does not help. The NAT bindings must be kept alive by a 
packet that has the same 5-tuple information as later SIP packets to be 
delivered by the SIP proxy.

-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: Jonathan Rosenberg <[email-masked]>
Date: Fri, 17 Feb 2006 12:00:01 -0500

The functional benefit of STUN over CRLF is two things:

1. a clear transaction ID that makes it EASIER to do timeouts. Its 
possible without it, just more difficult.

2. more importantly, it allows you, for UDP, to detect a reboot of the 
NAT. STUN will echo back the source port in MAPPED_ADDRESS. The UA can 
look at this and detect nat reboot. Without this, you won't notice it 
for an entire registration interval and thus effectively have a service 
outage. Imagine this happening at an enterprise with SIP phones and the 
server provided by a service provider on the public side of the nat. 
Basically, a reboot of the enterprise nat would result in a total system 
outage for an entire hour. There needs to be a way to avoid this.

-Jonathan R.

---

From: "Gary Gan" <[email-masked]>
Date: Fri, 17 Feb 2006 15:41:42 -0500

Why most SIP UA uses UDP protocol in first place. If it uses TCP, the UA
will get notified by the TCP stack automatically if the server or NAT is
down.

Gary Gan
Sr. Software Developer

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Friday, February 17, 2006 12:00 PM
To: Gary Gan
Cc: 'Dean Willis'; 'Cullen Jennings'; [email-masked]; 'Francois Audet';
[email-masked]

-Jonathan R.

---

From: Dean Willis <[email-masked]>
Date: Fri, 17 Feb 2006 15:37:21 -0600

> will get notified by the TCP stack automatically if the server or  

Well, we found that its was sometimes more like 20 minutes before TCP  
notices.

--
Dean

---

From: "Gary Gan" <[email-masked]>
Date: Fri, 17 Feb 2006 17:10:13 -0500

How about if each UA maintain a TCP connection to the server just SKINNY
protocol in Cisco CallMananger? The client gets notified immediately when
the server is down. If you unplug the cable, it may take a while, but not
long, I would say in the matter of a minute, for the TCP will give it a try
to recover.

I don't know if the SIP TCP maintains a constant connection or not. It may
use TCP as per request basis, just like web requests. If it doesn't maintain
a connection, it will face the same problem as UDP in terms of keep-alive.

Gary Gan

--
Dean

---

From: "Gary Gan" <[email-masked]>
Date: Fri, 17 Feb 2006 17:52:21 -0500

I reviewed the SKINNY protocol in Cisco CallManager, it is TCP connection
based. But it also has defined a keep-alive echoing message. So that there
must be cases that even in TCP, a transport layer keep-alive is still
required in order for a UA to know the server's health.

Gary Gan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gary
Gan
Sent: Friday, February 17, 2006 5:10 PM
To: 'Dean Willis'
Cc: 'Cullen Jennings'; [email-masked]; 'Francois Audet'; [email-masked]
Subject: RE: [Sip] Outbound and STUN Keep Alive

Gary Gan

--
Dean

---

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

Jonathan,

On Feb 17, 2006, at 6:00 PM, Jonathan Rosenberg wrote:

> for an entire registration interval and thus effectively have a 
> service outage. Imagine this happening at an enterprise with SIP 
> phones and the server provided by a service provider on the public 
> side of the nat. Basically, a reboot of the enterprise nat would 
> result in a total system outage for an entire hour. There needs to be 
> a way to avoid this.

I agree this specific feature is very useful and necessary. We 
experience such problems of rebooting NATs with our customers today.

What we are not taking into account the overhead of having 2 protocol 
stacks talk to each other. We need to do the following:

- modify the sip parser to recognise the message is a stun message 
(replicating code in the stun stack)
- modify the stun stack to accept stun messages from an adjacent 
protocol stack
- modify stun stack to enable it to send stun messages through another 
protocol stack instead of tcp/ip sockets
- modify the sip stack to talk to the stun stack for sending an 
receiving stun messages
- build an application on top of both stacks that watches stun 
responses to keepalive stun requests and triggers SIP REGISTER requests 
whenever the external ip-address/port of a binding has changed.

The last point above requires some processing as well that is not being 
taken into considerations by the statistics being presented on this 
thread.

I have earlier suggested a similar sip method to PING, called it 
NATKEEPALIVE that the server responds to with a 200 Ok and adding a 
contact header reflecting the source IP address and port, effectively 
achieving what we are trying to achieve with stun.

Hisham

>> would be more severe.  So the problem becomes the UA polling for the 
>> healthy of the server,
>> of service. By introducing the multiplexing of STUN server with SIP 
>> server for the
>> From: Dean Willis [mailto:[email-masked]] Sent: Thursday, 
>> February 16, 2006 5:20 PM
>> To: Gary Gan

---

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

> response. If it fails a few times, the UA can declare the server down, 

Forget about the CRLF for UDP as well. It does not have the feature 
that solves the rebooting NAT problem.

Hisham

---

From: <[email-masked]>
Date: Wed, 22 Feb 2006 09:23:46 +0200

Hi ! 

>Forget about the CRLF for UDP as well. It does not have 
>the feature that solves the rebooting NAT problem.

What about the following approach (at least as a short
term solution while the ultimate solution will not yet
be defined or supported by the deployed servers):

- Send CRLF to SIP proxy for NAT binding keepalve

- Simultaneously send STUN binding requests to a separate
  STUN server discovered in the domain of registered SIP
  AOR, in order to detect NAT reboots 

Yes it will add overhead (not good for an ultimate solution)
but can you point out any other profound flaw with this 
approach ? E.g. SIP server and STUN server located in 
different address spaces so that the NAT reboot detection
would possibly not work etc. ?

Regards,

Erkki

>From: ext Hisham Khartabil [mailto:[email-masked]] 
>Sent: 20.February.2006 11:53
>To: Gary Gan
>Cc: 'Cullen Jennings'; [email-masked]; 'Francois Audet'; 
>[email-masked]; 'Dean Willis'
>> Are we overkilling this issue by inventing a new keep-alive 
>mechanism 
>> that
>> Theoretically, the echo back CRLF can get lost, but it can 
>be handled 
>> in the
>> UA side by retransmitting the keep-alive polling when it can 
>not find 
>> the
>> response. If it fails a few times, the UA can declare the 
>server down, 
>> out
>> of service.
>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 22 Feb 2006 08:46:16 -0800

> would possibly not work etc. ?

Say you have two SIP clients A and B that use the same default port behind
the same NAT and that NAT does port preservation (this is fairly common).
Then the NAT reboots. Without loss of generality, assume A had got the
preserved port and B had not. Each UA has sends a stun packet that create a
new binding. If A sends first, it will get the same binding it had last time
and it will not detect that the NAT had rebooted. However, it binding for
SIP may or may not be the same as before the NAT rebooted and it may not
work. In this case, it seems like about 50% of the time, one of two clients
will think things are OK when in fact they are not.