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

From: "Matthew Gardiner" <[email-masked]>
Date: Thu, 29 Jun 2006 21:14:29 +0100

Hi,

I have been reading the above document with some interest, as any recommendation which attempts to reduce the burden due to latency of repeated TLS handshakes seems to be worth following.

However, I am now unsure as to how "shared connections" may be implemented without introducing the chance of race conditions between remote closes and request sends.

It is section 8 which worries me. Despite the statement:

"When a server receives a request whose topmost Via header contains an "alias" parameter, it signifies that the upstream client will leave the connection open beyond the transaction and dialog lifetime, and that subsequent transactions and dialogs that are destined to a resolved address that matches the identifiers in the advertised address in the topmost Via header can reuse this connection."

in 8.2 Server Behaviour, both the client and server behaviour sections also add that client/server must be prepared to open new connections in the, albeit unlikely, circumstance of the remote peer closing their end of the connection. My question is, at any instant time, how does the peer ready to send a new request know whether or not the remote end has called close()? 

Consider the following sequence of events, listed chronologically:

1. local end checks for read/write on socket. socket is writeable.
2. remote end closes.
3. local end calls send. send will not report an error initially.

Am I missing something obvious as to how the remote close can be always detected, prior to the attempt to send?

thanks,

Matthew Gardiner
Software Enginneer
Aculab

_______________________________________________
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: Thu, 29 Jun 2006 16:42:51 -0500

> detected, prior to the attempt to send?

Matthew: A socket that is being monitored for events using select()
or poll() is considered ready for reading when the read half of
the connection is closed.

When the sequence of events you write above happens, the send will
succeed, but as a result of the remote end closing the socket, the
local end will get a FIN, making the local descriptor readable.
A read operation will then return EOF and you can conclude that
all transactions in progress that are tied to that socket need
to be closed appropriately.

Depending on the TLS libraries you are using, your application
could also get notified when the local end receives a close_notify
TLS message.  The close_notify will be followed by a FIN.

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)

---

From: "Matthew Gardiner" <[email-masked]>
Date: Fri, 30 Jun 2006 08:09:47 +0100

Thanks Vijay,

I think you have allayed my fears regarding the race possibility. However, I think that to implement this connect-reuse scheme correctly would require some fairly major changes to our, and perhaps other peoples', SIP stacks. As connection-oriented sockets are based on a stream of bytes, rather than necessarily discrete packets, it makes them somewhat difficult to associate with SIP transactions, particularly in programming environments where socket processing, transaction management and dialog management are delegated to individual worker threads.

In addition to the requirement of maintaining a per-socket list of associated transactions, there is also the need to not only close these transactions in the event of socket EOF but furthermore then to restart the transactions to cater for this possibility.

thanks,

Matthew Gardiner
Software Engineer
Aculab

-----Original Message-----
From: Vijay K. Gurbani [mailto:[email-masked]]
Sent: 29 June 2006 22:43
To: Matthew Gardiner
Cc: IETF SIP List
Subject: Re: [Sip] draft-ietf-sip-connect-reuse-05

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 30 Jun 2006 08:55:16 -0500

[... I will CC the SIP list, but I think any responses to
      this thread should migrate to sip-implementors, since
      the discussion is now heading towards implementation
      stratgies and not changes in the protocol itself ...]

Matthew Gardiner wrote:
> Thanks Vijay,
> 
> I think you have allayed my fears regarding the race possibility.

OK; thanks.

> However, I think that to implement this connect-reuse scheme 
> correctly would require some fairly major changes to our, and perhaps
> other peoples', SIP stacks.

Maybe; however, a standard cannot dictate how a software
implementation is constructed.  All it can do is to ensure that
those entities that do not support the feature being developed
are not adversely affected.  And connect-reuse does that.

> As connection-oriented sockets are based on a stream of bytes, rather
> than necessarily discrete packets, it makes them somewhat difficult
> to associate with SIP transactions, particularly in programming
> environments where socket processing, transaction management and
> dialog management are delegated to individual worker threads.

There are many ways to skin and de-bone this particular feline.
You do not necessarily need to tie sockets to transaction processing
if you do not want to.  For instance, if a send of an INVITE
succeeds, but the TLS thread detects that the socket has been
closed, it could act dumb and do nothing.  After T1*64s, for
an INVITE transaction Timer B will fire.  And you can do
appropriate processing since you never received a final response
to the INVITE.  And so on...

There is enough information in the transaction state machines
to allow recovery even when TLS threads are decoupled from
worker threads.  Distilling this information into a specific
software implementation will, of course, be a function of how
the software is architected.

Thanks.

- vijay

---

From: "Matthew Gardiner" <[email-masked]>
Date: Fri, 30 Jun 2006 15:23:34 +0100

Thanks Vijay,

[ > but I think any responses to this thread should migrate to sip-implementors
Yes, maybe at some stage, I'll re-post to there, but as I started off the posting here...]

> a standard cannot dictate how a software implementation is constructed.
Yes, I agree, I just wanted to get clear whether the proposed standard is actually realistic/feasible before undertaking the implementation.

> You do not necessarily need to tie sockets to transaction processing if you do not want to.
I'm not sure that there is a practical alternative. See below...

> After T1*64s, for an INVITE transaction Timer B will fire.  And you can do appropriate processing ...
Yes, fair enough. However, this suggestion is unworkable, for instance in a situation where the remote end dropped it's connection on a timer, and is perfectly willing to accept to a new connection. If the transaction was a reINVITE for hold, for example, the caller would be left waiting for 32 seconds minimum, before the local stack fires Timer B and decides it must initiate a new connection in order to place the hold. As an implementator I'd want a better technique than this.

thanks
Matthew Gardiner 

-----Original Message-----
From: Vijay K. Gurbani [mailto:[email-masked]]
Sent: 30 June 2006 14:55
To: Matthew Gardiner
Cc: IETF SIP List
Subject: Re: [Sip] draft-ietf-sip-connect-reuse-05

OK; thanks.

Thanks.

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 30 Jun 2006 09:38:04 -0500

Matthew Gardiner wrote:
> Yes, I agree, I just wanted to get clear whether the proposed
> standard is actually realistic/feasible before undertaking the
> implementation.

There are implementations in the wild out there.  I have
implemented it, and at the last SIPit, there were 6 implementations
reported.  Plus some more that I am aware of through IETF hallway
conversations and private emails.

> Yes, fair enough. However, this suggestion is unworkable, for
> instance in a situation where the remote end dropped it's connection
> on a timer, and is perfectly willing to accept to a new connection.
> If the transaction was a reINVITE for hold, for example, the caller
> would be left waiting for 32 seconds minimum, before the local stack
> fires Timer B and decides it must initiate a new connection in order
> to place the hold. As an implementator I'd want a better technique
> than this.

True.  I will answer this on a separate email CC'd to the
sip-implementors list.

Thanks.

- vijay