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

From: "Mark Watson" <[email-masked]>
Date: Tue, 11 Feb 2003 16:16:14 -0000

I fail to see the problem.

Servers can close the connection whenever they like. pc=1 tells the server
to keep the connection for longer. Longer than what ? Longer than it would
have done otherwise ??

If the server closes the connection, it presumably had a good reason. Asking
it nicely to ignore its own good reasons does not seem very useful to me.

Perhaps we should recommend that servers do not close connections without a
good reason ? Should we recommend that they do not initiate connections
without a good reason ? or that they should not reject connections without a
good reason ? Why should we believe there are servers which will arbitrarily
close connections for no reason, servers that are so stupid they need a new
parameter to tell them not to do this ?

...Mark

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> Sent: 10 February 2003 18:04
> To: 'Vijay K. Gurbani'
> 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
> 
> 
> 
> 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
>  
> 
> > -----Original Message-----
> > 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:
> > > 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
> > 
> > _______________________________________________
> > 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
> > 
> 
> _______________________________________________
> 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: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 12 Feb 2003 08:45:58 -0600

Mark Watson wrote:
> Servers can close the connection whenever they like. pc=1 tells the 
> server to keep the connection for longer. Longer than what ? Longer than 
> it would have done otherwise ??
> 
> If the server closes the connection, it presumably had a good reason. 
> Asking it nicely to ignore its own good reasons does not seem very 
> useful to me.
> 
> Perhaps we should recommend that servers do not close connections 
> without a good reason ? Should we recommend that they do not initiate 
> connections without a good reason ? or that they should not reject 
> connections without a good reason ? Why should we believe there are 
> servers which will arbitrarily close connections for no reason, servers 
> that are so stupid they need a new parameter to tell them not to do this ?

Mark:

I don't think anyone is suggesting that every connection a server
opens actively to a downstream entity or accepts passively from an
upstream client remain open forever.

The essence of the problem simply is that two high-signaling traffic
proxies (or a UAC and its default outbound proxy) would like to keep
a TCP (or TLS) connection open for traffic between them.  This
alleviates negotiating TLS security keys or TCP 3-way handshake for
each transaction going between them.

Admittedly, this was not too much a problem when UDP was the preferred
mode of transport for SIP signaling.  However, for good reasons, TCP is
becoming the preferred transport.  So I don't see why we can't have some
thought put into investigating this problem.

Section 18 of rfc3261 correctly instructs implementors to close
connections after a certain time (64*T1).  It also recognizes that
two proxies in a peering relationship will actually have two
connections open towards each other (which can be avoided).  And it
also rightly defines "persistence" to mean a transaction duration.
rfc3261 must ensure that the transactional integrity of SIP is
preserved, and it does.

All that is being done now is an attempt to investigate an extension
that will enable "persistence" to mean some duration longer than
a transaction's lifetime.  Exactly how long, how to negotiate it (or
not) is what comes next.

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: Wed, 12 Feb 2003 09:16:59 -0800

Hmm - I did not read 3261 quite that way.

I thought it was more along the lines of what you want to get too where it
is up to the proxy and UA to make intelligent decision about when to close a
connection. I think it would be good to provide some information level
advice about schemes UA and Proxies might want to use to do a good job of
this. If this required more information to be passed between them to do a
good job of it that would be interesting but without seeing the scheme it is
hard to see that they need any more information than they have today.

Cullen

> From: Vijay K. Gurbani [mailto:[email-masked]]
> Sent: Wednesday, February 12, 2003 6:46 AM
> To: Mark Watson
> Cc: 'Cullen Jennings'; 'Colasanto, Eric (Eric)'; 'James Ford'; 'Jain,
> Rajnish (Rajnish)'; [email-masked]; 'Sarit Galanos Mekler'
> Subject: Re: [Sip] Impossible to use real persistent connection with sip
>
>
> Mark Watson wrote: