Subject: Re: [Sip] Anybody feeling a connection with "connect reuse"?

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Jul 2006 00:34:45 -0400

Having just done a detailed review of the document, I will say that I am 
skeptical of the value of this specification at this time.

Firstly, it has fairly limited deployment scenarios:

1. no NATs between the elements
2. mutual TLS auth only

assuming these are true, its valuable only when there is generally a lot 
of churn in TLS connection setups. For example, in an environment where 
there is a fixed and known-ahead-of-time peering relationship between 
providers, connect-reuse doesn't do much for you anyway, since there are 
relatively few TLS connections and they are set up when the system 
boots, or perhaps just once.

Even if the connections aren't set up at startup, but on demand, over 
time the value of connect-reuse is really zero if the total number of 
TLS connections that are needed by the proxy is below the capacity of 
the server. In other words, if a proxy only ever connects to 100 other 
proxies, then at some point the proxy gets its 200 TLS connections set 
up (assuming no connect-reuse) and thats it. It never tears them down 
since it never runs out of resources, so TLS handshaking becomes a 
fixed, one-time cost. That makes it uninteresting to optimize.

The value, then, comes only when the set of proxies that get connected 
to is constantly changing, such that TLS handshaking between proxy peers 
is an ongoing and non-trivial percentage of the overall CPU effort.

To be frank, I am not aware of a single deployment situation today that 
meets this constraint. Can someone point me to a real deployment 
scenario where connect-reuse is applicable and has a non-trivial 
improvement in the performance of the proxy?

Thanks,
Jonathan R.

Nils Ohlmeier wrote:

> On Friday 23 June 2006 23:08, Dean Willis wrote:
> 
>>We've been following the connection reuse draft, currently draft-ietf-
>>sip-connect-reuse-05.txt, for a long long time.
>>
>>We've slipped the charter delivery date several times.
>>
>>Are we ever going to finish this work? Do we need to finish this work?
>>
>>Is this something that we could just not do?
>>
>>
>>Otherwise said: "Does the SIP working group still have a consensus to
>>expend working group effort on connection reuse?"
>>
>>If you have an opinion, for or against, please let it be known on
>>this list.
> 
> 
> I think their are two options left:
> 
> - either push it out as "TLS-connection-reuse-between-proxies" (if nobody 
> comes up with any issue any more)
> - or drop it because the real world usage is too limited
> 
> I have little preference for the first alternative, but wouldn't mind to go 
> for the second option.
> 
> Regards
>   Nils
> 
> _______________________________________________
> 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
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Jul 2006 16:29:53 -0400

Sorry - haven't been following this and don't have a position on the 
merits. But one thing Jonathan didn't mention below that might be relevant:

With two connections, the traffic is split across them. This potentially 
affects the flow control. I can see that there could be both pros and 
cons to this.

	Paul

Jonathan Rosenberg wrote:
>> - either push it out as "TLS-connection-reuse-between-proxies" (if 
>> nobody comes up with any issue any more)
>> I have little preference for the first alternative, but wouldn't mind 
>> to go for the second option.
>>
>> Regards
>>   Nils
>>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Sat, 08 Jul 2006 02:07:36 -0500

> 1. no NATs between the elements

Jonathan: This is imposed by other realities.  The NAT issue is
discussed in outbound, and a decision has already been made not
to do connect reuse of TCP connections.

> boots, or perhaps just once.

True, but there is nothing to stop UACs in an enterprise to do
connect reuse to their default outbound proxy.

> fixed, one-time cost. That makes it uninteresting to optimize.

RFC3261 is rather silent on how to do persistent connections.
This has let to a mess for TCP, where some implementations keep the
connections open across transactions and dialogs, some do not, and
yet others open a new connection to send a response!  Let's not
create the same mess for TLS.

> is an ongoing and non-trivial percentage of the overall CPU effort.

...Or the number of UACs using a default outbound proxy is
constantly changing...

> improvement in the performance of the proxy?

Connection reuse is underspecified in rfc3261, which takes the
position that connections accepted by the transport layer
will frequently not be reused.  Connect-reuse solves this
problem.  Without it, there is *absolutely* no guidance in how
to send requests in the backwards direction on the same
connection if outbound is not used.  Given the state of
TCP connection reuse today, I think we can do better with
TLS.  The draft itself has seen implementations, so it
appears that it has some utility.

The draft can be wrapped up in a couple of weeks after
Montreal.

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)