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

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

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.

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

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

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

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

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

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

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

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

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

Thanks for your comments!

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 02 Aug 2010 10:58:55 -0400

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

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

> same SIP entity needs to be separately negotiated."

See above.

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.

Well, people manage with session timer. But I don't care very much.

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.

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 2 Aug 2010 19:59:26 +0200

Hi,

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

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

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

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

>> same SIP entity needs to be separately negotiated."

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?

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

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

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

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

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

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

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

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

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

>the use of Flow-Timer, which is optional in outbound, is forbidden in

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

---

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

Hi Paul,

Some proposed new text based on your comment regarding symmetric path. 

-----------------
 
>>>> 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.
>>>>
>>>The generic procedure is described in the first paragraph 
>>>of the section, and it does not talk about flows - it talks 
>>>about registrations.
>>
>>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.
> 
>-----------------
> 
>But, it's still not a duplication of the whole Outbound 
>mechanism. For example, registrar support is still not required.
> 

For section 4.3, I suggest the following text:

	"A SIP entity that has negotiated sending of keep-alives associated with a registration (registration flow if Outbound is used) MUST be prepared to receive 
	SIP messages (requests and responses) associated with the registration from the receiver of the keep-alives on the same IP port:address 
	from where the keep-alives are sent. Likewise, a SIP entity that has negotiated sending of keep-alives associated with a dialog 
	MUST be prepared to receive SIP messages associated with the dialog from the receiver of the keep-alives on the same IP port:address from 
	where the keep-alives are sent."

For section 4.4, I suggest the following text:
	
	"A SIP entity that has negotiated receiving of keep-alives associated with a registration (registration flow if Outbound is used) MUST 
	send SIP messages (requests and responses)  associated with the registration towards the sender of the keep-alives using the IP address:port 
	from where the keep-alives where received. Likewise, a SIP entity that has negotiated receiving of keep-alives associated with a dialog MUST 
	send SIP messages associated with the dialog towards the sender of the keep-alives using the IP address:port from where the keep-alives where received."

Regards,

Christer

---

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

> Some proposed new text based on your comment regarding symmetric path. 

I think the statements you have added below seem reasonable as far as 
they go, but they only go half way. They say nothing about what the 
*recipient* of keepalives must do when sending requests. And I have a 
strong suspicion this is pretty far along toward reinventing -outbound-.

I would like to have comments on this from somebody more intimately 
familiar with -outbound- than I am.

	Thanks,
	Paul

---

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

Hi Paul,

>*recipient* of keepalives must do when sending requests. 

That is meant to be covered by the text I suggetsed for section 4.4. It says that the receiver of keep-alives must send messages towards the sender of those keep-alives using the address and port from where the keep-alives arrived.

>And I have a strong suspicion this is pretty far along toward reinventing -outbound-.

I don't agree. Symmetric routing wasn't invented by Outbound. It is used in NAT scenarios even if you don't use Outbound, in order to ensure that messages pass NATs. 

For example, entities providing NAT traversal using anchoring/latching use symmetric routing.

We also already have mechanisms like rport to request symmetric response routing.

Regards,

Christer

---

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

> That is meant to be covered by the text I suggetsed for section 4.4. It says that the receiver of keep-alives must send messages towards the sender of those keep-alives using the address and port f…

I don't think that is sufficient for TCP. AFAIK it actually has to be on 
the same connection. So for instance, if it attempted to open a new 
connection in the reverse direction to the same address and port, it 
would quite probably fail.

> We also already have mechanisms like rport to request symmetric response routing.

In the case of TCP this comes down to connection reuse, which is covered 
by outbound on the edge, and by the connection-reuse draft elsewhere.

I think you are talking about much the same, unless you are restricting 
to UDP.

	Thanks,
	Paul

---

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

Hi,

>would quite probably fail.

That is true, and at least from my experience that is also how entities providing NAT traversal (with or without outbound) work.

>by outbound on the edge, and by the connection-reuse draft elsewhere.

Yes.

So, there are two options:

1. We say that, for TCP, a connection re-use must be used.
2. We mandate the support of the connection re-use spec (RFC 5923).

I guess the only difference between 1) and 2) is that 2) would require the usage of the "alias" parameter, defined in 5923, while 1) means that support of keep-alive implicitly also indicates support of connection re-use.

Section 6 talks about connection reuse. But, we will most likely have to modify (or even remove) the section, based on above.

>I think you are talking about much the same, unless you are restricting to UDP.

Absolutely not :)

Regards,

Christer

---

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

> I guess the only difference between 1) and 2) is that 2) would require the usage of the "alias" parameter, defined in 5923, while 1) means that support of keep-alive implicitly also indicates suppo…

While rfc5923 allows bidirectional reuse of a TLS connection, it does 
not for a naked TCP connection. In case of TCP you are forced to open a 
separate connection in each direction, which presumably won't work in 
the cases where this draft is interesting.

>> I think you are talking about much the same, unless you are restricting to UDP.

Then perhaps you are talking about something that is impossible.

	Thanks,
	Paul

---

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

Hi,

>the cases where this draft is interesting.

Ok, you are probably right.

>Then perhaps you are talking about something that is impossible.

We simply say that one must re-use the connection, similar to Outbound (and other mechanisms).

Regards,

Christer

---

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

Hi,

Based on the discussion regarding symmetric routing, and some editorial changes, below is some new proposed text for section 4.3:

"A SIP entity that has negotiated sending of keep-alives associated with a registration MUST be prepared to receive, from the receiver of the keep-alives, SIP messages (requests and responses) associated 
with the registration on the same IP port:address from where the keep-alives are sent. If the SIP entity sends the keep-alives over a connection-oriented transport protocol, it MUST be prepared to receive SIP messages associated with the
registration over the same connection. The same rules apply for SIP messages associated with a dialog, if the SIP entity has negotiated sending of keep-alives associated with a dialog."

...and section 4.4:

"A SIP entity that has negotiated receiving of keep-alives associated with a registration MUST send, towards the sender of the keep-alives, SIP messages (requests and responses) associated with the registration 
using the IP address:port from where the keep-alives are received. If the SIP entity receives the keep-alives over a connection-oriented transport protocol, it MUST send SIP messages associated with the
registration over the same connection, rather than creating a new connection. The same rules apply for SIP messages associated with a dialog, if the SIP entity has negotiated receiving of keep-alives associated with a dialog."

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Christer Holmberg [[email-masked]]
Sent: Tuesday, August 03, 2010 7:31 PM
To: Paul Kyzivat
Cc: SIPCORE
Subject: Re: [sipcore] draft-ietf-sipcore-keep-04 - Paul's comments on symmetric path

Hi,

Regards,

Christer
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore