Subject: RE: [Sip] Impossible to use real persistent connection with sip

From: "Colasanto, Eric (Eric)" <[email-masked]>
Date: Thu, 6 Feb 2003 08:50:55 -0500

I think a new parameter will work well to specify the creation of a persistent socket.
;pc=0 when the socket is NOT persistent, or don't include this parameter.
;pc=1 when the socket is persistent.

After setting up this socket will all subsequent SIP messages be required to have the pc=1
to utilize the persistent socket. Or will any SIP message destined for an endpoint supported by a
persistent socket utilize the socket, reguardless of the presence of the pc parameter?

Then there is the issue of when/how does one destroy the persistent connection(s).
Should this be left to the application/user which is controlling the generation/consumption of
the SIP messages?

Eric J. Colasanto 
(508) 862-3386 

-----Original Message-----
From: James Ford [mailto:[email-masked]]
Sent: Thursday, February 06, 2003 2:17 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [Sip] Impossible to use real persistent connection with sip

An even simpler solution will be to add a parameter to the Via header such 
as
pc; (or pc=1 so that we will not have troubles with Microsoft). Pc stands 
for persistent connection.

Guys, what do I need to do to move on this thing so that we will have a new 
draft to solve the problem?
I think many implementations will be interested in using a real persistent 
connection especially when TLS will be more deployed.

Thanks,
James S. Ford

>From: "Jain, Rajnish (Rajnish)" <[email-masked]>
>To: "'James Ford'" <[email-masked]>, [email-masked]
>CC: "Colasanto, Eric (Eric)" <[email-masked]>,   "Gurbani, Vijay K 
>(Vijay)" <[email-masked]>
>Subject: RE: [Sip] Impossible to use real persistent connection with sip
>Date: Tue, 4 Feb 2003 07:20:22 -0500
>
>James,
>
>The option of adding a SIP header field seems to be more flexible. That 
>way,
>when that header field is not present, the persistent connection is jointly
>owned by both UAs. And at their discretion they can close it. This allows 
>us
>to be backward compatible while enabling a new capability.
>
>Thanks,
>Rajnish
>
>-----Original Message-----
>From: James Ford [mailto:[email-masked]]
>Sent: Tuesday, February 04, 2003 2:45 AM
>To: [email-masked]
>Subject: [Sip] Impossible to use real persistent connection with sip
>
>
>Hi,
>The SIP standard does not specify who is responsible for closing TCP
>connections. This means that both client and server transaction can close
>the connection. A reasonable implementation for a transaction will be to
>close any open connection (incoming or outgoing) before termination in 
>order
>to free unused resources.
>This behavior actually makes it impossible to count on a persistent
>connection.
>For example, A UA that is always talking to the same destination using TLS
>will want to use one connection per day. This is impossible since the 
>server
>might close the connection as soon as the first transaction terminates.
>
>I can see several ways to solve this problem:
>1.	Specify that the UA that opened the connection will be responsible for
>closing it.
>2.	Add a header to sip requests that asks the server not to close the
>connection by itself.
>
>What do you think?
>James S Ford.
>
>
>
>
>
>
>_________________________________________________________________
>Add photos to your e-mail with MSN 8. Get 2 months FREE*.
>http://join.msn.com/?page=features/featuredemail
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use [email-masked] for questions on current sip
>Use [email-masked] for new developments on the application of sip

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Cullen Jennings" <[email-masked]>
Date: Sun, 9 Feb 2003 23:27:41 -0800

Just to get a little more precise about this ... what does persistence mean?
For the length of the transaction? For the dialog? As long as the
registration is valid? Until some box crashes? Until the world moves to
IPv6.

I think this persistent connection question is intertwined with the ideas of
how SIP will do reliability. It's all fine and dandy to add a parameter
allows box A to tell box B that it is not allowed to crash but it is a
little harder for B to make sure it correctly implements this. Even if B is
capable of this sort of HA, it might want to close the connection for
administrative reasons such as getting new keying material on a TLS
connection.

I would be very happy to see some good thought on when devices should close
a TCP socket - I think that figuring out a good algorithm and understanding
the large scale consequences is going to be surprisingly complicated.

Cullen

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Colasanto, Eric (Eric)
> Sent: Thursday, February 06, 2003 5:51 AM
> To: 'James Ford'; Jain, Rajnish (Rajnish); [email-masked]
> Cc: Colasanto, Eric (Eric); Gurbani, Vijay K (Vijay)

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 10 Feb 2003 10:21:19 -0600

Cullen Jennings wrote:
> Just to get a little more precise about this ... what does persistence 
> mean?  For the length of the transaction? For the dialog? As long as
> the registration is valid? Until some box crashes? Until the world moves 
> to IPv6.

Hi Cullen:

