Re: [sipcore] draft-ietf-sipcore-keep-04 - Paul's comments

[Christer Holmberg <[e-mail]>]

Hi,

>>>IMO the usage of "upstream" and "downstream" (which is ubiquitous) is
>>>confusing, because its not evident which is the high ground and which is
>>>the low ground. Normally for SIP I would assume that the sender of a
>>>request is on the high ground, with the request flowing *downstream*
>>>toward the recipient, and the response flowing *upstream* toward the
>>>sender of the request. But most of the text in this draft assumes the
>>>opposite. Perhaps this stems from a view that the "device" is on the low
>>>ground and the registrar is on the high ground. But then 4.1 further
>>>complicates this:
>>
>>After a first thought I probably agree with your comment that the request flows *downstream*.
>>
>>I guess I could add some clarification text, to make it clear that "adjacent downstream" refers to the 
>>adjacent SIP node in which a request is sent.
>
>I see three possible ways to clean this up:
>
>1) exchange "upstream" and "downstream" throughout the document.
>    Also include the explanation about what "downstream" means.
>
>2) Reword the text throughout the document to *eliminate* the use of
>    "upstream" and "downstream".

I discussed a lot with John Elwell about the wording, to avoid having to frequently repeat long sentences etc.

So, if we are to eliminate the usage I would like to see a proposal on how to do it.

>3) Leave the use of upstream and downstream as is, but add a very
>    explicit specification of what it means in this document.

If the usage of upstream and downstream is not alligned with the normal meaning (as you suggested), I definately think we shall change it.

>Of those, I find (1) or (2) to be equally acceptable. But (3) seems a
>poor choice to me - even though it will be internally consistent I think
>it will confuse people due to conflict with typical usage.

I agree.

Let me try to add put together some clarification text (your proposal 1), and see whether it makes things more clear.

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

>>>   NOTE: Usage of keep-alives is negotiated per direction.  If a SIP
>>>   entity has indicated willingness to receive keep-alives from its
>>>   adjacent downstream SIP entity, sending of keep-alives towards the
>>>   same SIP entity needs to be separately negotiated.
>>>
>>> If that negotiation were performed following the procedures in this
>>> draft then the upstream and dowstream roles would be reversed.
>>
>> I guess the note could be re-written without the "downstream" wording:
>>
>> "NOTE: Usage of keep-alives is negotiated per direction.  If a SIP
>> entity has indicated willingness to receive keep-alives from an
>> adjacent SIP entity, sending of keep-alives towards the
>> same SIP entity needs to be separately negotiated."
>
>See above.

Note that the new note text does not use "downstream" or "upstream" wording, so I don't think it's dependent on the above issue?

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

>>> Section 4.2.2:
>>>
>>> IIUC, the keepalive is associated with a flow as defined in 5626. Hence
>>> it isn't appropriate to use this negotiation mechanism on a registration
>>> that doesn't specify a flow. I don't see that stated anywhere.
>>>
>>> (If there was no flow, what would the keepalive state be associated *with*?)
>>
>>The second paragraph describes the case when outbound is used, and when you do have flows.
>>
>>The generic procedure is described in the first paragraph of the section, and it does not talk about flows - it talks about registrations.
>
>I don't see how that works (in the non-outbound case):
>
>The purpose of these keepalives is to keep a nat binding open.
>But that is only useful if the neighboring node then uses that path to
>send outbound requests. What is there in the keep draft that even
>*talks* about that?
>
>If the keepalives are sent via TCP, then the neighbor will have to use
>that same TCP connection for outbound requests in order to gain any
>benefit from the keepalive. If the keepalives are send via UDP, then the
>neighbor will have to send requests symmetrically from the address/port
>on which the keepalives are received.

That's a good point.

I have probably been assuming that the symmetric path usage is part of the keep-alive mechanism itself, defined in outbound, so there is no need to repeat that.

But, I guess that it is actually part of the outbound mechanism, so we would need to say that it applies also to entities that are willing to send and/or receive keep-alives.

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

>If you were to specify that, wouldn't it begin to duplicate outbound?

It would duplicate that specific requirement of Outbound, yes.

But, it's still not a duplication of the whole Outbound mechanism. For example, registrar support is still not required.

And, the keep mechanism can be used between any two SIP entities.

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

>Note that this issue exists for use of keep in dialogs too. The dialog
>doesn't nail down a connection to be used for the life of the dialog,
>yet the keepalive mechanism seems to assume it does. For instance, small
>messages may be sent via UDP and large ones via TCP. I think there is an
>unstated assumption here that the use of keepalives binds the dialog to
>a connection. Something needs to be said about how that is supposed to work.

