Subject: [sipcore] Draft new version: draft-ietf-sipcore-keep-03

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 May 2010 18:55:57 +0200

Hi,

I've submitted a new version of the keep draft.

Based on feedback and comments, I've moved back to the original Via parameter based solution.

I've done a number of editorial changes in order to make the draft more clear.

The currently only OPEN ISSUE is whether we should use the Flow-Timer header field, defined in Outbound, to indicate the keep-alive frequency, or whether the frequency should be added directly to the Via parameter as a parameter value (instead of adding a "yes" value).

Using Flow-Timer is alligned with Outbound, while using a keep parameter value is more "compact".

Flow-Timer example:   'Flow-Timer: 30'

Via keep parameter example: Via:11.22.33.44;keep=30

The keep-draft allows usage of the Flow-Timer header field also in initial requests for dialogs, and mid-dialog target refresh requests, but I did not find any text in the Outbound spec which would restrict the usage of the header field to REGISTER requests only.

Once we've agreed on how to move forward with the keep-alive frequency issue I believe the draft is ready for WGLC.

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 25 May 2010 10:33:51 +0200

Christer,

Thanks, this addresses concerns I had with the previous version.

Digging deeper into the issue with the Flow-Timer header field, I view it this way. The "keep" parameter is in the Via header field, which has one entry per hop over which the request passes. Therefore the "keep" parameter is clearly associated with a given hop. However, the Flow-Timer header field does not have the concept of one entry per hop. Therefore the header field is assumed to apply only to the current hop, and has to be removed before forwarding a response over a hop on which keep-alive has not been requested, or needs to have its value modified before forwarding a response over a hop on which keep-alive has been requested. It seems odd that the two pieces of information used by this feature should be handled in two completely different ways.

Another difference is that when a proxy receives a "keep" parameter in the topmost Via header field entry, it adds "yes" as the value of that parameter when forwarding that Via header entry (which will no longer be the topmost entry and therefore will not be inspected by the next entity). Therefore when the Via header field is returned in the response, it will already have the "yes" value in place when it crosses the hop to which the entry applies. Therefore the proxy does not need to take special action concerning the Via header field when forwarding the response. In contrast, a proxy has to take special action with the Flow-Timer header field when forwarding a response, as described above. The way "keep" is handled seems to take account of transaction-stateless proxies, whereas the way Flow-Timer is handle does not. I am not sure, however, whether this mechanism makes sense for use with transaction-stateless proxies anyway, so perhaps this latter point is moot.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 24 May 2010 17:56
> To: SIPCORE
> Subject: [sipcore] Draft new version: draft-ietf-sipcore-keep-03
> 
> Hi,
> 
> The currently only OPEN ISSUE is whether we should use the 
> Flow-Timer header field, defined in Outbound, to indicate the 
> keep-alive frequency, or whether the frequency should be 
> added directly to the Via parameter as a parameter value 
> (instead of adding a "yes" value).
> 
> The keep-draft allows usage of the Flow-Timer header field 
> also in initial requests for dialogs, and mid-dialog target 
> refresh requests, but I did not find any text in the Outbound 
> spec which would restrict the usage of the header field to 
> REGISTER requests only.
> 
> Once we've agreed on how to move forward with the keep-alive 
> frequency issue I believe the draft is ready for WGLC.
> 
> Regards,
> 
> Christer
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 May 2010 11:36:11 +0200

Hi John,

>Digging deeper into the issue with the Flow-Timer header field, I view it this way. The "keep" parameter is in the Via header field, which has one entry per hop over which the request passes. Therefore the "keep" parameter is clearly associated with a given hop. However, 
>the Flow-Timer header field does not have the concept of one entry per hop. Therefore the header field is assumed to apply only to the current hop, and has to be removed before forwarding a response over a hop on which keep-alive has not been requested, or needs to 
>have its value modified before forwarding a response over a hop on which keep-alive has been requested. 

