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

From: Dean Willis <[email-masked]>
Date: Wed, 15 Feb 2006 23:00:19 -0600

On Feb 15, 2006, at 10:10 PM, Brian Stucker wrote:

> Dean, et. al-
>
> Keep in mind one thing in your calculations... Parsing a MESSAGE  
> that is short (which may or may not be a message that needs further  
> processing) cannot be separated from "service" traffic as easily as  
> PING. Once I've parsed the request type I immediately know that I'm  
> dealing with a special case and can shunt processing over to a  
> separate chunk of code that can ignore much of the message.
>

This implementation modified the SIP UA for immediate handling of the  
MESSAGE request. It wasn't being shunted off to an application via  
the api -- the UA was immediately doing a 200-and-discard sequence.

> For instance, here would be a very simple way of parsing a PING:
>
> 1. Is the request type of the message "PING". If so, then shunt...
> 2. In the shunt parser take the original packet the PING came in on  
> and do the following:
> Replace the top of the buffer from "PING sip:xxxyyyzzz... SIP/2.0"  
> to "SIP/2.0 200". Pad the remainder with white space until you hit  
> the CRLF that terminates the request URI.
> 3. Append the correct header information to bottom of the packet to  
> identify the source of the request.
> 4. Send the packet back from whence it came.
>
> (Potentially) no data that needs to be copied and nothing other  
> than the first five characters of the message needs to be parsed.
>

How can you send a 200 OK without parsing out the Via header fields?

How do you get the cseq without parsing that out?

--
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: "Brian Stucker" <[email-masked]>
Date: Wed, 15 Feb 2006 22:10:56 -0600

Dean, et. al-

Keep in mind one thing in your calculations... Parsing a MESSAGE that is short (which may or may not be a message that needs further processing) cannot be separated from "service" traffic as easily as PING. Once I've parsed the request type I immediately know that I'm dealing with a special case and can shunt processing over to a separate chunk of code that can ignore much of the message.

1. Is the request type of the message "PING". If so, then shunt...
2. In the shunt parser take the original packet the PING came in on and do the following:
Replace the top of the buffer from "PING sip:xxxyyyzzz... SIP/2.0" to "SIP/2.0 200". Pad the remainder with white space until you hit the CRLF that terminates the request URI.
3. Append the correct header information to bottom of the packet to identify the source of the request.
4. Send the packet back from whence it came.

(Potentially) no data that needs to be copied and nothing other than the first five characters of the message needs to be parsed.

Regards,
Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Dean Willis
Sent: Wednesday, February 15, 2006 8:20 PM
To: Audet, Francois [SC100:9T51:EXCH]
Cc: Cullen Jennings; [email-masked]; [email-masked]
Subject: Re: [Sip] Outbound and STUN Keep Alive

On Feb 15, 2006, at 7:22 PM, Francois Audet wrote:

> I really don't see why processing a PING method would be any more
> resource-intensive because of "parsing" or whatever than processing
> a STUN message (binary) that happens to run on the same port
> the rest of the SIP protocol runs on.

Well, I'm sure there's at least SOME difference. How much remains to  
be determined.

I have a preliminary report from one of the performance people who's  
working with Jonathan. He did some saturation testing comparing the  
STUN operation to receiving, discarding, and 200oking a short MESSAGE  
request (roughly analogous to how PING processing would work if it  
were heavily optimized).

These initial results show at least a 3x difference, much of which is  
attributable to the parsing overhead. Once the MESSAGE request is  
liberated from its framing, it still has to be parsed enough to  
recognize it as a discardable message and figure out where to send  
the 200 OK response (which requires parsing Via header fields). Then  
the 200 OK response has to be constructed, which is pretty  
straightforward but still requires several times more string  
operations than the STUN response does. This testing was done on a  
very mature Java stack implementation, the SIP part of which has been  
highly optimized.

Now I'll also have to say I don't completely trust these results --  
they're preliminary, I have doubts about the STUN optimization, and I  
think we were hitting interface saturation on a 100 M ethernet. My  
gut feel is that the gap will widen above 3x as the testing (and  
implementation) gets better.

Is 3x significant? I suppose that depends on your business model and  
per-box overhead. It also changes the inflection points at which one  
has to go from single or paired-box models to high-availability  
clustering approaches with state replication, and THAT is a  
significant delta, if you;re not already past it.

--
Dean

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 16 Feb 2006 18:49:25 -0500

> How do you get the cseq without parsing that out?

If it is acceptable to define the SIP request so the receiver processes as a
request for echo instead of applying the typical SIP processing rules, the
parsing requirement would be minimal for devices which understand the
request.

For udp, the receiver of request would just need to partially decode the
Request-Line and first Via entry (if rport type functionality not assumed).
It could then echo back everything except Request-Line as the contents
within the 200 response.

For tcp, the receiver of request would just need to partially decode the
Request-Line and deal with content-length header.  It could then echo back
everything except Request-Line as the contents within the 200 response.

The sender of the request would need to decode enough of the response (first
Via entry) to match it to the request.

I currently have no strong opinion between STUN, the "double CRLF", and a
new SIP method.  All are better than the overhead of using REGISTER or
OPTIONS to produce a similar result.

One disadvantage of STUN and the "double CRLF" (echoing extraneous CRLFs) is
that they require both devices to support the functionality for it to work.
And I assume the device would need to fallback/use another mechanism when
not supported or support unknown by other.  Thus defining a new SIP method
might still be beneficial for use in these situations.  Additionally,
devices unable or unwilling to implement the STUN approach might at least be
willing to implement a new SIP method which is better than the ones
currently common.

