Subject: Re: [Sip] Keepalive mechanisms for TCP flows in outbound-08

From: "Rohan Mahy" <[email-masked]>
Date: Thu, 21 Jun 2007 10:56:07 -0700

Hi Erkki,

At IETF68 we agreed to add an indicator "timed-keepalive" that the
*server* expects keepalives to happen according to the timers
recommended in the draft.  If the server asks for this, then the
client needs to send pings (STUN over UDP or double CRLF over TCP or
TLS).  The *client* can tell if the server will send pongs (STUN
binding responses over UDP, or single CRLF over TCP or TLS) if the
server advertises "keep-stun" or "keep-crlf".  This allows a battery
operated client to use TCP keepalives or send pings less often if the
server allows, and it allows the client in general to know if they
should expect to receive pongs.

thanks,
-rohan

On 3/8/07, [email-masked] <[email-masked]> wrote:
> Hi,
>
> >> Question 1:
> >>
> >> Is the single CRLF "pong" necessary or could the UA detect the
> >> flow failure just by receiving a socket or ICMP error when the
> >> connection is broken and not able to pass the double-CRLF "ping"
> >> to the proxy ?
> >
> >Sure, if you don't mind not getting calls for 10 minutes. And if some
> >moron hasn't blocked ICMP on your network (which unfortunately
> >corpsec guidelines frequently recommend).
>
> To overcome this problem, doesn't Outbound strongly promote the
> UA registering over multiple flows ?
>
>    This requires the UA to detect when a flow fails.  Since
>    such detection takes time and leaves a window of opportunity for
>    missed incoming requests, this mechanism allows the UA to use
>    multiple flows to the proxy or registrar.
>
> Are you suggesting that this mechanism in the Outbound only
> has limited or even no value ?
>
> >It can take TCP a LONG time to know a flow has failed. This is a
> >large part of why I liked the STUN model.
>
> How does the addition of CRLF keepalive without CRLF "pong"
> make the situation worse compared using TCP keepalive, which
> has been considered acceptable for Outbound over several
> successive  draft revisions and is still there without any
> "pong" other than TCP ACK ?
>
> And as you say, it can take TCP a LONG time to know a flow has failed,
> but not necessarily. The device which rebooted might indicate the
> broken connection by sending TCP RST, which immediately tells the
> sender about the flow failure.
>
> Even the STUN over TCP model will not guarantee an immediate
> detection of a failed flow as Outbound suggests that the time
> between successive keepalives over TCP should be between 95 and
> 120 seconds on top of which the STUN transaction adds 8 seconds
> to wait for the response. So even with STUN or CRLF "ping-pong"
> you could not getting calls for two minutes if the UA is relying
> on one single flow only or using two flows towards two different
> proxies over a single NAT which reboots.
>
>
> I am still questioning whether the requirement to add CRLF "pong"
> and 'keep-crlf' URI tags are really worth the extra complexity.
> Personally I am not at all convinced about it.
>
> Regards,
>
> Erkki
>
> _______________________________________________
> 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: <[email-masked]>
Date: Wed, 27 Jun 2007 10:08:27 +0300

Hi Rohan,

To start with I have to apologize that I have not been able to
attend the latest IETF meetings (and will not be able to make it
for the next meeting either). That said I try to be reasonable
in my posts to the mailing lists even if I am not totally happy
to the fact that these issues were raised already in March but
will not be addressed before the end of June. Last year Outbound
was considered urgent and many WG members wanted it to be finished
as soon as possible, but recently the push to get it out seems to
have vanished somewhere. Maybe there has been something more urgent
gaining the focus.

Responding to the comments you made:

>TLS).  

I was able to find a note in the IETF68 SIP meeting minutes for this,
however I am not able to grasp the value of this indicator (unless
it is supposed to carry a value for the timers, but how could the
server know the keepalive times of the NATs between the UA and proxy ?)

