Subject: [SIP] RE: [Sip-implementors] Interpretation of break in TCP connection

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 15 Mar 2001 02:51:47 -0500

(forwarded old note from sip-implementors to sip since there is an open
issue here)

The current spec has some verbiage of how treatment of premature TCP
connection closures is handled at clients and servers.

I'd like to deprecate the entire thing. Here's why.

1. Client close = CANCEL = proxy close?

The problem here is that there is an implicit assumption that the client
side of a connection is from a UAC. TCP and or TLS is very useful between
proxies within a domain, in which case the "client side" of the connection
is a proxy. Its not possible for the server side to determine whether the
previous hop is a proxy or UAC, and I don't want to try and use heuristics
(like Via counting) to guesstimate this. Equivalency of SIP semantics
between UAC to proxy and proxy to proxy is quite fundamental. So, if the
client side closes the connection, and the client side is a proxy, should
the proxy on the server side of the connection CANCEL every pending
transaction through it? Horrible. This is not what you want at all in this
case. Its also a big implementation burden to track the pending transactions
on every connection.

2. separation of transport from semantics

As much as possible (and we can't do it entirely), I'd really like to
separate transport level issues from sip semantics. That is, excepting
retransmit issue, I don't want to associate higher level sip behavior with
transport behavior. The rule about connection closures violates that.

3. breaks reliable networks

The rule regarding the case of a server prematurely closing the connection
(client treats it as a 500) is at odds with designing highly available SIP
networks that use TCP (and it is possible). Lets say the proxy did indeed
crash, releasing the server side of the TCP connection prematurely. The
response to that request could get forwarded through a different server, and
that server could open a connection to the client to send the response.
However, if the client interpreted closure of the TCP connection as a 500,
its too late. 

4. client closure = CANCEL at odds with 487

Bis now specifies that the original transaction being cancelled is responded
to with a 487. So, lets say a client opens a connection, sends a request,
then closes the connection. The proxy treats this as a CANCEL. It creates
and sends a CANCEL downstream. The UAS gets teh CANCEL, responds 200 OK to
it. It then responds 487 to the original request being cancelled. This is
forwarded upstream to the proxy. The proxy gets the 487. It then processes
it according to the via processing, which will cause it to open a connection
to the upstream UA, and send that 487! Big waste. 

I suspect there is no implementation which uses TCP, and actively closes
connections prematurely instead of cancelling. Similarly, I suspect there
are no servers which close TCP connections instead of explicitly sending a
500. If my suspicions are correct, we can safely remove this capability from
SIP. I think it adds little value. If a client crashes before a transaction
completes, the server will know it when it tries to re-open the connection
to send the response. Simiarlly, if a client sends a request, and the server
crashes during the transaction, and there is no backup, the client
transaction will timeout. 

Comments?

(I'll be discussing this during IETF probably).

-Jonathan R.

> -----Original Message-----
> From: Jo Hornsby [mailto:[email-masked]]
> Sent: Tuesday, January 30, 2001 4:15 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [Sip-implementors] Interpretation of break in TCP
> connection
> 
> 
> Binu wrote:
> >      In section 10.3 of the bis-02 draft it is mentioned that if
> > the server
> > closes a connection prematurely, the client should treat 
> the closure as a
> > 500 (Server Internal Error) response. It is also mentioned 
> that the server
> > treats closure of connections as a CANCEL for the pending 
> transactions on
> > that connection. So if a TCP connection were to break 
> before a transaction
> > could be completed, won't the client treat this as a 500 
> response to the
> > request and then receive a "487 Transaction Cancelled" 
> response from the
> > proxy server on a passive connection ?
> 
> To be honest, I'm slightly confused by this question, but
> I'll blunder on as always, anyway. &:)
> 
> Basically, the semantics of a "premature" TCP connection close
> depends on who was responsible for closing it.  A client seeing
> a connection close interprets that as a 500 for all transactions
> using that connection that have not had received responses.
> A server seeing a connection close interprets that as a CANCEL
> for all transactions using that connection that have not been
> sent final responses.
> 
> In your case above, it is the server that is closing the
> connection prematurely (at least, that is how I interpret it),
> so the client pretends it saw a 500.  Probably, the proxy
> (or whatever) has died in this case.  If the proxy has not
> died, then it might be that we're seeing some sort of network
> outtage, in which case the proxy will see the close as a
> CANCEL, and thus do its normal cancelling magic.  (I guess
> it's not impossible that the proxy would actively open up
> a connection back to the client to return the final response
> to the connection, but since it seems reasonable to assume
> that this will fail (otherwise, why did the connection close?),
> I would imagine that most proxies do not do this.)
> 
> >      Or is it that the proxy server treats the closure as a
> > CANCEL in order
> > to cancel pending transactions on the branches but does not 
> respond to the
> > client with a "Transaction Cancelled" response for the 
> original request ?
> 
> More likely, I think.
> 
> [Note that for a proxy, the response should be the result of
> all the transaction branches; i.e., not necessary a 487.]
> 
> Cheers,
> 
> 
>  - Jo.
> 
> _______________________________________________
> Sip-implementors mailing list
> [email-masked]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> 

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: "Jo Hornsby" <[email-masked]>
Date: Thu, 15 Mar 2001 11:09:27 -0000

> I'd like to deprecate the entire thing. Here's why.
[...]

Sounds good to me; particularly in light of your proposal for
the change to Via-processing to support SRV usefully.

I was fond of that piece of code, but for the greater good, eh?

Cheers,

 - Jo.

---

From: Benny Prijono <[email-masked]>
Date: Fri, 16 Mar 2001 15:37:33 +0000

> transaction will timeout.

This is a very good thing to do.

But this might not be backward compatible. A server which conforms to
the new behaviour might close TCP connection (for a very odd reason),
and assumes that it would not change transaction state. But it does
change the transaction state, if the client conforms to the old (i.e.
current) behaviour. So there will be state inconsistency between
client and server.

I got to admit though that I can't find any reasons why the server
should close the TCP connection when it still has some pending
transactions, but that's possible, and that's not backward compatible.

-- 
cheers,
Bennylp