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

["Jain, Rajnish (Rajnish)" <rajnishjain@lucent.com>]

I agree w/ Sean that this problem needs to be addressed in the overall
scope of SIP transport layer connection management.  

It is well known that SIP is designed to be loosely coupled w/ transport 
layer. However, diverse forms of SIP entities (such as phones, proxy 
servers, B2BUAs, application servers) tend to be somewhat differently 
influenced w/ the systemic ripple created by connection-oriented 
transport layers. For instance, while it may be okay for a SIP phone to 
liberally request transport layer connections, it presents performance, 
scaling problems if two high traffic peer proxy servers keep churning 
through transport layer connections. These proxy servers would best 
serve the network if they communicate over persistent connections that 
are setup and torn down predictably. 

RFC 3261 suggests that a connection can be recycled, but for that to 
happen traffic arrival rate must be such that implementation defined 
idle timeouts don't occur. Any sporadic patches of idle time can render 
undesirable connection closure (as Vijay pointed out). Making just the
implementation defined timer very large makes the problem worst. That
way, the proxy server will tend to impose the large timer for all its 
connections even w/ SIP phones. Furthermore, since the timer is 
implementation defined, the two proxies may have vastly different
timer values (one very large and one very solve) which can really
imbalance overall interaction.

Rajnish Jain,
Lucent Technologies

-----Original Message-----
From: Sean Olson [mailto:seancolson@yahoo.com]
Sent: Wednesday, February 12, 2003 8:50 PM
To: Vijay K. Gurbani; Christian Jansson; 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


I'm looking forward to reading the draft.
I think this is a common problem that deserves
greater scrutiny. I don't think there is any 
lack of potential solutions. I would like to see
some clean (informational) recommendations on
how this should be done. In addition to connection
persistence, I think connection re-use is an
interesting problem that could potentially be 
solved with a common design. This is similar
to recommendations on how best to use SCTP
in a SIP environment.

Regards,
Sean Olson
Microsoft


--- "Vijay K. Gurbani" <vkg@lucent.com> wrote:
> Christian Jansson wrote:
> >>Section 18 of rfc3261 correctly instructs
> implementors to 
> >>close connections after a certain time (64*T1).  
> > 
> > No, it does not. Section 18 does not say when to
> close sockets, 
> 
> That's your interpretation.  When I read the
> following sentence from
> section 18:
> 
>     "It is RECOMMENDED that connections be kept open
> for some
>     implementation-defined duration..."
> 
> It implies to me that after the duration has passed,
> the entity is
> free to close the socket.
> 
> > but
> > rather that you should not close the socket to
> soon. So if you feel like
> > it, you could leave the connection open forever.
> 
> I am afraid I don't read it that way; i.e. leave the
> connection open
> forever.
> 
> > Not needed. Close the socket when you have to, and
> probably it will be
> > more effective to keep it open for a while in case
> you need it again (as
> > Cullen Jennings wrote).
> 
> Exactly how long is the question.  For some peering
> arrangements between
> service providers and for UACs always using a
> default outbound proxy,
> does it make sense to leave TCP/TLS sockets open for
> a longer time than
> a transaction.  That is the crux of the problem.
> 
> Cullen Jennings writes:
> > 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.
> 
> Right; or schemes between proxies.
> 
> > 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.
> 
> Fair enough.  Folks on the CC list (except
> sip@ietf.org :-)) are working
> on an I-D and it'll be available as soon as they are
> done.
> 
> Thanks,
> 
> - 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


__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com
_______________________________________________
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