Question

We have a design like below and I would like to get opinions or protocol guidlines
for the below error scenario.

   Layer1                                                 
---------------                                                
 |      ^    ^                                          
 | (1)  |(4) |(6)
 v      |    |                                           Remote entity
----------------                                        ---------------  

   Layer0-----------------(2)------------------------------->Layer0
   Layer0<----------------(3)--------------------------------Layer0
   Layer0<----------------(5)--------------------------------Layer0


1. New session request to remote entity.
2. Establish link + data(session request)
3. Link Establishment ongoing 
4. Link Establishment pending
5. Link Established + data (session accepted)
6. session accepted.

If layer1 decides that it does not need the remote entities service between step 4 and 6. i.e event 4 is received and event 6 is yet to be received due to some error.

1) Should it wait for event 6 to happen and initiate a session release or
2) Layer1 should instruct Layer 0 to terminate the connection establishment procedure
immediately.

Which is the correct way?

The problem with (1) will be, even though we know that we are going to terminate the session because of an error, we need to handle other events before event6 comes in.

Answer 1

I am a fan of fail fast designs. As soon as you know that you can’t continue, you should notify the other side, and quit.

If for some reason you need to verify that the other side got your quit message, I prefer responding to requests with either an UNABLE_TO_COMPLY message, or discarding the events entirely. The problem is that you can get in a half-open state.

One way to handle a situation where the other side is stuck waiting for responses from other requests after you have already sent the fail message is to use a priority queue. Instead of processing requests in the order they are received, you can indicate that some messages are processed immediately no matter when they are received. The higher priority messages get inserted in the front of the queue, so quit_on_failure events are not blocked by other requests that you know you cannot really process.

I generally also dislike time-based watchdogs (because the time length the developer chooses is never correct for all situations), but for these kinds of protocols you often have to define a worst-case scenario where the other side never responds to your fail message. In these situations, a configurable time-out is usually the only way to clean up. Timeouts should always be the last resort, never the first.