>The *client* can tell if the server will send pongs (STUN

What I am worried about all this is that it seems to make the 
machinery quite complex. My preference would be to keep things
simple as creeping complexity seems to be a common problem for
SIP and its extensions. (E.g. I have heard many concerns that
the specs from the SIMPLE WG are really far from simple :-)

Yes I was one of the proponents for the UA probing STUN support
of proxy before starting to send STUN requests to the SIP port
of the proxy. However one solution for that, OPTIONS probing for
STUN support, was ultimately deemed too complex in IETF68 and
was agreed to be removed from the draft according to the minutes.

To me it seems that introduction of various flags like
"timed-keepalive",
"keep-stun" and "keep-crlf" will in the end have similar effect to
the complexity, which is not probably justified by the value gained.
I even fail to see how those flags would really help any battery
operated mobile device. The only thing which really helps is the
possibility for the UA to use TCP instead of UDP as TCP has longer
keepalive timers.

After this email from Cullen in the end of March...

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

... I was expecting to see a bit different solution in the
next version of the Outbound draft as suggested by me and 
Christer (to what Cullen agreed):

1. UA would check the transports supported by the proxy via DNS
   (NAPTR and/or SRV)

2. The proxy would indicate its Outbound support e.g. by adding
   'ob' parameter to its URI within the Path header

3. When UA knows the supported transports (from DNS) and Outbound
   support (from Path header) it can be sure that the proxy supports
   all keepalive methods Outbound has specified for those transports.
   At this point the UA can choose its keepalive method amongst:

	a) UDP: UA MUST use STUN
	b) TCP: UA can use either CRLF or TCP keepalives

4. Whatever keepalive method (type of pings) is selected by the UA,
   the proxy will send corresponding responses (pongs):

	a) UDP: STUN responses
	b) TCP: CRLF pongs or TCP ACKs

5. When sending the keepalives the UA would use timers as specified
   in the normative text of SIP Outbound draft.

Defined like that all the other flags "timed-keepalive",
"keep-stun" and "keep-crlf" could be removed from the draft.
I do not see enough value for those flags which seem to 

a) enable the proxy to support just one keepalive method 
for TCP; and

b) somehow complex negotiation between UA and proxy whether 
regular keepalive or heartbeat messages are expected.

Any comments to this proposal ?  If you find it acceptable,
could you please incorporate it either within the next version
of the Outbound draft or raise it as an open question for the
meeting to decide ?

>> "pong" other than TCP ACK ?

One of my colleagues pointed out that the OS implementations
for TCP keepalive typically have some timer for receiving the
ACKs. Thus it would mean TCP keepalive has an implicit timeout
behaviour which CRLF keepalives lack. After this comment I can
accept the value of CRLF "pong" and do not have any problem with
it.

Thanks,

Erkki

---

From: <[email-masked]>
Date: Thu, 28 Jun 2007 11:32:53 +0300

Hi,

I have today had a look into the fresh Outbound-09
to see how it addresses the keepalive issues in comparison
to the proposal I submitted originally in the beginning of
March and resent it yesterday.

My first questions are related to this statement:

   Clients MUST support this CRLF keepalive.

If so, what is the value of promoting the TCP Keepalive within
SIP Outbound ? In which circumstancies an UA supporting TCP 
Keepalive would instead select sending CRLF keepalive ?

Further on, I like this piece of text within Outbound-09:

   The client needs to perform normal RFC 3263 [4] SIP DNS resolution on
   the URI from the outbound-proxy-set to pick a transport.  Once a
   transport is selected, the UA selects a keepalive approach that is
   allowed for that transport ... 

That approach is elegant and consistent with RFC 3263.

But I still dislike these pieces of text:

   ... and that is allowed by the server based on the tags in the URI 
   from the outbound-proxy-set.

   User Agents that form flows check if the configured URI they are
   connecting to has a 'keep-crlf' URI parameter (defined in
   Section 12).  If the parameter is present and the UA is not already
   performing keepalives using another supported mechanism, the UA can
   send keep alives as described in this section.

   User Agents that form flows, check if the configured URI they are
   connecting to has a 'keep-stun' URI parameter (defined in
   Section 12).  If the parameter is present and the UA is not already
   performing keepalives using another supported mechanism, the UA can
   periodically perform keepalive checks by sending STUN [3] Binding
   Requests over the flow as described in Section 8. 

