Subject: Re: [Sip] Keepalive mechanisms and related flags in outbound-09

From: "Rohan Mahy" <[email-masked]>
Date: Sat, 7 Jul 2007 08:45:11 -0700

Hi Erkki, et al.

I hope you are enjoying your summer holiday.  I'm assuming that Aki
and/or Miguel will join in the thread, per your other email.

I was hoping that François Audet would reply to the time-keepalive
part of this thread, but I will reply based on one of the use cases he
described to me.  I will also talk a bit about keep-stun and
keep-crlf.

Comments inline.

On 6/28/07, [email-masked] <[email-masked]> wrote:
>
> 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 ?

If the server did not add "timed-keepalives", and the UA is happy with
the value of the TCP keepalive timers, then the UA can use TCP
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.

The 'ob' parameter is not appropriate if we continue to allow STUN
keepalives to be used without outbound.  Christer requested this and
the WG agreed to move the STUN keepalive definition to a separate
section of the draft.

We could certainly change 'keep-stun' and 'keep-crlf' to just 'keep'
(for example), but we had consensus that supporting keepalives and
supporting outbound should be kept orthogonal.  In addition, I think
using 'ob' in so many contexts would be confusing:
- in the first Path header it means that the first Edge Proxy added a flow token
- in the UACs Contact header it means that the UAC registered
successfully with outbound.  The first Edge Proxy can use this as a
hint to add a flow-token to its Record-Route.
Then you propose to add this one:
- in the outbound-proxy-set URIs it means that keepalives are supported.
- in the topmost Path header returned after registration it means that
keepalives are supported

Having 'keep-stun' and 'keep-crlf' is merely historic and I support
merging these into a single 'keep' parameter if we have consensus to
do so.

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

This parameter was a compromise between folks who want the client to
be able to send whenever it likes (typically less often, to conserve
battery power for example); and folks who want their server to be able
to track liveness of their clients.

The spec does not define what a proxy using timed-keepalives would do
with this information, but below are some examples.

1) The UA is used in a call center.  If a certain number of keepalives
are missed by a UA, the proxy assumes the UA could be down and only
forwards calls to that agent when no "live" clients are available.

2) If several keepalives are missed, the proxy declares the UA down
and deletes the flow.

3) Associated with the proxy is a management station that shows the
status of each UA connected to it.

I am not trying to argue for including these features.  I am just
providing an explanation of what folks might do with this parameter.

I would like to point out that this only works if the EP and the
registrar are coordinated at least via configuration.  A simple way to
do this in a cross-domain environment would be for the EPs to include
;keep in the outbound-proxy-set and for the registrar to add
;timed-keepalives to the Path header for the EP.

> 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

Choice a) certainly does not work well for battery operated devices,
and choice b) does not enable the use cases I described above.

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

Discovering the topology between the UA and the EP is easy 90% of the
time and practically impossible 1% of the time.  The problem is that
the UA can't tell which situation it is in. Consequently, I won't hold
my breath for a deterministic solution to middlebox timer
configuration.

> 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

Your first URI isn't quite correct.  If your proxy has no interest in
timed-keepalives, then it would omit the parameter.  The 'ob'
parameter does not appear in the outbound-proxy-set.  If we
consolidate keep-stun and keep-crlf, the situation looks pretty good.

outbound-proxy-set:
sip:pri.example.com;lr;keep-stun;keep-crlf  OR
sip:pri.example.com;lr;keep

Path:
sip:pri.example.com;lr;keep-stun;keep-crlf;ob
sip:pri.example.com;lr;keep;ob

I don't think this is quite as daunting.

thanks,
-rohan

> Just guess why I prefer the latter ;-) Any comments ?
>
> 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