Subject: Re: [sipcore] draft-ietf-sipcore-keep - Peter's comments

From: Christer Holmberg <[email-masked]>
Date: Sun, 1 Aug 2010 21:52:30 +0200

Hi Peter,

>I have read draft-ietf-sipcore-keep in detail for the first time.
>
>I have one questions and some Nits.
>
>Question: 7.3 Should the TRYING (not shown) from P1 to Alice have
>keep=30 in it? What if the 200 OK takes e.g. longer than 30sec and the
>NAT pinhole closes?

It is true that the flow only shows the 200 OK, but the text in section 4.4 responses in general.

I guess we could add some text that points out that the keep value should be sent as soon as possible, as it may take a while before the final response is sent.

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

>Nits
>1. s/Eventhough/Even though/
>
>1.3 "As specified in [RFC5626], usage keep-alives is not implicitly
>negotiated for such flows, why usage needs to be explicitly
>negotiated." Re-phrase?
>
>4.2.1 s/The section/This section/
>
>4.4 para 2. This paragraph is one sentence. I read it many times - I gave up.

Thanks for your comments!

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 3 Aug 2010 13:47:46 +0200

Hi Peter, 

Some proposed new/modified text based on your comments.

>I guess we could add some text that points out that the keep 
>value should be sent as soon as possible, as it may take a 
>while before the final response is sent.

What about the following new text in section 4.4.

	"In the case of an INVITE request, if a SIP entity sends or forwards multiple responses (provisional and final) associated with the 
	request, and it indicates willingness to receive keep-alives, it only needs to insert a "keep" parameter value in one of the responses. The
	SIP entity SHOULD indicate the willingess to receive keep-alives as soon as possible."

--------------
 
>4.4 para 2. This paragraph is one sentence. I read it many 

I tried to make the paragraph more readable. It still contain a long sentence, but please let me know if it's easier to understand now:

	"When a SIP entity creates or receives a response, and the adjacent downstream SIP entity that sent the associated request indicated 
	willingness to send keep-alives, if the SIP entity is willing to receive keep-alives associated with the registration (in case of 
	a REGISTER response), or the dialog (in case of a response to an initial request for a dialog, or a response to a mid-dialog 
	target refresh request), from the adjacent downstream SIP entity it MUST add a parameter value to the "keep" parameter, before sending 
	or forwarding the response. The parameter can contain a recommended keep-alive frequency, or a zero value."

Regards,

Christer

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 3 Aug 2010 08:11:14 -0400

Thanks Christer,

Inline.

>        SIP entity SHOULD indicate the willingess to receive keep-alives as soon as possible."
Sounds good.
-
>        or forwarding the response. The parameter can contain a recommended keep-alive frequency, or a zero value."
Better - but I am still getting a stack overflow since I parse
"When... A or B ..and...if..or.."

How about:

If a request from a downstream SIP element indicated support for
keep-alives and the upstream element also supports keep-alives then
the response from the upstream element MUST contain a parameter value
for the "keep". This value can contain a recommended keep-alive value
or a zero value.

(I have cut out the stuff on what kind of request it is - I am not
sure if this distinction was vital?)

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 3 Aug 2010 14:52:53 +0200

Hi, 

>>I tried to make the paragraph more readable. It still 
>>contain a long sentence, but please let me know if it's 
>>easier to understand now:
>>
>>        "When a SIP entity creates or receives a response, and the 
>>        adjacent downstream SIP entity that sent the associated request 
>>        indicated willingness to send keep-alives, if the SIP entity 
>>        is willing to receive keep-alives associated with the registration 
>>        (in case of a REGISTER response), or the dialog (in case of a 
>>        response to an initial request for a dialog, or a response to a mid-dialog
>>        target refresh request), from the adjacent downstream SIP entity it MUST 
>>        add a parameter value to the "keep" parameter, before sending
>Better - but I am still getting a stack overflow since I parse "When... A or B ..and...if..or.."

You should take a look at some 3GPP specifications :)

>How about:
> 
>If a request from a downstream SIP element indicated support 
>for keep-alives and the upstream element also supports 
>keep-alives then the response from the upstream element MUST 
>contain a parameter value for the "keep". This value can 
>contain a recommended keep-alive value or a zero value.
> 
>(I have cut out the stuff on what kind of request it is - I 
>am not sure if this distinction was vital?)

I think it is important to indicate the "scope" (registration or dialog) for which the entity
Indicates willingess to receive keep-alives.

I guess the "in case of..." parts could be removed.

Also, the "the response from the upstream element" is a little confusing, because it seems to refer to some other entity (the "reference point" in the text is the SIP entity that inserts the value in the keep header). I would like to use "the SIP entity", as elsewhere in the document.

Regards,

Christer

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 3 Aug 2010 09:56:03 -0400

All ok with me.

Thanks,

Peter

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Aug 2010 10:04:06 -0400

at end...

> 	SIP entity SHOULD indicate the willingess to receive keep-alives as soon as possible."

You really need to consider reliable and unreliable provisionals separately.

Either restrict to reliable responses (provisional or final), or else 
allow in unreliable provisionals preceding a reliable response. (Which 
might get it going sooner.)

As we have seen with o/a, allowing in unreliable provisionals introduces 
complications, especially when changing values are used.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 3 Aug 2010 17:15:42 +0200

Hi Paul,

>complications, especially when changing values are used.

You are right. I was thinking about that, but must have forgot when I put the text together...

The text should say that the parameter needs to be inserted in at least one response that is sent reliably. I see no reason to forbid to, in addition, also include it in unreliable responses.