Outbound-09 suggests that configured proxy URIs could contain
'keep-crlf' or 'keep-stun' parameters, with which the UAs could
check whether the proxy supports the corresponding keepalive
mechanism before starting to send such keepalives. Instead of 
all that I simply suggest using the 'ob' parameter for the proxy 
URI to indicate that the proxy supports SIP Outbound and all the 
keepalive mechanisms defined in SIP Outbound for those transports 
the proxy supports according to DNS.

Rationale:

1. SIP Outbound anyway already mandates compliant proxies to
   support all keepalive mechanisms (see section 5.4) so there is
   no need to define separate flags for each of those mechanisms.
   One single flag for Outbound support is sufficient indication.

2. The draft has already defined the 'ob' URI parameter and how the
   proxy should use it. My proposal is to use the flag as defined
   but additionally to bundle the semantics of separate keepalive
   flags to this single 'ob' parameter.

3. The UA could check the presence of 'ob' parameter within the
   proxy URI either
	a) within its configured outbound-proxy-set; or
	b) Path header received within 200 OK to REGISTER
	   (like suggested in section 8)

4. Simple is better: less flags to be introduced to IANA,
   to the URIs or to the implementations. Resulting URIs
   would also be shorter with this single and short parameter.

Finally I do not find any value for the 'timed-keepalives' 
parameter. It was agreed in IETF68 but I was not attending
the meeting and I have not seen the rationale for it anywhere.
For the proxy point of view what is the difference whether or
not the proxy URI contains this parameter ? If the parameter
is within the URI, the proxy can be sure that it receives
the keepalives with intervals defined in the spec but otherwise
the UA could select longer intervals. However the spec does not
specify any actions for the proxy to check how often it receives
the keepalive messages so what is the point to have such a URI
parameter ? Instead of that I would suggest dropping this
parameter and either:

a) mandate the UA always to use timers as defined in the draft
or
b) let the UA always to choose any timer values it wants to use 
   and make the timer values in the draft as recommendations

Option b) could be better if the UA later on has some 
mechanism (like STUN extension etc.) to ask the middleboxes
to adjust their timer behaviour.

Example of URIs for a proxy supporting all keepalive methods:

Outbound-09:  
sip:pri.example.com;lr;keep-stun;keep-crlf;timed-keepalives;ob

My proposal:  
sip:pri.example.com;lr;ob

Just guess why I prefer the latter ;-) Any comments ?

Regards,

Erkki

---

From: Jerry Yin <[email-masked]>
Date: Thu, 28 Jun 2007 07:48:42 -0700 (PDT)

Hi Erkki,
   
  I think you got a good point. I don't know what is behind the "keep-" parameters. But I don't see a real value using these parameters either. I agree with you with your approach. Here is some more comments.
   
  First, if the proxy supports all three kinds of keep alive mechanism, the client is free to choose the one that it supports. Then the keep-parameter is not useful.
   
  Second, the client should be able to detect if it's behind a firewall or not (by rport). The client may not send any keep alive packet if it's not behind any firewall. In such case, the configuration with "keep-" parameter would only introduce confusion.
   
  Third, if the protocol can solve the problem automatically, it would be better not to introduce any configuration. Right now, there are too many configurations already to deploy on any SIP set.
   
  Fourth, similar to the ";transport=udp" parameter which does not need to be configured in any sip set explicitly if the UA can resolve the transport type by using NAPTR/SRV (RFC3263). Therefore again, it's not necessary to configure ";keep-xx" parameter if the proxy supports all of them.
   
  Jerry

[email-masked] wrote:  
Hi,

Rationale:

Outbound-09: 

My proposal: 

Regards,

Erkki

       
---------------------------------
Shape Yahoo! in your own image.  Join our Network Research Panel today!