SAS SL_CC missing a Connection Closed (Break Received)

[Elliott, Robert (Server Storage)]

* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
*
With lots of deletions to try to make this thread readable again...

> -----Original Message-----
> From: George Penokie [mailto:gop at us.ibm.com] 
> Sent: Wednesday, April 30, 2003 8:47 AM
> To: Elliott, Robert (Server Storage)
> Cc: t10 at t10.org
> Subject: RE: SAS SL_CC missing a Connection Closed (Break Received)
> 
> Rob,
> OK, I agree it's not a good idea to tell the port layer 
> something has happened before it really has happened. But I 
> still do not believe your solution is a good one. See my 
> comments below.
> 
> Bye for now,
> George Penokie
> 
> Dept 2C6  114-2 N212
> E-Mail:    gop at us.ibm.com
> Internal:  553-5208
> External: 507-253-5208   FAX: 507-253-2880

>> RE - These are the state machine paths through BreakWait and the 
>> confirmations that could be sent if the confirmation is added 
>> to the Connected state:
>> 
>> from ArbSel (sent OPEN):
>>          Open Failed (Port Layer Request or Open Timeout 
>>              Occurred or Break Received)
>>          then, if appropriate, Connection Closed (Break Timeout)
>> from Connected (from an established connection):
>>          Connection Closed (Break Received)
>>          then, if appropriate, Connection Closed (Break Timeout)
>> from DisconnectWait (sent CLOSE, timed out):
>>          Connection Closed (Close Timeout)
>>          then, if appropriate, Connection Closed (Break Timeout)
>> 
>> Making DisconnectWait the state that issues exactly one of 
>> them yields this set:
>> 
>> from ArbSel (sent OPEN):
>>          Open Failed (Port Layer Request or Open Timeout Occurred)
>>          then, Connection Closed (Break Received) or 
>>             Connection Closed (Break Timeout)
>> from Connected (from an established connection):
>>          Connection Closed (Break Received) or 
>>             Connection Closed (Break Timeout)
>> from DisconnectWait (sent CLOSE, timed out):
>>          Connection Closed (Close Timeout)
>>          then, Connection Closed (Break Received) or 
>>            Connection Closed (Break Timeout)

> GOP - In all of the cases above the second confirmation 
> only occurs if there is an error. The error being that there 
> was no response to the BREAK when there should have been. 
> With the suggested change there would always be a second 
> confirmation. So you have taken an error case response and 
> made it the normal operation. That is what I object to. For 
> example with this change the port layer will always get both 
> an Open Failed and a Connection Closed instead of just an 
> Open Failed and hardly ever getting the Connection Closed.

RE - In the "through ArbSel" case, it would always get a Connection
Closed after the Open Failed.  The port layer is not looking for
Connection Closed at that point (Open Failed shut it up) so it doesn't
hurt anything.

However, this leads to a question: if a phy gives up on an OPEN and
sends BREAK (because of a port layer request or a timeout), should it
report these differently?
a) Gave up, sent BREAK, and got a BREAK in return
b) Gave up, sent BREAK, and didn't get a BREAK in return

For the port layer to notice, that would have to be sent instead of Open
Failed (Port Layer Request or Open Timeout).  Which means that ArbSel
couldn't be the state that sends it; BreakWait would have to do so.


The same question applies to the "through DisconnectWait" case.  Is it
important to differentiate these?
a) a Close Timeout happened, sent BREAK, and got BREAK in return
b) a Close Timeout happened, sent BREAK, and a Break Timeout happened

Multiple Connection Closed () aren't noticed by the port layer.  To make
this distinction, DisconnectWait could not send Connection Closed (Close
Timeout) - BreakWait would have to do so.

> GOP - So the only solution I see is to place a conditional 
> statement into the BreakWait state so that only if it is 
> entered from the Connected state will it send the Connection 
> Closed (Break Received) if a BREAK Received message is 
> received before the timeout occurs.

RE - I fear the complete solution might need to be:
* Don't have ArbSel send Open Failed (Port Layer Request) or Open Failed
(Open Timeout) 
* Don't have DisconnectWait send Connection Closed (Close Timeout)
* make BreakWait send:
  * Open Failed (Port Layer Request and Break Timeout)  [new message]
  * Open Failed (Port Layer Request)  [new source state]
  * Open Failed (Open Timeout and Break Timeout)  [new message]
  * Open Failed (Open Timeout)  [new source state]
  * Connection Closed (Close Timeout and Break Timeout)  [new message]
  * Connection Closed (Close Timeout)   [new source state]
  * Connection Closed (Break Received)   [fixing the original bug]
  * Connection Closed (Break Timeout)    [as is]
  * based on the dreaded "arguments to the transitions" into BreakWait

--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
https://ecardfile.com/id/RobElliott


*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org