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

[Paul Kyzivat <[e-mail]>]

(Just to be clear, all of these comments of mine are as an individual)

Christer Holmberg wrote:
> Hi Paul,
> 
>> I finally got around to reading the keep draftfor the first time in
>> quite awhile. I have a few comments and questions:
>>
>> 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".

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

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.

>>   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.

> -----------------
> 
>> 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.

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

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 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.

> -----------------
> 
>> 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.

> -----------------
> 
>> 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?)

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?

	Thanks,
	Paul