Transport layer retries

George Penokie gop at us.ibm.com
Tue Aug 9 13:02:33 PDT 2005


* From the T10 Reflector (t10 at t10.org), posted by:
* George Penokie <gop at us.ibm.com>
*
This is a multipart message in MIME format.
--=_alternative 006DE72486257058_=
Content-Type: text/plain; charset="US-ASCII"


Bob, 

No that is not a reasonable approach. This is a non-issue and does not
need any changes to the standard. There are dozens of bits and fields in
Mode Pages the could cause a problem if the target marked them as
unchangeable and the initiator did not support that function. That does
not happen as customer specifications and the marketplace take care of
the issue. 

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





"Sheffield, Robert L" <robert.l.sheffield at intel.com> 
Sent by: owner-t10 at t10.org 


08/09/2005 11:43 AM 

To
"Day, Brian" <Brian.Day at lsil.com>, "Bill Martin"
<bill_martin at sierralogic.com>, <t10 at t10.org> 

cc

Subject
RE: Transport layer retries

	





Now that I think about it - it might not be a bad idea to define an
"INITIATOR SUPPORTS TLR" bit in the SAS command frame. A value of zero
wouldn't require that the target NOT attempt retries, but it would be a
pretty good hint that it's not such a good idea. 
  
Does this sound like a reasonable approach? 
  
Bob 


  _____  

From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Day,
Brian
Sent: Tuesday, August 09, 2005 8:13 AM
To: 'Bill Martin'; t10 at t10.org
Subject: RE: Transport layer retries

Bill... 
  
If you follow the tables listed in the state machines (particularly
tables 130, 133, and 134) in section 9.2.6, I believe you will see that
an initiator that doesn't support retries will turn the target's attempt
of the retry into a Command Complete Received confirmation to the app
layer, with the appropriate delivery result error argument. 
This would then cause the application layer (section 10.2.2) to send
down an ABORT TASK. 
  
However, an initiator should not be NAKing frames just because it does
not support transport retries... it should only for link errors.   
  
Hope this helps... 
  
Brian Day 
LSI Logic 


  _____  

From: Bill Martin [mailto:bill_martin at sierralogic.com] 
Sent: Tuesday, August 09, 2005 8:19 AM
To: t10 at t10.org
Subject: Transport layer retries

SAS 1.1 allows for discovery of whether a target supports transport
layer retries, but in the spirit of SCSI, the standard does not require
that the mode page bit be changeable.  In the event that the mode page
bit is not changeable, and the initiator does not support transport
layer retries, what is the mechanism for stopping continuous retries by
the target until a timeout occurs?  The definition of the retry
mechanism in 9.2.4.4.2 and 9.2.4.5.2 require that if retransmitted frame
is received the initiator shall operate on it properly.  Finally, the
number of times that a frame will be retransmitted is vendor specific,
so if the initiator sends NAK, it may be retried over and over. 
  
Thanks for any insight. 
  
Bill Martin
Sr. Principal Engineer
Standards and Interoperability
Sierra Logic, Inc.
916 772-3658 
916 765-6875 (Cell)
bill_martin at sierralogic.com 
  


--=_alternative 006DE72486257058_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">Bob,</font>
<br>
<br><font size=2 face="sans-serif">No that is not a reasonable approach.
This is a non-issue and does not need any changes to the standard. There
are dozens of bits and fields in Mode Pages the could cause a problem if
the target marked them as unchangeable and the initiator did not support
that function. That does not happen as customer specifications and the
marketplace take care of the issue. </font>
<br><font size=2 face="sans-serif"><br>
Bye for now,<br>
George Penokie<br>
<br>
Dept 2C6 &nbsp;114-2 N212<br>
E-Mail: &nbsp; &nbsp;gop at us.ibm.com<br>
Internal: &nbsp;553-5208<br>
External: 507-253-5208 &nbsp; FAX: 507-253-2880<br>
<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>"Sheffield, Robert
L" <robert.l.sheffield at intel.com&gt;</b> </font>
<br><font size=1 face="sans-serif">Sent by: owner-t10 at t10.org</font>
<p><font size=1 face="sans-serif">08/09/2005 11:43 AM</font>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">"Day, Brian" <Brian.Day at lsil.com&gt;,
"Bill Martin" <bill_martin at sierralogic.com&gt;, <t10 at t10.org&gt;</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">RE: Transport layer retries</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2 color=blue face="Arial">Now that I think about it - it
might not be a bad idea to define an "INITIATOR SUPPORTS TLR"
bit in the SAS command frame. A value of zero wouldn't require that the
target NOT attempt retries, but it would be a pretty good hint that it's
not such a good idea. </font>
<br><font size=3>&nbsp;</font>
<br><font size=2 color=blue face="Arial">Does this sound like a reasonable
approach?</font>
<br><font size=3>&nbsp;</font>
<br><font size=2 color=blue face="Arial">Bob</font>
<br>
<br>
<hr><font size=2 face="Tahoma"><b>From:</b> owner-t10 at t10.org [mailto:owner-t10 at t10.org]
<b>On Behalf Of </b>Day, Brian<b><br>
Sent:</b> Tuesday, August 09, 2005 8:13 AM<b><br>
To:</b> 'Bill Martin'; t10 at t10.org<b><br>
Subject:</b> RE: Transport layer retries</font><font size=3><br>
</font>
<br><font size=2 color=#800000 face="Arial">Bill...</font>
<br><font size=3>&nbsp;</font>
<br><font size=2 color=#800000 face="Arial">If you follow the tables listed
in the state machines (particularly tables 130, 133, and 134) in section
9.2.6, I believe you will see that an initiator that doesn't support retries
will turn the target's attempt of the retry into a Command Complete Received
confirmation to the app layer, with the appropriate delivery result error
argument.</font>
<br><font size=2 color=#800000 face="Arial">This would then cause the application
layer (section 10.2.2) to send down an ABORT TASK.</font>
<br><font size=3>&nbsp;</font>
<br><font size=2 color=#800000 face="Arial">However, an initiator should
not be NAKing frames just because it does not support transport retries...
it should only for link errors. &nbsp;</font>
<br><font size=3>&nbsp;</font>
<br><font size=2 color=#800000 face="Arial">Hope this helps...</font>
<br><font size=3>&nbsp;</font>
<br><font size=2 color=#800000 face="Arial">Brian Day</font>
<br><font size=2 color=#800000 face="Arial">LSI Logic</font>
<br>
<br>
<hr><font size=2 face="Tahoma"><b>From:</b> Bill Martin [mailto:bill_martin at sierralogic.com]
<b><br>
Sent:</b> Tuesday, August 09, 2005 8:19 AM<b><br>
To:</b> t10 at t10.org<b><br>
Subject:</b> Transport layer retries</font><font size=3><br>
</font>
<br><font size=2 face="Arial">SAS 1.1 allows for discovery of whether a
target supports transport layer retries, but in the spirit of SCSI, the
standard does not require that the mode page bit be changeable. &nbsp;In
the event that the mode page bit is not changeable, and the initiator does
not support transport layer retries, what is the mechanism for stopping
continuous retries by the target until a timeout occurs? &nbsp;The definition
of the retry mechanism in 9.2.4.4.2 and 9.2.4.5.2 require that if retransmitted
frame is received the initiator shall operate on it properly. &nbsp;Finally,
the number of times that a frame will be retransmitted is vendor specific,
so if the initiator sends NAK, it may be retried over and over.</font>
<br><font size=2 face="Arial">&nbsp;</font>
<br><font size=2 face="Arial">Thanks for any insight.</font>
<br><font size=2 face="Arial">&nbsp;</font>
<br><font size=2 face="Arial">Bill Martin<br>
Sr. Principal Engineer<br>
Standards and Interoperability<br>
Sierra Logic, Inc.<br>
916 772-3658</font>
<br><font size=2 face="Arial">916 765-6875 (Cell)<br>
bill_martin at sierralogic.com</font>
<br><font size=3 face="Times New Roman">&nbsp;</font>
<br>
--=_alternative 006DE72486257058_=--





More information about the T10 mailing list