Because the "double CRLF" has the least capacity hit on connection oriented
transports, I have to ask.  Is the limitation concerning the lack of
transaction ID a showstopper?  Would late CRLF "responses" really be common
enough and the consequence really be considered harsh enough so that this is
not a reasonable alternative?  I can't really imagine late data trickling in
at intervals to confuse the mechanism more than three times in a row.  And
for those (hopefully nobody) desiring even quicker knowledge of connection
closure, the capacity improvement of this mechanism actually allows the
check to occur more frequently than the other alternatives.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Feb 2006 10:39:31 -0500

Brian,

You still have to frame the message, at least if it arrives over TCP. 
That means hunting for the Content-Length header, parsing it, hunting 
for the CRLF, and then pulling the (presumably empty) body off.

I know you are going to say that the PING message can't have a body. But 
in that case it isn't really a normal extension to sip messages.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Fri, 17 Feb 2006 11:52:46 -0600

> than the first five characters of the message needs to be parsed.

I believe in the test case that I'm reporting that the MESSAGE  
response processing was short-circuited, and the test stack wouldn't  
have processed any MESSAGE request correctly.  So I think the 3-1  
ratio would apply to PING, even though the typical "full request  
processing" number may be more like 10-1.

But where are you assuming you send your response to if you don't  
parse Via? rport? What about asymmetric nodes and semitransparent  
proxies?

--
Dean

---

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

> But where are you assuming you send your response to 
> if you don't parse Via? rport? What about asymmetric 
> nodes and semitransparent proxies?

Concerning the where, I discuss an option within

http://www1.ietf.org/mail-archive/web/sip/current/msg12882.html

and 

http://www1.ietf.org/mail-archive/web/sip/current/msg12873.html

What aspects of a semitransparent proxy do you foresee a problem?

What should be sent until both devices finally support STUN as suggested?

---

From: Dean Willis <[email-masked]>
Date: Fri, 17 Feb 2006 13:25:12 -0600

> What aspects of a semitransparent proxy do you foresee a problem?

I believe it's possible to get a request for which the response  
cannot be routed back to the IP address and port it was received  
from. That is, you'd have to obey the Via.

> What should be sent until both devices finally support STUN as  

OPTIONS, I believe.

--
Dean

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 17 Feb 2006 15:04:13 -0500

> I believe it's possible to get a request for which 
> the response cannot be routed back to the IP address 
> and port it was received from. That is, you'd have 
> to obey the Via.

For the intended use over connection oriented protocols, the source port and
source address are only really desired.

For UPD, I potentially agree.  However the need could be clearly indicated
by definition of the request.  For instance ECHO could be defined to process
Via as usual.  And ECHOSRC could be defined so that sending to more than
source address and source port is not needed.

> > support STUN as suggested?

Because some vendors would likely be slow to implement or never implement
it, would it be beneficial to define a new easily optimized SIP request for
this purpose?

---

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

We tried to use OPTIONS as keep-alive, but found not very practical. It ends
up on the server side you will see almost all traffics are OPTIONS, as each
client is sending its own keep-alive (in 15-30 seconds interval). In case
like Vonage server, it doesn't response to SIP OPTION message, the UA would
trigger retransmission which further jams the server. You would see each
OPTION actually being sent 5-6 times within 10 seconds for the SIP stack
just trying to get the OPTION request go through. Currently we use double
CRLF, it keeps the NAT binding alive, but in case of NAT reboot, it is still
a problem. The UA wouldn't know if the NAT is rebooted (the addr/port
mapping may be changed), until the next time it re-registers to SIP
registrar.

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: Friday, February 17, 2006 2:25 PM
To: Brett Tate
Cc: [email-masked]
Subject: Re: [Sip] Outbound and STUN Keep Alive

OPTIONS, I believe.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 17 Feb 2006 14:11:57 -0600

> it, would it be beneficial to define a new easily optimized SIP  

My guess is that if we have consensus on something like coaxial STUN  
that we would be better-served by pushing new development that way  
instead of adding another stepping-stone.

If they aren't going to implement the preferred solution, having a  
less-optimal second choice available is probably not going to result  
in much more compliance, and will cause a fair amount of sustained  
divergence.

Would it be reasonable to give guidance on use of OPTIONS as a  
keepalive and on optimization of OPTIONS request processing in UAs?

--
Dean

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 17 Feb 2006 16:37:54 -0500

> it doesn't respond to SIP OPTION message, the UA 
> would trigger retransmission which further jams 
> the server. 

That is one concern I have about trying to define/use a new SIP message for
the keep alive.  Because of security reasons or poor implementations, some
servers might ignore the unknown request instead of producing an appropriate
failure response.  However STUN has the same limitation.

---

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

That is hardly a concern. You need to implement something to solve the 
problem. If we chose stun and proxy vendors don't implement it, then we 
have the same problem.

Hisham

---

From: "Brett Tate" <[email-masked]>
Date: Tue, 21 Feb 2006 14:36:52 -0500

> > Because some vendors would likely be slow to implement
> > or never implement it, would it be beneficial to define
> > a new easily optimized SIP request for this purpose?
> 
> My guess is that if we have consensus on something like
> coaxial STUN that we would be better-served by pushing 
> new development that way instead of adding another 
> stepping-stone.

It would not necessarily just be a stepping stone.  A version of it would
likely allow a proxy chain to be checked.

> Would it be reasonable to give guidance on use
> of OPTIONS as a keepalive and on optimization 
> of OPTIONS request processing in UAs?

It might help; and it is definitely better than some devices registering
every 15 seconds.  However it might be a little controversial trying to
standardize a "best common practice" concerning how to misuse OPTIONS and
REGISTER for this type of functionality.  

Because of the frequency of OPTIONS outside of a dialog being used
explicitly for this type of functionality, some have already overly
optimized/broke it for capacity/security reasons to receive OPTIONS but not
provide useful data within the response.