Comments/Clarifications on sas1r03 SSP transport layer

Elliott, Robert (Server Storage) elliott at hp.com
Sat Mar 13 17:05:08 PST 2004


* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <elliott at hp.com>
*
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Ameen Rahman <ameen at cup.hp.com>
> *
> I have the following comments/clarifications on 
> SAS-1.1 Revision 3, Dated 24 Jan 2004
> 
> 1) COMMAND frame - handling og link layer errors (Sec 
> 9.2.4.2, Page 282)
>   
>    The last sentence in this page is,
>    "An SSP initiator port should re-transmit each COMMAND frame that 
>    does not receive an ACK ateast one time".
>   
>    I think an SSP initiator port should retransmit only those COMMANDs
>    which were NOT delivered to the target port. 

It's just a "should."  If it gets a NAK, it might try another target
port with access to that logical unit (perhaps using a different
initiator port altogether) if it has knows of one.  Or, it might just
retry the command on the same I_T.

> 2) SSP frame format ( Sec 9.2.1, Page 270 )
>    This section doesn't explain the RETRY DATA FRAMES and 
>    CHANGING DATA pointer fields of SSP frame header. Probably some 
>    text needs to be added in this section to explain these fields.
>    Explanation for these fields can be found in later sections though.

The missing paragraphs from 03-186r5 will be included in sas1r04.

> 3) SSP frame format ( Sec 9.2.1, Page 270 )
>  
>    Explanation for RETRANSMIT bit from the standard:
> 
>    "The RETRANSMIT bit is set to one for TASK frames, RESPONSE frames,
> and XFER_RDY frames under the conditions defined in FIXFIX and shall 
> be set to zero for all other frame types. This bit indicates the 
> frame is a retransmission after the SSP target port failed in 
> its previous attempt to transmit the frame"
> 
>    a) In the above "FIXFIX" needs to be sustituted with 
> relevant section numbers.

Fixed in sas1r04.

> 
>    b) RETRANSMIT bit is also a indication of initiator port failed in
> its previous attempt to transmit a frame ( TASK frame )

Will remove "target" in sas1r04.

> 4) TASK frame - handling of link layer errors  ( Sec 9.2.4.3, 
> Page 283 )
>   
>    If a NAK is recieved for the TASK frame, what should be 
> the action ?
>    Retry the TASK frame with RETRANSMIT bit set to 0 ??

That's up to the initiator (same for COMMAND frames that are NAKed).
It knows the target didn't get it, so it can do whatever it wants.
There's
a general rule that it should retransmit the frame at least once.
There's 
no requirement for the RETRANSMIT bit to be set to 1, though.  That's
just
for ACK/NAK uncertainty.  (see the application client error handling
section 10.2.2)

> 5) XFER_RDY frame with transport layer re-tries ( Sec 9.2.4.4.3 , Page
> 283 )
>   
>    When the target recieves NAK for a XFER_RDY, probably it should 
>    not set RETRANSMIT bit to 1 in the retransmitted XFER_RDY.

The SAS WG discussed this and recommended keeping the RETRANSMIT 
bit as 1 in this case to ease the job of logic analyzers and engineers 
in the lab.  As the editor's note says, it provides no benefit to
the initiator (since it sent a NAK and never saw the original frame).

> Regards
> -Ameen

--
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




More information about the T10 mailing list