Yes, we've grappled with that as well.  Clearly, to get most bang for
the buck, the persistent connection lives beyond the dialog that
established it; i.e. it spans transactions.  One place where such
persistent connections may be used is between a UAC and its default
outbound proxy, or between two proxies that may have a trusted peering
relationship between them for traffic between their domains.

Exactly how to quantify this length of time is tricky.  As you point
out, sometime a peer may go down for administrative reasons, other times
it may simply crash.  Depending on how we specify and implement it,
there may be an expiry time for this connection -- I don't know what the
correct answer is right now.

> I would be very happy to see some good thought on when devices should 
> close a TCP socket - I think that figuring out a good algorithm and 
> understanding the large scale consequences is going to be surprisingly 
> complicated.

We're working on an I-D that extends the connect-reuse ID to outline
some of these issues.  I will post it to the list as soon as I can.  It
contains a lot of what Sarit also outlines below:

Sarit Galanos Mekler ([email-masked]) writes:
> First I would like to say that I think that the pc=1 is a good choice.
> To my opinion adding the pc=1 to the via header is only a recommendation 
> to the server to keep the connection open.

Unfortunately, this is just a hint to the server, and as you point out
below:

> Servers that don't understand pc or don't want to keep the connection 
> open are more then welcome to close it.

But that may be all we need to do.  I don't yet know if it is worthwhile
to go through some negotiation mechanism (i.e. register Require and
Proxy-Require tokens with IANA).  Even it we do go the "pc=1" parameter
route, we should register the "pc" token with IANA.

> A server can also decide that it wishes to keep the connection open only 
> if it is actually being used.  An implementation can for example, set a 
> timer on server connections.   When ever a message is received/sent on
> the connection the timer is reset. when the timer expires the server 
> closes  the connection.

All this presumes that clients and servers are well-behaved.  In the
extreme case, I think that we may rely on I/O failing on a now
unconnected socket because one of the peers crashed or got brought down
for adminstrative reasons.  That is, we proscribe behavior for well-
behaved peers, taking in account extreme cases where one of them
suddenly disappears.

> The persistency level (dialog / transaction) if for the specific 
> application to decide. For dialog persistency the application will have 
> to keep the connection open for the duration of the call.  Using the 
> pc=1 parameter will give a good chance for using connections for more 
> then one transaction. An option that today (almost) does not exist.

Right.

Cheers,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

---

From: "Cullen Jennings" <[email-masked]>
Date: Mon, 10 Feb 2003 10:03:31 -0800

I look forward to reading the draft. I have been hoping someone would
write some advice to implementers on when to close connection. 

I initially did not understand that pc was meant to be a hint - I'm way
more comfortable with a hint than with anything that assumes a
reliability model beyond what SIP already has specified.

Cullen

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Vijay K. Gurbani
> Sent: Monday, February 10, 2003 8:21 AM
> To: Cullen Jennings
> Cc: Colasanto, Eric (Eric); 'James Ford'; Jain, Rajnish 
> (Rajnish); [email-masked]; Sarit Galanos Mekler
> Subject: Re: [Sip] Impossible to use real persistent 
> connection with sip
> 
> 
> Cullen Jennings wrote:
> Yes, we've grappled with that as well.  Clearly, to get most 
> bang for the buck, the persistent connection lives beyond the 
> dialog that established it; i.e. it spans transactions.  One 
> place where such persistent connections may be used is 
> between a UAC and its default outbound proxy, or between two 
> proxies that may have a trusted peering relationship between 
> them for traffic between their domains.
> 
> Exactly how to quantify this length of time is tricky.  As 
> you point out, sometime a peer may go down for administrative 
> reasons, other times it may simply crash.  Depending on how 
> we specify and implement it, there may be an expiry time for 
> this connection -- I don't know what the correct answer is right now.
> 
> We're working on an I-D that extends the connect-reuse ID to 
> outline some of these issues.  I will post it to the list as 
> soon as I can.  It contains a lot of what Sarit also outlines below:
> 
> > To my opinion adding the pc=1 to the via header is only a 
> > recommendation to the server to keep the connection open.
> 
> But that may be all we need to do.  I don't yet know if it is 
> worthwhile to go through some negotiation mechanism (i.e. 
> register Require and Proxy-Require tokens with IANA).  Even 
> it we do go the "pc=1" parameter route, we should register 
> the "pc" token with IANA.
> 
> All this presumes that clients and servers are well-behaved.  
> In the extreme case, I think that we may rely on I/O failing 
> on a now unconnected socket because one of the peers crashed 
> or got brought down for adminstrative reasons.  That is, we 
> proscribe behavior for well- behaved peers, taking in account 
> extreme cases where one of them suddenly disappears.
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments on the 
> application of sip
>