True. 

Of course, in Outbound that is not a problem, since Flow-Timer is only used on one hop (between the UA and its edge proxy).

>It seems odd that the two pieces of information used by this feature should be handled in two completely different ways.
>
>Another difference is that when a proxy receives a "keep" parameter in the topmost Via header field entry, it adds "yes" as the value of that parameter when forwarding that Via header entry (which will no longer be the topmost entry and therefore will not be inspected by 
>the next entity). Therefore when the Via header field is returned in the response, it will already have the "yes" value in place when it crosses the hop to which the entry applies. Therefore the proxy does not need to take special action concerning the Via header field when 
>forwarding the response. In contrast, a proxy has to take special action with the Flow-Timer header field when forwarding a response, as described above. The way "keep" is handled seems to take account of transaction-stateless proxies, whereas the way Flow-Timer is 
>handle does not. I am not sure, however, whether this mechanism makes sense for use with transaction-stateless proxies anyway, so perhaps this latter point is moot.

I think that proxies do need to be stateful - at least if they intend to send keep-alives within a dialog (I doubt a proxy would negotiate sending of proxies within a registration, since proxies are normally registration un-aware). Because, the proxy needs to know when the dialog is terminated, in order to stop sending the keep-alives.

Also, a proxy that receives keep-alives also needs to be stateful in case it intends to perform some actions in case negotiated keep-alives aren't received within a dialog. The draft (nor Outbound, afaik) defines what a proxy does in those cases, because it is seen as an implementation issue.

As said earlier, the reason for using Flow-Timer in the draft is because Outbound already uses it, and the purpose of the keep-draft is to not change the Outbound keep-alive mechanism as such, but rather define a mechanism to explicitly negotiate usage of it.

But, personally I have no strong preference for which solution we use. However, IF we choose to indicate the frequency as a keep parameter value, I think we should add some text to the draft explaining why Flow-Timer is not used.

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 26 May 2010 10:13:15 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Elwell, John
> Sent: Tuesday, May 25, 2010 4:34 AM
> 

Same here.
 
> Digging deeper into the issue with the Flow-Timer header field, I view it
> this way. The "keep" parameter is in the Via header field, which has one
> entry per hop over which the request passes. Therefore the "keep"
> parameter is clearly associated with a given hop. However, the Flow-Timer
> header field does not have the concept of one entry per hop. Therefore the
> header field is assumed to apply only to the current hop, and has to be
> removed before forwarding a response over a hop on which keep-alive has
> not been requested, or needs to have its value modified before forwarding
> a response over a hop on which keep-alive has been requested. It seems odd
> that the two pieces of information used by this feature should be handled
> in two completely different ways.

Yes I had the same feeling when reading it - that it's odd/unnatural to do the Flow-Timer header in when it would be simpler to just make it the keep param's value.  But obviously Flow-Timer is used in Outbound, so in some sense it also feels odd to make it different from that.

> Another difference is that when a proxy receives a "keep" parameter in the
> topmost Via header field entry, it adds "yes" as the value of that
> parameter when forwarding that Via header entry (which will no longer be
> the topmost entry and therefore will not be inspected by the next entity).
> Therefore when the Via header field is returned in the response, it will
> already have the "yes" value in place when it crosses the hop to which the
> entry applies. Therefore the proxy does not need to take special action
> concerning the Via header field when forwarding the response. In contrast,
> a proxy has to take special action with the Flow-Timer header field when
> forwarding a response, as described above. The way "keep" is handled seems
> to take account of transaction-stateless proxies, whereas the way Flow-
> Timer is handle does not. I am not sure, however, whether this mechanism
> makes sense for use with transaction-stateless proxies anyway, so perhaps
> this latter point is moot.

We shouldn't disallow stateless proxies from doing it, but yeah it's not the "normal" case.