So, something like:

       "In the case of an INVITE request, if a SIP entity sends or forwards multiple responses (provisional and final) associated with the
       request, and it indicates willingness to receive keep-alives, it only needs to insert a "keep" parameter value in one response that is sent 
       reliably. The SIP entity MAY insert the parameter value also in other responses (relaible and unreliable) associated with the request. 
      The SIP entity SHOULD indicate the willingess to receive keep-alives as soon as possible."

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Aug 2010 11:40:55 -0400

at end

>       The SIP entity SHOULD indicate the willingess to receive keep-alives as soon as possible."

You have to be very careful with the wording here.
(Speaking after bad experience with o/a.) The above doesn't say that the 
value must be the same if sent more than once, or what should happen if 
it is not the same. How about:

"A SIP entity receiving an initial INVITE request and wishing to 
indicate a willingness to receive keep-alives, MUST insert a "keep" 
parameter value in one reliable response to the INVITE. The SIP entity 
MAY insert an identical "keep" parameter value in other responses to the 
same INVITE. The SIP entity MUST NOT insert "keep" parameters with 
differing values in responses to a single INVITE. The SIP entity SHOULD 
indicate the willingness to receive keep-alives as soon as possible."

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 3 Aug 2010 18:00:06 +0200

Hi,

>indicate the willingness to receive keep-alives as soon as possible."

Looks good. I did some editorial changes, to allign with the style in the rest of the documents. I also changed the text a little, to make sure it doesn't look like an INVITE response is the only way of indicating willingess to receive keep-alives.

Also, I removed "initial", because the negotion could take place in a target refresh re-INVITE (assuming no negotiation has taken place before that).

How about:

"When a SIP entity indicates willingness to receive keep-alives in a response to an INVITE request, it MUST insert a "keep" parameter in one reliable response to the INVITE.
The SIP entity MAY insert an identical "keep" parameter value in other responses to the same INVITE. The SIP entity MUST NOT insert "keep" parameters with
differing values in responses to a single INVITE. The SIP entity SHOULD indicate the willingness to receive keep-alives as soon as possible."

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Aug 2010 12:12:03 -0400

Christer,

This text seems ok to me, though I haven't evaluated it in the context 
of the draft as a whole. We'll see how it all comes together.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 3 Aug 2010 18:13:51 +0200

Hi,

>of the draft as a whole. We'll see how it all comes together.

Sure. I will put together a new version as soon as we seem to have a common view on the principles. It is then easier to do the editorial stuff once we have everything on the table.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 Aug 2010 18:31:55 -0400

Christer,

[speaking as individual]

I have reviewed the new version. The change in use of upstream and 
downstream has worked out well - it now seems understandable and not 
upside down. *Except* I think you missed changing one place - in 1.1:

    In some cases a User Agent Client (UAC) does not register itself
    before it establishes a session, but in order to maintain NAT
    bindings open during the session it still needs to be able to
    negotiate sending of keep-alives towards its adjacent upstream SIP
    entity.  A typical example is an emergency call, where a registration
    is not always required in order to make the call.

In that "upstream" should be "donwstream".

But I still think there are problems with the rules for routing messages 
so as to take advantage of the keep-alives while avoiding doing anything 
improper.

The intro lists three cases, but I think two of them (1.1 and 1.3) are 
describing the same situation. So we get two cases from there:

WITH-OUTBOUND:
   no register, dialog establishing request, outbound *is* in use.
   There is need of negotiating keep-alive use that isn't negotiated
   as part of outbound

WITHOUT-OUTBOUND:
   outbound is not supported and so not used, but keep-alives still
   desired. Includes both REGISTER and Dialog-establishing sub-cases.

In the WITH-OUTBOUND case:

outbound results in the negotiation of keep-alives on the last hop to 
the UA. So IIUC, the use of keep is to negotiate keep-alives on other 
hops along the path. 5626 specifies the procedures for selecting/reusing 
the flow for subsequent requests in dialog for the hop it is concerned 
with. It does not do so for any other hop. keep-05 has text added to 4.4 
for this case, but I don't think it is right.

This is a case that could be covered, in part, by 5923 (connect-reuse). 
In the TLS case where 5923 allows bidirectional use of a connection, the 
keep-alive mechanism is complementary. But that is no good for TCP or 
UDP. The security concerns that prevented 5923 from permitting 
bidirectional use of TCP are also reasons it can't in general be used here.

It should arguably be ok to use TCP and UDP bidirectionally here as long 
as the usage is restricted to in-dialog requests. But its going to take 
some additional text to limit it this way and explain the reason that 
security is not compromised.

In the WITHOUT-OUTBOUND case:

You can't fall back on outbound to give any guidance on when to use a 
flow and when not.

In the dialog-establishing case, the rules that apply to the non-last 
hops in the WITH-OUTBOUND case should also apply here, even to the last hop.

In the REGISTER case it gets harder. The problem is that you want to 
support new outbound out-of-dialog requests. If you have a TLS 
connection, then 5923 tells you when you can do it. Without that, the 
reuse of the flow must be tied to the registration in some way. I know 
you want this for IMS which has its own form of secure connection. But 
you are going to have to find some way to specify it here that will 
survive security considerations scrutiny. I don't know what that might be.

In any case, I suspect you need to reinstate the references to 5923 to 
make this all work.

I'm still hoping to get comments from an outbound expert here. They 
might be able to put all this stuff in context better than I can.

	Thanks,
	Paul

Christer Holmberg wrote:
> (Private)
> 
> Hi,
> 
> Based on your WGLC comments/discussions, I have put together a new version draft.
> 
> It can be found at:
> 
> http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-keep-05pre.txt
> 
> Please check whether your issues have been addressed.
> 
> Please note that I have now "switched" downstream and upstream, and suggested definition text for those.
> 
> Please also note that I for now have removed section 6, regarding overlapping with the connect-reuse spec.
> 
> Regards,
> 
> Christer