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

From: "Samir Srivastava" <[email-masked]>
Date: Wed, 22 Feb 2006 16:47:10 -0600

Compression can help here, if enough CPU juice is available.

Can we avoid both ways messages (REQ/RSP) flowing for the KEEP ALIVE.

Client indicates to the server (With Require tags), that it expects the
CRLF or keep alive message from the server. Server will send the keep
alive messages to clients without expecting a response. When client
doesn't see the keep 
alive messages for configured interval, it assumes box in between
rebooted or mapping is lost. It finds new mappings 
and re-registers. This does reduce traffic by half, though it is against
the normal REQ/RSP model of protocols here, 
and it does require periodic activity at server with some state for keep
alive. As we are changing server and clients both for this, why not get
the most optimal stuff.

For SIP based keep alive, How 15 seconds interval fit with
retransmission timers of NON-INVITE transactions which retransmit at the
max at the interval of 4 seconds till 32 seconds . Are we saying that we
are changing this ?
If the binding is gone, Detection will take between 32 seconds to 47
seconds without changing the existing state machines. Whether 47 seconds
unreachable time period is okay ?

Thx
Samir

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan Rosenberg
Sent: Wednesday, February 15, 2006 9:05 AM
To: Pekka Pessi
Cc: Cullen Jennings; [email-masked]; [email-masked]; Dean Willis
Subject: Re: [Sip] Outbound and STUN Keep Alive

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.

Pekka Pessi wrote:

> Dean Willis <[email-masked]> writes:
> 
>>[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.
> 
> 
> 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
> 

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

---

From: "Frank W. Miller" <[email-masked]>
Date: Wed, 22 Feb 2006 19:31:24 -0500

> max at the interval of 4 seconds till 32 seconds . Are we saying that we

The current draft says that you cannot have more than one PING
transaction outstanding with a given UAS at a time.  If we assume that
the UAC is retransmitting the PING but for some reason not receiving any
response there are several possibilities.

1) The UAS has gone down
2) The NAT binding has gone away and for some reason sending the PING
through it isnt refreshing it properly
3) The NAT is dead
4) Probably others...

In any event, you're wanting to send a heartbeat every 15 seconds to
keep the NAT up.  If you're still retransmitting after 15 seconds,
something is probably wrong.  The main problem here is that you're now
going to get into these 30 and 60 second waits as the backoff occurs on
the retransmission timer and that blows your 15 second heartbeat
function.

I'm actually wondering if we want to change this so that it does not
follow standard retransmission rules.  For example, the PING might be
sent unreliably, i.e. send it once and wait some period for a response.
If it doesnt come back, you kill that particular PING transaction.  If
you want to retransmit the PING, its a new transaction.  The choice of
whether to retransmit is pushed up to the application.  It knows best
what the context is for sending the PING in the first place.

So, some observations of something like this.  First, its a new
transaction type.  Its really simple, but it is new, its definitely not
a NIT.  I think it would be OK to still adhere to the routing rules but
not to the retransmission rules but I need to think on it some and I'd
be interested in any comments on that.

Second, its really dirt simple to implement at both the UAC and UAS.

Third, its now definitely different from the OPTIONS request.

Fourth, I'm starting to think that a PING request is a good idea in
general.  I've seen three good reasons why you would want something like
this: 1) to refresh NAT bindings, 2) as a heartbeat during a session,
and 3) as a check for the presence of a UA that is independent of
registrations.  This last bit could be very useful, particularly for
B2BUAs.  If I wanted to check whether another UA is available, a quick
PING would do nicely.  I know all three of these things can be done with
OPTIONS but with these new semantics, a PING would make more sense for
reasons that have been discussed, load, security, etc.

Thoughts?
FM