Regardless, I'm not sure why the Proxy inserts the keep in the forwarded Request, instead of just in the response(s)?

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 May 2010 16:24:21 +0200

Hi,

>>Thanks, this addresses concerns I had with the previous version.

Great!

>Yes I had the same feeling when reading it - that it's odd/unnatural to do the Flow-Timer header in when it would be simpler to just make it the keep param's value.  But obviously Flow-Timer is used…

So, we just need to pick one alternative :)

Keep is leading 1 - 0.

>Regardless, I'm not sure why the Proxy inserts the keep in the forwarded Request, instead of just in the response(s)?

In case it wants to indicate to ITS adjacent upstream entity (maybe another proxy) that it is willing to send-keep alives. There may not be many use-cases (someone mentioned a PBX connection point acting as a proxy), but there is no reason to forbid it. UAs and proxies can use the same procedures.

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 26 May 2010 10:40:18 -0400

Hi Christer,
I like this version a lot more. :)

Technical comments/questions:

1) Why does the Proxy insert the keep in the forwarded Request, vs. just the response(s)?

2) You note that a keep=yes in any response to a request means the next-hop can handle keep.  Does this mean a Proxy can send it in a 100 Trying?  If so (and I assume it should be so), then the Proxy really needs to add the "yes" to responses, not forwarded requests I think.

3) You use the phrase "within a registration" a lot.  I assume this means for the lifetime of the Registration binding (as opposed to say the duration of the REGISTER transaction, between the request and final response).  So does this mean that a REGISTER refresh (i.e., same call-id) does or does not re-negotiate keep?  I think it must, since a real Proxy doesn't really know whether a REGISTER is a refresh vs. a new one.

4) Section 4.2.1 states:
   "The scope of the negotiated keep-alives depends on what SIP request methods are used for the keep-alive negotiation."
I don't think you want to make it method-specific in the draft, except for maybe REGISTER.  But other than REGISTER, any dialog-forming or in-dialog request affects the keep for the duration of the dialog.  Any out-of-dialog, non-dialog-forming Request other than REGISTER would presumably have no impact.  I mention this because an out-of-dialog MESSAGE or PUBLISH would have no bearing on keep I guess, but those same methods in-dialog could negotiate keep (as I read the current text in the draft).

5) Section 4.2.1 states:
   "The sending and receiving of keep-alives can be negotiated when a
   registration or dialog is initiated, or later during the registration
   or dialog.  However, once a SIP entity has negotiated the sending of
   keep-alives within a registration or dialog, it can not re-negotiate
   the sending of keep-alives within the same registration or dialog.
   Likewise, once a SIP entity has indicated willingness to receive
   keep-alives within a registration or dialog, it MUST NOT indicate
   willingness to receive keep-alives in a response to a subsequent
   request within that registration or dialog."
Why is there that last sentence's restriction?  

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 26 May 2010 10:45:49 -0400

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Wednesday, May 26, 2010 10:24 AM
> To: Hadriel Kaplan; Elwell, John; SIPCORE
> >
> >Regardless, I'm not sure why the Proxy inserts the keep in the forwarded
> Request, instead of just in the response(s)?
> 
> In case it wants to indicate to ITS adjacent upstream entity (maybe
> another proxy) that it is willing to send-keep alives. There may not be
> many use-cases (someone mentioned a PBX connection point acting as a
> proxy), but there is no reason to forbid it. UAs and proxies can use the
> same procedures.

Yeah I was worried you'd say that. :)

I think that's a dangerous assumption.  The Proxy may not be able to support keep-alive on that Proxy-Proxy connection/side, while it can for the UA-Proxy side.  Believing some lower Via isn't safe.

What should really happen is the Proxy should add a keep param (without "yes") in ITS Via header, so that the downstream Proxy getting it can add a "yes" to that Via, for that connection.  In other words, all the logic should be about top-most Via's.

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 May 2010 17:14:50 +0200

Hi,

