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

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jul 2012 18:05:12 -0400

Some comments on this, as an individual, not chair:

Section 5.3:

    The parameter value, if present and with a value other
    than zero, represents a recommended keep-alive frequency, given in
    seconds.

We've been through this before with event-rate-control (RFC 6446) - 
seconds are a unit for measuring intervals, not frequency. Frequency is 
the reciprocal of interval. I suggest you replace "frequency" with 
"interval" everywhere.

Next:

    Once a SIP entity has negotiated receiving of keep-alives associated
    with a dialog towards an adjacent SIP entity, it MUST NOT insert a
    "rkeep" parameter in any subsequent SIP requests, associated with the
    dialog, towards that adjacent SIP entity.  Such "rkeep" parameter
    MUST be ignored, if received.

Why must it not be inserted, and why must it be ignored?
Wouldn't it be useful to allow the interval to be renegotiated?

Yet another thing in this section:

    If an INVITE request is used to indicate willingness to receive keep-
    alives, as long as at least one response (provisional or final) to
    the INVITE request contains a "rkeep" parameter with a parameter
    value which is different from the value in the request (counting a
    "rkeep" parameter without a value) it is seen as an indication that
    the adjacent downstream SIP entity is willing to send keep-alives
    associated with the dialog on which the response is received.

What happens in the presence of forking?

If the request is forked downstream from the node requesting keepalives, 
including if the neighbor does the forking, there can be responses in 
different early dialogs. But all of them will traverse the same neighbor 
who will be doing the keepalives. So, does this rule apply across all 
the different dialogs? Or must the response indication be separate for each?

Section 5.4:

The addition or removal of the value in the response to indicate 
acceptance seems weird.

IMO it would be better to arrange it so that the presence of a value in 
the response means keepalives can be expected with that interval.

I presume your concern is that a neighbor that doesn't support this will 
leave the parameter unchanged, so you need a way to force a change even 
if the requested interval is to be used.

Maybe we can find another way to accomplish that. Perhaps something 
extra in the request, in addition to the interval, that can be removed 
in the response. E.g.:

	Request	         Positive Response  Negative Response
	rkeep=5:desired  rkeep=5,           rkeep=5:desired
	                 or rkeep=10        or rkeep

If that's too verbose, how about "rkeep=5?"

Section 7:

Its empty!

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 Jul 2012 00:33:18 +0200

Hi Paul,

Thanks for your comments! See inline.

In general, the procedures are based on RFC 6223, so any restrictions and limitations that apply there also apply in the rkeep draft (unless they are affected by the semantical difference between the Via header field parameters in the both specs).

---------------------------

> We've been through this before with event-rate-control (RFC 6446) - seconds are a unit for measuring intervals, 
> not frequency. Frequency is the reciprocal of interval. I suggest you replace "frequency" with "interval" everywhere.

I guess we've been through that after RFC 6223, or we didn't spot it there, because it also talks about "frequency" :)

Having said that, eventhough I think common terminology would be useful, I see no major issue in using "interval" for rkeep.

---------------------------

>Wouldn't it be useful to allow the interval to be renegotiated?

Again, this restriction comes from RFC 6223.

I would have to dig through the archieves to remind myself why we made that restriction, but I ASSUME it could be related to the fact that it was a little unclear in which SIP request types (target refresh, etc) we would allow it.

---------------------------

>If the request is forked downstream from the node requesting keepalives, including if the neighbor does the forking, there can be responses in different early dialogs. But all of them will traverse the same neighbor who will be doing >the keepalives. So, does this rule apply across all the different dialogs? Or must the response indication be separate for each?

I guess it would be good to indicate the willingess to send keep-alives for each dialog, as dialogs have different lifetime. However, I see no need to start sending keep-alive instances for each dialog, as they are sent to the same entity.

---------------------------

>Section 5.4:
>
>The addition or removal of the value in the response to indicate acceptance seems weird.
>
>IMO it would be better to arrange it so that the presence of a value in the response means keepalives can be expected with that interval.
>
>I presume your concern is that a neighbor that doesn't support this will leave the parameter unchanged, so you need a way to force a change even if the requested interval is to be used.

Correct.

>Maybe we can find another way to accomplish that. Perhaps something extra in the request, in addition to the interval, that can be removed in the response. E.g.:
>

I guess there are many ways how it could be done. I just thought the currently suggested one was a simple one, without the need for additional parameters etc.

---------------------------

>Its empty!

Will be fixed in the next version.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jul 2012 20:38:25 -0400

