Subject: [sipcore] comments on draft-holmberg-sipcore-rkeep-00

From: "Dan Wing" <[email-masked]>
Date: Mon, 6 Aug 2012 16:25:35 -0700

The document insufficient describes the problem.  It only says "One reason
can be that the scheduling policy", with insufficient detail.  After bumping
into the SIPCORE chairs and mentioning that I had some feedback on 'rkeep',
I have a deeper understanding of the problem space.  However, the document
should provide that understanding.  Specifically, the problem is that
applications cannot get scheduled to send their periodic keepalive messages,
but that a network-originated packet will allow the application to get
scheduled to send its reply; it is that reply message that is critical to
RKEEP working (because the NAT pinhole is often only refreshed with outbound
traffic, not inbound traffic).  This needs to be clearly stated in the
document.  When that is done, we can more carefully understand the reason
that operating systems are reluctant to schedule applications to send
occasional keepalive traffic.  I would guess the reasoning is to save the
device's battery.  If my guess is accurate, then RKEEP destroys (ruins) that
purpose of application scheduling.  SIP is not the sole protocol that would
benefit from RKEEP.  We could see other long-lived quiescent connections
benefiting from RKEEP, such as IMAP or XMPP, to keep their TCP connections
open.  If RKEEP is used by those other connections, the servers will not
synchronize when they send their keepalive traffic.  In contrast, if the
applications were allowed to schedule their own application keepalives and
their own network keepalives, the applications (or the client operating
system) could coordinate those application and network keepalives to use the
battery most efficiently.  With RKEEP's network-based keepalives, such
efficiency can never be realized.

This text in the document:
   This section describes how SIP UAs and proxies negotiate usage of
   keep-alives associated with a registration, or a dialog, which types
   of SIP requests can be used in order to negotiate the usage, and the
   lifetime of the negotiated keep-alives.
and several other places in the document, intermixes two things, (a) SIP
dialog state and (b) NAT pinhole state.  These really need to be described
separately, because they are different things -- (a) is application state
(SIP dialog state) the (b) is network middlebox state (NAT state).
Combining them, for the purposes of optimization, is useful, but needs to be
clearly stated.  This is because if the SIP communication is over TCP or is
signaled with PCP, the network state maintenance changes whereas the
application state may well remain the same (the application may want a
'liveness' check every ~10 minutes, but the network elements no longer need
such frequent traffic).

The document needs to acknowledge and describe the firewalls -- and not just
NATs -- create state that occasionally needs refreshing.  Currently, the
word 'firewall' does not appear in the document at all.  This is important
because while it might be true that "NAT goes away with IPv6", the need and
value of firewalls to protect the network (from useless noise traffic) and
to protect hosts does not necessarily go away with IPv6.  And of course
NAT64, if it is used with a SIP service (e.g., over the top service), may
also need these similar functions and thus IPv6 (on the handset) didn't
eliminate the need for NAT keepalives if the traffic traverses a stateful
NAT64.

The document should recommend PCP as the better answer than RKEEP.

Nit:  removing the rkeep parameter (Section 5.4) isn't the best way to
signal support of rkeep, but I believe that feedback was already provided in
the WG meeting.

-d

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 06 Aug 2012 16:43:15 -0700

Thank you Dan for providing a different perspective.
This demonstrates a reason not to rush this work into sipcore - that we 
should investigate if the problem deserves to be considered in a broader 
focus.

While we think about where to deal with this I encourage more discussion.

	Thanks,
	Paul (as sipcore co-chair)

On 8/6/12 4:25 PM, Dan Wing wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 8 Aug 2012 21:50:52 +0200

Hi Dan,

>document.

In my presentation, I tried to make it very clear that it is the STUN *response*, sent
from the UA, which acts as the actual keep-alive message, due to the reason
you also mention,

But, I do agree with you that it should be made more clear in the draft.

>When that is done, we can more carefully understand the reason
>purpose of application scheduling.

I don't think it's only about sending keep-alives, but to be able to perform any type of scheduled actions.

>SIP is not the sole protocol that would benefit from RKEEP.  We could see other long-lived quiescent connections
>benefiting from RKEEP, such as IMAP or XMPP, to keep their TCP connections open.

Keep in mind that the actual STUN keep-alive mechanism is already defined in RFC 5626. This draft only defines a *SIP*
mechanism for negotiating the usage of it.