>I think that's a dangerous assumption.  The Proxy may not be able to support keep-alive on that Proxy-Proxy connection/side, while it can for the UA-Proxy side.  Believing some lower Via isn't safe.

I am not sure I understand.

If the proxy wants to receive keep-alives on the UA-Proxy side, it inserts a "yes" parameter value (or, the frequency, if we choose that alternative) in the keep paramter inserted by the UA. in its Via parameter

If the proxy wants to send keep-alives towards the next hop proxy, it inserts a keep paramter in its own Via header.

So, there are two different procedures for indicating willingness to send and received.

>What should really happen is the Proxy should add a keep param (without "yes") in ITS Via header, so that the downstream Proxy getting it can add a "yes" to that Via, for that connection.  In other…

That is how it works. If you are willing to receive, you insert "yes" in the Via of the previous hop (if it contains "keep", or course). If you are willing to send, you insert "keep" in your OWN Via.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 May 2010 17:31:07 +0200

Hi,

>1) Why does the Proxy insert the keep in the forwarded Request, vs. just the response(s)?

See my reply to your other mail.

The proxy inserts "keep" in itw own Via to indicate willingess to SEND keep-alives towards the adjacent upstream hop.

The proxy inserts "=yes" in the Via of the adjacent downstream hop to indiciate willingness to RECEIVE keep-alives from that hop.

>2) You note that a keep=yes in any response to a request means the next-hop can handle keep.  Does this mean a Proxy can send it in a 100 Trying?  If so (and I assume it should be so), then the Prox…

That's a good point. We can change that.

The only reason it currently adds "=yes" to the request is because I thought it is alligned with the received parameter. There is really no technical reason to do so, because it is the adjacent downstream entity that needs the information.

>3) You use the phrase "within a registration" a lot.  I assume this means for the lifetime of the Registration binding (as opposed to say the duration of the REGISTER transaction, between the request and final response).

Correct.

>So does this mean that a REGISTER refresh (i.e., same call-id) does or does not re-negotiate keep?  I think it must, since a real Proxy doesn't really know whether a REGISTER is a refresh vs. a new one.

That's a good point. I will think a little about it, but if you're right the keep-alive would have to be re-negotiated in registration refreshes. 

That should not be a big problem, though, as registration re-refreshes don't happen that occur (especially since one will not have to use them for keep-alives anymore).

>I don't think you want to make it method-specific in the draft, except for maybe REGISTER.  But other than REGISTER, any dialog-forming or in-dialog request affects the keep for the duration of the dialog.

The text DO talk about initial requests for dialogs, and mid-dialog target refresh requests. It does not talk about methods for dialog keep-alives. So, the text you refer to probably needs to be modified. Maybe it should say "what type of SIP requests are used for...".

>Any out-of-dialog, non-dialog-forming Request other than REGISTER would presumably have no impact.  I mention this because an out-of-dialog MESSAGE or PUBLISH would have no bearing on keep I guess, but those same methods in-dialog could negotiate keep (as I read the current text in the draft).

Correct. It would probably be good to mention that also.

>   Why is there that last sentence's restriction?

Maybe we don't need the sentence, becuase it should not receive a keep paramter within the dialog in the first place.

Based on your previous comment about proxies not knowing whether a REGISTER is a refresh or not, for registrations we probably need to say that it MUST indicate willingness to receive also for registration refreshes.

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 26 May 2010 11:33:43 -0400

Ahh, sorry for the confusion.  It occurs to me I didn't ask the question correctly the first time, which resulted in us talking about different things.

In the current draft, I believe that a Proxy inserts the "yes" value for the keep of the Via it receives from the UA, in the *forwarded request* it sends onwards.  My question is why is that done, instead of just inserting "yes" in the response(s).

