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:fluffy@cisco.com]
> Sent: 10 February 2003 18:04
> To: 'Vijay K. Gurbani'
> Cc: 'Colasanto, Eric (Eric)'; 'James Ford'; 'Jain, Rajnish (Rajnish)';
> sip@ietf.org; '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: sip-admin@ietf.org [mailto:sip-admin@ietf.org] 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); sip@ietf.org; 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 (Sarit@radvision.com) 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 sip-implementors@cs.columbia.edu for questions on current
> > sip Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>