If you want to define how *other* protocols negotiate the usage of STUN for keep-alives, I don't think it belongs in this draft.

>If RKEEP is used by those other connections, the servers will not synchronize when they send their keepalive traffic.  In contrast, if the
>applications were allowed to schedule their own application keepalives and their own network keepalives, the 
>applications (or the client operating system) could coordinate those application and network keepalives to use the
>battery most efficiently.  With RKEEP's network-based keepalives, such efficiency can never be realized.
>
>clearly stated.

SIP dialog only refers to the scope of the negotiated keep-alives, ie that you can negotiate them to be sent within the lifetime of a SIP dialog.

>This is because if the SIP communication is over TCP or is

As said earlier, the STUN keep-alive mechanism is already defined in RFC 5626. 

RFC 6233 defines a SIP mechanism which allows a UA behind a NAT to indicate willingness to send such STUN requests, and this draft now defines a SIP mechanism (based on the 6233 mechanism) which allows a UA behind a NAT to indicate willingess to receive such STUN requests.

>signal support of rkeep, but I believe that feedback was already provided in

The details of the mechanism obviously needs to be discussed, if the work is started.

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Wed, 08 Aug 2012 15:06:59 -0500

[as an individual]

On 8/8/12 2:50 PM, Christer Holmberg wrote:
> Keep in mind that the actual STUN keep-alive mechanism is already defined in RFC 5626. This draft only defines a*SIP*
> If you want to define how*other*  protocols negotiate the usage of STUN for keep-alives, I don't think it belongs in this draft.

The concern, I believe -- and I've heard this from people other than Dan 
-- is that the issue of sending periodic NAT binding keepalives in the 
face of unpredictable OS scheduling is a *general* problem, and that it 
might be inadvisable to come up with application-by-application 
solutions to the problem.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 8 Aug 2012 22:28:39 +0200

Hi,

>The concern, I believe -- and I've heard this from people other than Dan -- is that the issue of sending periodic NAT binding keepalives 
>in the face of unpredictable OS scheduling is a *general* problem, and that it might be inadvisable to come up with application-by-application 

You might still need protocol-by-protocol solutions to negotiate the keep-alive, and the draft defines a negotiation solution for SIP. It can then be used by any SIP application.

Regards,

Christer

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 8 Aug 2012 17:41:17 -0700

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Wednesday, August 08, 2012 12:51 PM
> To: Dan Wing; [email-masked]
> Cc: [email-masked];
> [email-masked]
> Subject: RE: comments on draft-holmberg-sipcore-rkeep-00
> 
> Hi Dan,
> 
> from the UA, which acts as the actual keep-alive message, due to the
> reason you also mention,
> 

That is the solution.

The underlying problem is caused by operating systems that are not
allowing client applications, running on handsets, to send their 
own keepalives.  It is that problem I would like to have better
described.  

> perform any type of scheduled actions.

That is vague.  Can you be more specific by what you mean about 'scheduled
actions', if those are not keepalive messages.

> >SIP is not the sole protocol that would benefit from RKEEP.  We could
> see other long-lived quiescent connections
> Keep in mind that the actual STUN keep-alive mechanism is already
> defined in RFC 5626. This draft only defines a *SIP*
> If you want to define how *other* protocols negotiate the usage of STUN
> for keep-alives, I don't think it belongs in this draft.

I understand the scope of the draft.

My point is that the problem is larger than just the SIP application.

That is why I want the problem described better, so we can understand
the underlying cause of the problem -- and either get that fixed (because
it is flawed) or understand it better so we can quickly apply this
same RKEEP-style workaround to the other 213 applications that use
long-lived connections (the number 213 might be off by an order of
magnitude).

> >If RKEEP is used by those other connections, the servers will not
> >applications (or the client operating system) could coordinate those
> application and network keepalives to use the
> SIP dialog only refers to the scope of the negotiated keep-alives, ie
> that you can negotiate them to be sent within the lifetime of a SIP
> dialog.

I'll leave it to y'all, as SIP experts, how that relates to registration
refresh, if it relates at all.

> RFC 6233 defines a SIP mechanism which allows a UA behind a NAT to
> indicate willingness to send such STUN requests, and this draft now
> defines a SIP mechanism (based on the 6233 mechanism) which allows a UA
> behind a NAT to indicate willingess to receive such STUN requests.

-d

> Christer=