In other words, why is this done:
     Alice                        P1                      REGISTRAR
       |                          |                           |
       |--- REGISTER------------->|                           |
       |    Via: UAC;keep         |                           |
       |                          |--- REGISTER-------------->|
       |                          |    Via: P1;keep           |
       |                          |    Via: UAC;keep=yes      |
       |                          |                           |
       |                          |<-- 200 OK ----------------|
       |                          |    Via: P1;keep=yes       |
       |                          |    Via: UAC;keep=yes      |
       |<-- 200 OK ---------------|                           |
       |    Via: UAC;keep=yes     |                           |
       |    Flow-Timer: 30        |                           |

Instead of this:
     Alice                        P1                      REGISTRAR
       |                          |                           |
       |--- REGISTER------------->|                           |
       |    Via: UAC;keep         |                           |
       |                          |--- REGISTER-------------->|
       |                          |    Via: P1;keep           |
       |                          |    Via: UAC;keep          |
       |                          |                           |
       |                          |<-- 200 OK ----------------|
       |                          |    Via: P1;keep=yes       |
       |                          |    Via: UAC;keep          |
       |<-- 200 OK ---------------|                           |
       |    Via: UAC;keep=yes     |                           |
       |    Flow-Timer: 30        |                           |

> Sent: Wednesday, May 26, 2010 11:15 AM
> Subject: RE: Draft new version: draft-ietf-sipcore-keep-03
> 
> Hi,
> 
> >I think that's a dangerous assumption.  The Proxy may not be able to
> support keep-alive on that Proxy-Proxy connection/side, while it can for
> the UA-Proxy side.  Believing some lower Via isn't safe.
> 
> If the proxy wants to receive keep-alives on the UA-Proxy side, it inserts
> a "yes" parameter value (or, the frequency, if we choose that alternative)
> in the keep paramter inserted by the UA. in its Via parameter
> 
> If the proxy wants to send keep-alives towards the next hop proxy, it
> inserts a keep paramter in its own Via header.
> 
> >What should really happen is the Proxy should add a keep param (without
> "yes") in ITS Via header, so that the downstream Proxy getting it can add
> a "yes" to that Via, for that connection.  In other words, all the logic
> should be about top-most Via's.
> 
> That is how it works. If you are willing to receive, you insert "yes" in
> the Via of the previous hop (if it contains "keep", or course). If you are
> willing to send, you insert "keep" in your OWN Via.
> 
> Regards,
> 
> Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 May 2010 20:38:54 +0200

Hi,

>In the current draft, I believe that a Proxy inserts the "yes" value for the keep of the Via it receives from the UA, in the *forwarded request* it sends onwards.  My question is why is that done, i…

As I said earlier, I can insert it in the response. It doesn't need to be in the request. I just thought that since the proxy anyway might insert the received parameter in the request, it could as well insert "=yes" at the same time.

But, if it confuses readers of the draft we can change it, and specify that "=yes" is inserted in the response. It would work even for transaction stateless proxies, since the "keep" parameter of the UA will be in the response.

Regards,

Christer

Instead of this:
     Alice                        P1                      REGISTRAR
       |                          |                           |

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 May 2010 19:25:29 +0200

Hi,

Based on the feedback and comments, I intend to produce a new version of the keep draft, with the following changes:

1. Instead of using the Flow-Timer header field, the server recommended keep-alive frequency is inserted as keep parameter value (instead of "yes").

2. If an entity wants to receive keep-alives, it will add the keep parameter value (instead of "yes") in the response, instead of the request. It does not need to be in the request, and it seems to confuse the reader of the draft.

3. The text will say that, when negotiated with REGISTER, the keep-alives are sent until a registration refresh is performed, when the keep-alives needs to be negotiated again (if the sender still wants to send them). The reason is that it cannot be assumed that a proxy knows whether a REGISTER is for a new registration, or for a registration refresh.

4. The example flows will be updated to reflect the changes above.

5. Editorial changes.

After that, I intend to ask the chairs to initiate WGLC.

Regards,

Christer