Section 13 of Outbound says that one would need to establish both UDP and TCP flows, but that in most cases it
would make more sense to only use TCP. Maybe we could refer to that text?

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

>>>Section 4.2.3:
>>>
>>>Is there a reason *why* you can't renegotiate the dialog to eliminate
>>>the use of keepalives? (session timers are a similar concept, and they
>>>are renegotiated on/off with every reINVITE/UPDATE.)
>>>
>>>(Maybe there is a good reason - I just don't see it.)
>>
>>People thought that we shouldn't make things too complicated and heavy by allowing mid-dialog renegotiations - and especially not *mandating* a renegotiation with every reINVITE/UPDATE.
>
>Well, people manage with session timer. But I don't care very much.

I still think the conecpt of session timer and keep alive is a little different. In addition, reINVITE/UPDATE is a central part of the session timer mechanism itself, while for keep they are only used for the negotiation.

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

>>> Section 4.3:
>>>
>>> The following:
>>>
>>>    When a SIP entity is about to send a keep-alive, if the SIP entity at
>>>    the same time is also about to send or forward a SIP request
>>>    associated with the same registration or dialog, for which the keep-
>>>    alive is to be sent, the SIP entity MAY choose not to send the keep-
>>>    alive, as the SIP request will perform the same keep-alive action.
>>>
>>> seems pretty imprecise. Wouldn't it be more precise to state that every
>>> request sent resets the clock for when a keep-alive needs to be sent?
>>
>> I can use such wording instead, if people think it's better.
>>
>>>Also, while this skipping of the explicit keep-alive makes sense to me,
>>>AFAICT it isn't consistent with -outbound-.
>>
>>So, do you suggest that a SIP request should NOT reset the clock?
>
>>OR, would you like some note saying that, when keep-alives are implicilty negotiated as part of outbound, requests do not reset the timer?
>
>As I said, it makes sense to me to only send keepalives with the path
>has been idle. But it disturbs me for the keepalive mechanism, which is
>borrowed from outbound, to diverge from the definition provided by
>outbound. I think this is perhaps a discussion to have with the authors
>of outbound. But I'm inclined to want this to be consistent with
>outbound even if it means sending unnecessary keepalive messages.

My suggestion would be to remove the text, and simply refer to Outbound.

We could then have the discussion with the Outbound authors, but it would not delay the keep draft.

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

>>> Section 5:
>>>
>>> The following has me totally confused:
>>>
>>>   SIP Outbound uses the Flow-Timer header field to indicate the server-
>>>    recommended keep-alive frequency.  However, it will only be sent
>>>    between a UA and an edge proxy.  Using the "keep" parameter, however,
>>>    the sending and receiving of keep-alives might be negotiated between
>>>    multiple entities on the signalling path.  Since the server-
>>>    recommended keep-alive frequency might vary between different SIP
>>>    entities, those would have to re-write the Flow-Timer header field
>>>    value.  In addition, if a SIP entity does not indicate willingness to
>>>    receive keep-alives from its adjacent downstream SIP entity, and
>>>    receives a Flow-Timer header field in a response, it would have to
>>>    remove the Flow-Timer header field from the response.  This issue
>>>    does not exist for the "keep" parameter, as each SIP entity has its
>>>    own individual Via header field.
>>>
>>> (There are too many hypotheticals in it.)
>>>
>>> After reading this, I don't know:
>>>
>>> - can I use keep in conjunction with an outbound registration?
>>
>>I think the draft currently does not explicitly say anything about that, but I think it would be good to add text saying that it is possible.
>>
>>> - if so, does this alter the procedures of outbound - requiring some manipulation of the Flow-Timer value?
>>
>>No. The usage of Flow-Timer with outbound is optional, so saying that it MUST NOT be used if the draft mechanism is not used does not break anything, in my opinion.
>
>So, you are saying that this may be used in conjunction with outbound,
>but then there is a *limitation* on how outbound is implemented? (That
>the use of Flow-Timer, which is optional in outbound, is forbidden in
>certain circumstances?)

Another option would be to say that, if the Flow-Timer is used (because of Outbound) the keep parameter value MUST be identical to the Flow-Timer value.

That would put no restrictions on Outbound, because it does not say anything about whether to use Flow-Timer or not.

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

>I'm still very confused over exactly what you are trying to say. And I
>note that there are no normative statements in that text. I can't even
>begin to suggest an alternative wording for this paragraph. Can you try
>again to word it so I understand? Or keep trying to explain it to me so
>I can suggest something that doesn't confuse me?

The possibility to use keep in conjunction with registration initiated Outbound flows does need normative text - no matter how we re-write the note - so I will try to come up with something :)

The purpose of the note it to simply describe why the Flow-Timer header is not used with the keep mechanism. 

Regards,

Christer