Subject: [Sip] Some doubts about draft-ietf-sip-connect-reuse-05

From: Rocky Wang <[email-masked]>
Date: Wed, 22 Mar 2006 08:56:38 -0600

Hi, Rohan and Brett,
Why should we limit only one TLS connection between two entities? Suppose
there are a huge traffic between proxys or proxy and application server, one
TLS maybe will limit the traffic and application. I think they can keep and
select a TLS connection if there are some, for example, load balance.
And we should not mandate that the entities MUST NOT disconnect TLS if it is
reused. Let's suppose there are not much traffic between two proxys and the
TLSes have not been used for a long time, it should be possible to
disconnect them. Even though there are no any application layer data, but
much connection will reduce the performance quickly, especially TCP and TLS.

Regards,
Rocky Wang

_______________________________________________
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

.com> for
	[email-masked]; Wed, 22 Mar 2006 23:21:29 +0800 (CST)
Date: Wed, 22 Mar 2006 08:56:38 -0600
From: Rocky Wang <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: [Sip] Some doubts about draft-ietf-sip-connect-reuse-05

Hi, Rohan and Brett,
Why should we limit only one TLS connection between two entities? Suppose
there are a huge traffic between proxys or proxy and application server, one
TLS maybe will limit the traffic and application. I think they can keep and
select a TLS connection if there are some, for example, load balance.
And we should not mandate that the entities MUST NOT disconnect TLS if it is
reused. Let's suppose there are not much traffic between two proxys and the
TLSes have not been used for a long time, it should be possible to
disconnect them. Even though there are no any application layer data, but
much connection will reduce the performance quickly, especially TCP and TLS.

Regards,
Rocky Wang

_______________________________________________
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, 22 Mar 2006 14:11:24 -0600

Rocky Wang wrote:
> Hi, Rohan and Brett, Why should we limit only one TLS connection
> between two entities? Suppose there are a huge traffic between proxys
> or proxy and application server, one TLS maybe will limit the traffic
> and application. I think they can keep and select a TLS connection if
> there are some, for example, load balance.

Load balancing through SRV mechanism is accounted for in the
current draft.  You do not need to do anything special.

> And we should not mandate that the entities MUST NOT disconnect TLS
> if it is reused. Let's suppose there are not much traffic between two
> proxys and the TLSes have not been used for a long time, it should be
> possible to disconnect them. Even though there are no any application
> layer data, but much connection will reduce the performance quickly,
> especially TCP and TLS.

I don't think that the draft mandates with normative strength
that idle connections should be kept open *indefinately*.  When
to close a connection is an implementation defined issue; at the
minimum, to get the most benefit out of connection reuse, the
implementation should not close sockets after every transaction
and/or dialog.  Some implementations may choose to close
connections when the number of open connections have reached a
high watermark, others may want to close them when they have been
idle for some time (implementation defined).

Thanks,

- vijay

---

From: Rocky Wang <[email-masked]>
Date: Wed, 22 Mar 2006 14:46:24 -0600

> current draft.  You do not need to do anything special.

The following sentense is from the client behavior part of the draft. Maybe
I missed something.
And furthermore,
   it MUST reuse the connection when subsequent requests in the same or
   different transactions are destined to the same resolved address. 

   Whether or not to allow an aliased connection ultimately depends on
   the recepient of the request.  Thus, clients MUST NOT assume that the
   acceptance of a request by a server automatically enables connection
   aliasing.  They MUST continue receiving requests on their default
   port.

> 
> > And we should not mandate that the entities MUST NOT 
> disconnect TLS if 
> > it is reused. Let's suppose there are not much traffic between two 
> that idle connections should be kept open *indefinately*.  
> When to close a connection is an implementation defined 
> issue; at the minimum, to get the most benefit out of 
> connection reuse, the implementation should not close sockets 
> after every transaction and/or dialog.  Some implementations 
> may choose to close connections when the number of open 
> connections have reached a high watermark, others may want to 
> close them when they have been idle for some time 
> (implementation defined).

The following part is also from the client behavior part of the draft.
Please help me to check it.

   The implications of placing an "alias" parameter in the topmost Via
   header of a request must be understood by the client.  Specifically,
   this means that the client MUST keep the connection open for as long
   as the resources on the host operating system allow it to, and that
   it MUST accept requests over this connection -- as opposed to a
   default listening port -- from its downstream peer.

Thanks,
Rocky Wang

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 23 Mar 2006 09:36:44 -0600

Rocky Wang wrote:
> The following sentense is from the client behavior part of the draft.
> Maybe I missed something. 
> And furthermore, it MUST reuse the
> connection when subsequent requests in the same or different
> transactions are destined to the same resolved address.
> 

Rocky: I will attempt to clarify this in the next rev.  All the
above paragraphs are saying is (a) when a client establishes
an alias with the downstream server, it must use the aliased
connection on subsequent requests, and (b) since the alias
mechanism does not have a negotiation process, the client cannot
really be sure that the server accepted the alias and will send
subsequent requests in the backwards direction over the aliased
connection.  Thus, it must be prepared to receive new requests
from the same downstream server over the default port.

> The following part is also from the client behavior part of the
> draft. Please help me to check it.
> 

OK; maybe this needs some more explanation in the next rev as well.

This goes back to the discussion we had in the previous email
in this thread.  The normative statements simply state that the
client must keep the connection alive for as long as it can.
Reclamation of the connection should be done based on some
heuristics, but at the very least, the connection to the same
downstream server should not be opened and closed with regularity
if the benefits of connection reuse are to be realized.

I will add some more explanatory text in the next rev.

Thank you for your comments.

Regards,

- vijay