> In general, the procedures are based on RFC 6223, so any restrictions and limitations that apply there also apply in the rkeep draft (unless they are affected by the semantical difference between t…

Feel free to use frequency rather than interval. But then the units 
can't be seconds. They then need to be keepalives-per-second.

If you've got good reason then I won't object. It's not a big deal.

>> If the request is forked downstream from the node requesting keepalives, including if the neighbor does the forking, there can be responses in different early dialogs. But all of them will traverse the same neighbor who will be doing>the keepalives. So, does this rule apply across all the different dialogs? Or must the response indication be separate for each?
>

I just think you need to discuss it.
Once you have something down about it there may be a number of people 
with opinions about it.

I'd like to have some other opinions on this.
It's really a matter of taste. It can work as it is.
As I say, to me it just seems weird and possibly something that people 
will misunderstand and implement wrong.

OK.

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 27 Jul 2012 13:32:00 -0400

> can't be seconds. They then need to be keepalives-per-second.

+1

Generally people use intervals rather than frequencies in
protocol-related quantities.

> > I would have to dig through the archieves to remind myself why we
> made that restriction, but I ASSUME it could be related to the fact
> that it was a little unclear in which SIP request types (target
> refresh, etc) we would allow it.
> 

Off the top of my head, I guess the problem regards ordering:  Since (in
general) the two entities are proxies, they do not necessarily see the
requests of a dialog in the same order.

> >> If the request is forked downstream from the node requesting
> keepalives, including if the neighbor does the forking, there can be
> responses in different early dialogs. But all of them will traverse
> the same neighbor who will be doing>the keepalives. So, does this rule
> apply across all the different dialogs? Or must the response
> indication be separate for each?
> >
> > I guess it would be good to indicate the willingess to send
> keep-alives for each dialog, as dialogs have different lifetime.
> However, I see no need to start sending keep-alive instances for each
> dialog, as they are sent to the same entity.
> 

I see this text:

   A SIP entity MUST NOT indicates willingness to send/receive keep-alives
   associated with a dialog, unless it has also inserted itself in the
   dialog route set [RFC3261].

So the sending/receiving of keepalives is bound to a dialog.  That makes
sense, as the end of the dialog determines when the keepalives stop.
(BTW, does the draft state that explicitly?)

If a request forks further downstream, the entity is Record-Routed into
all of the forks, but of course, each fork has a different lifetime.

It sounds like you want to say that all of the dialogs form a group, and
the group can be "kept alive" by only one sequence of keepalives, but
the sequence of keepalives must be maintained as long as any dialog in
the group exists.

BTW, does the mechanism ensure that the negotiated keepalive interval is
the same for all forks?

> > I guess there are many ways how it could be done. I just thought the
> currently suggested one was a simple one, without the need for
> additional parameters etc.
> 

At the least, it must be possible to examine a SIP message in isolation
and determine the meaning of the rkeep parameter without any further
context.  From the chart above, it appears that the current definition
has that property.

However the situation does seem to be confusing.  You should have a
summary in the draft much like the above chart.  Better, once you have
written the chart, people can discuss whether they would like to adjust
the syntax.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Jul 2012 14:16:17 -0400

> BTW, does the mechanism ensure that the negotiated keepalive interval is

Good question. For an INVITE, the downstream neighbor forbidden from 
giving different answers to different responses to the INVITE. I guess 
that is intended to apply to responses from multiple early dialogs. So I 
guess it does mean it is the same for all dialogs.

> context.  From the chart above, it appears that the current definition

The chart above is mine, and is for a postulated change to the draft.
As the draft is currently written the corresponding chart would be:

	rkeep=5          rkeep              rkeep=5
	                 or rkeep=10

	rkeep            rkeep=5            rkeep
			 or rkeep=10

So, you can examine a request/response *pair* and determine the meaning 
of the parameter. But you can't examine a *response* in isolation and 
determine the meaning.

Of course, even with the change you can't do that, because the value 
doesn't need to be in all responses.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Fri, 27 Jul 2012 13:23:31 -0500

> can't be seconds. They then need to be keepalives-per-second. 

Or "Hertz." ;-)

/a

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 27 Jul 2012 14:41:03 -0400

> of the parameter. But you can't examine a *response* in isolation and 

As someone who has spent a lot of time looking at SIP traces, I advise
that we do not define a mechanism in which "rkeep" is either a positive
or a negative response, depending on what the matching request is.
Indeed, there are cases where one can see the response but not the
request...

Dale