initiator retransmission of DATA frames with transport layer retries

George Penokie gop at us.ibm.com
Thu Jul 28 13:33:17 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 0070BBE58625704C_=
Content-Type: text/plain; charset="US-ASCII"


Rich, 

The paragraph you indicated is not correct (it's left over from before
the standard had frame level retries defined) and is the comparable
paragraph in section 9.2.5.2. The correct summary section that describes
this is in section 9.2.4.5 DATA frame - handling of link layer errors.
However, the absolute rule is defined in the 9.2.6.3.3.6
ST_TTS5:Receive_Data_Out state section (see below). So in the retry case
the target just keeps going tossing out the frames until the CHANGING
DATA POINTER bit is set to one. 

9.2.6.3.3.6 ST_TTS5:Receive_Data_Out state 
9.2.6.3.3.6.1 State description 
If: 
a) transport layer retries are supported; 
b) the CHANGING DATA POINTER bit is set to zero; and 
c) the value in the DATA OFFSET field is not equal to the Write Data
Received variable, 
then this state should discard all Data-Out Arrived messages until the
CHANGING DATA POINTER bit is set to one. 
This state shall resume processing additional Data-Out Arrived messages
when it receives a Data-Out Arrived message with the CHANGING DATA
POINTER bit set to one. 

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





"Deglin, Rich" <Richard_Deglin at adaptec.com> 


07/28/2005 02:36 PM 

To
George Penokie/Rochester/IBM at IBMUS 

cc
"Chen, Larry" <Larry_Chen at adaptec.com>, "Hu, Lin" <Lin_Hu at adaptec.com>,
<t10 at t10.org> 

Subject
RE: initiator retransmission of DATA frames with transport layer retries

	





George 

  


How does a target which supports retries deal with the following
situation? 


  


Initiator sends write command. 


Target sends XFER_RDY. 


Initiator sends write data. One DATA frame (not the last) has a CRC
error, thus target sees a gap in the stream (data offset does not match
what is expected). 


  


The standard says that the target must send a check condition (RESPONSE
frame) to the initiator (sec 9.2.5.3 para 11). How does this square with
the requirement that the initiator is going to retransmit the data? Does
this imply that the initiator cannot transmit any additional DATA frames
following the receipt of NAK? This is not possible as DATA frames are
not interlocked. 


  


Thanks for your time, 


  


Rich Deglin 


Principal Software Engineer 


Vitesse Semiconductor 


Email: rdeglin at vitesse.com 


  



  _____  

From: George Penokie [mailto:gop at us.ibm.com] 
Sent: Thursday, July 28, 2005 11:00 AM
To: Deglin, Rich
Cc: Chen, Larry; Hu, Lin; t10 at t10.org
Subject: RE: initiator retransmission of DATA frames with transport
layer retries 


  



Rich, 

At the point an initiator receives a NAK for a frame it has two choices:


1- If retries are disabled (or not supported) then the initiator stops
sending frames (i.e., the state machine transitions from
ST_ITS2:Initiator_Send_Frame to ST_ITS1:Initiator_Start). 
2-If retries are enabled then the initiator resets the pointers for the
write data back to the offset that was sent in the last XFER_RDY and
then starts sending the frames again from that offset point. 

The target will never retransmit an XFER_RDY as the result of having
sent a NAK for a data frame. The only reason the target will retransmit
an XFER_RDY is if the XFER_RDY transmission failed. The target never
attempts to retry data frames on writes it will only retry data frames
on read operations (i.e., the initiator is responsible for controlling
the retry of write data frames not the target) 

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






"Deglin, Rich" <Richard_Deglin at adaptec.com> 


07/28/2005 12:05 PM 



To
George Penokie/Rochester/IBM at IBMUS 

cc
"Chen, Larry" <Larry_Chen at adaptec.com>, "Hu, Lin" <Lin_Hu at adaptec.com>,
<t10 at t10.org> 

Subject
RE: initiator retransmission of DATA frames with transport layer retries

  





  	 






George 
 
I am generally in agreement with your analysis. 
 
I may be mistaken, but I believe an initiator is free to continue
transmitting DATA frames even after receiving NAK (although this is an
unwise decision). Would it not make sense for the target to quickly
retransmit the XFER_RDY in this case, in order to force the initiator to
begin retransmission as soon as possible? 
 
Rich 


  



  _____  


From: George Penokie [mailto:gop at us.ibm.com] 
Sent: Thursday, July 28, 2005 9:32 AM
To: Deglin, Rich
Cc: Chen, Larry; Hu, Lin; t10 at t10.org
Subject: Fw: initiator retransmission of DATA frames with transport
layer retries 
 

Rich, 

To follow up on me email from yesterday. 

The option 2 in the email (see below) will be recommended to the SCSI
committee as the solution to the problem. That will change section
9.2.6.3.3.3.3 of SAS 1.1 9e to be as follows: 


Transition ST_TTS2:Target_Send_Frame to ST_TTS5:Receive_Data_Out 


This transition shall occur after this state: 


a) sends a Transmission Complete (Xfer_Rdy Delivered) message to the
ST_TFR state machine; or 
b) receives a Data-Out Arrived message. 


This transition shall include the received Data-Out Arrived message, if
any, as an argument. 



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


----- Forwarded by George Penokie/Rochester/IBM on 07/28/2005 09:33 AM
----- 



George Penokie/Rochester/IBM at IBMUS 
Sent by: owner-t10 at t10.org 


07/27/2005 01:22 PM   






To
"Deglin, Rich" <Richard_Deglin at adaptec.com> 

cc
"Chen, Larry" <Larry_Chen at adaptec.com>, "Hu, Lin" <Lin_Hu at adaptec.com>,
owner-t10 at t10.org, t10 at t10.org 

Subject
Re: initiator retransmission of DATA frames with transport layer retries


  


  





  	 







Rich, 

Before I answer what I believe your question is I would like to describe
the scenario that can cause it to happen and also what is happening on
the target side. 

Your step 1 is normal operation 
Your step 2 is normal operation 
Your step 3 is normal operation 
Your step 4 assumes frame level retries are enabled and is normal
operation under that condition 

At this point there are two possible options neither of which are
currently spelled out in the transport layer state machines. 

Option 1 
Your step 5 can only happen if the target does not receive the ACK that
the initiator sent for the XFER_RDY. Because the target did not receive
the ACK it will be ignoring the write data at the transport layer (i.e.,
the write data will not be written to the media and/or not written into
the buffer). However, it will be retuning ACKs for the data frames as
that is a link layer operation that is independent from the transport
layer frame handling. The target will resend the XFER_RDY after an
ACK/NAK Timeout or a Connection Lost Without ACK/NAK. 
Your step 6 is correct. The initiator cannot set the
CHANING_DATA_POINTER bit set to one in any DATA frame unless the
initiator is doing a retry on it's own. In this case the retry was as a
result of a target initiated operation and therefore initiator cannot
set the bit. The target determines the valid frame by checking the TPTT
field. 

Option 2 
Your step 5 will never happen. The reason is that when the detects a
frame has been received for a XFER_RDY (even though it does not receive
an ACK) it will assume that XFER_RDY was received and will start
processing the DATA frames. 
Your step 6 would be a retransmission of the frame with the TPPTT = A
and the CHANING_DATA_POINTER bit set to one. 

At this point I believe option 2 should be placed into SAS 1.1 as this
technique is being used in other places in the transport layer. 

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 



"Deglin, Rich" <Richard_Deglin at adaptec.com> 
Sent by: owner-t10 at t10.org 


07/25/2005 04:08 PM   


  






To
<t10 at t10.org> 

cc
"Hu, Lin" <Lin_Hu at adaptec.com>, "Chen, Larry" <Larry_Chen at adaptec.com> 

Subject
initiator retransmission of DATA frames with transport layer retries


  


  





  	 







* From the T10 Reflector (t10 at t10.org), posted by:
* "Deglin, Rich" <Richard_Deglin at adaptec.com>
*
This is a multi-part message in MIME format.

------_=_NextPart_001_01C5915C.F053CB8C
Content-Type: text/plain;
             charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I have not been able to clearly make out the meaning of this phrase in
sec 9.2.4.5.2:
=20
"For both reads and writes, the CHANGING DATA POINTER bit is set to one
in the first retransmitted DATA frame
and CHANGING DATA POINTER bit is set to zero in subsequent DATA frames."
=20
Consider the following scenario:
=20
1. Initiator transmits write command to target
2. Target transmits XFER_RDY frame to initiator (TPTT =3D A, offset =3D
=
X,
RETRANSMIT =3D 0)
3. Initiator transmits DATA frames for TPTT =3D A
4. Initiator receives NAK for one of the write DATA frames and prepares
to retransmit the DATA frames
5. Target retransmits XFER_RDY frame to initiator (TPTT =3D B, offset =
=3D X,
RETRANSMIT =3D 1)
6. Initiator abandons its retransmission for TPTT =3D A and begins
transmission for TPTT =3D B
=20
Q: does initiator set the CHANGING_DATA_POINTER bit in the first DATA
frame of the transmission for TPTT =3D B?
=20
Rich Deglin
Principal Software Engineer
Vitesse Semiconductor, Inc.

------_=_NextPart_001_01C5915C.F053CB8C
Content-Type: text/html;
             charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40"> 

I have not been able to clearly make out the meaning = of this phrase in
sec 9.2.4.5.2:



For both reads and writes, the = CHANGING DATA POINTER bit is set to
one in the first retransmitted DATA = frame

and CHANGING DATA POINTER = bit is set to zero in subsequent DATA
frames.



Consider the following = scenario:



1. Initiator transmits = write command to target

2. Target transmits = XFER_RDY frame to initiator (TPTT =3D A, offset
=3D X, RETRANSMIT =3D = 0)

3. Initiator transmits DATA = frames for TPTT =3D A

4. Initiator receives NAK = for one of the write DATA frames and
prepares to retransmit the DATA = frames

5. Target retransmits = XFER_RDY frame to initiator (TPTT =3D B, offset
=3D X, RETRANSMIT =3D = 1)

6. Initiator abandons its retransmission for TPTT =3D A and begins
transmission for TPTT =3D = B



Q: does initiator set the CHANGING_DATA_POINTER bit = in the first DATA
frame of the transmission for TPTT =3D = B?



Rich Deglin

Principal Software = Engineer

Vitesse= Semiconductor, Inc.

------_=_NextPart_001_01C5915C.F053CB8C--


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




--=_alternative 0070BBE58625704C_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">Rich,</font>
<br>
<br><font size=2 face="sans-serif">The paragraph you indicated is not correct
(it's left over from before the standard had frame level retries defined)
and is the comparable paragraph in section 9.2.5.2. The correct summary
section that describes this is in section 9.2.4.5 DATA frame - handling
of link layer errors. However, the absolute rule is defined in the 9.2.6.3.3.6
ST_TTS5:Receive_Data_Out state section (see below). So in the retry case
the target just keeps going tossing out the frames until the CHANGING DATA
POINTER bit is set to one.</font>
<br>
<br><font size=2 face="sans-serif">9.2.6.3.3.6 ST_TTS5:Receive_Data_Out
state</font>
<br><font size=2 face="sans-serif">9.2.6.3.3.6.1 State description</font>
<br><font size=2 face="sans-serif">If:</font>
<br><font size=2 face="sans-serif">a) transport layer retries are supported;</font>
<br><font size=2 face="sans-serif">b) the CHANGING DATA POINTER bit is
set to zero; and</font>
<br><font size=2 face="sans-serif">c) the value in the DATA OFFSET field
is not equal to the Write Data Received variable,</font>
<br><font size=2 face="sans-serif">then this state should discard all Data-Out
Arrived messages until the CHANGING DATA POINTER bit is set to one.</font>
<br><font size=2 face="sans-serif">This state shall resume processing additional
Data-Out Arrived messages when it receives a Data-Out Arrived message with
the CHANGING DATA POINTER bit set to one.</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>"Deglin, Rich"
<Richard_Deglin at adaptec.com&gt;</b> </font>
<p><font size=1 face="sans-serif">07/28/2005 02:36 PM</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">George Penokie/Rochester/IBM at IBMUS</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top><font size=1 face="sans-serif">"Chen, Larry" <Larry_Chen at adaptec.com&gt;,
"Hu, Lin" <Lin_Hu at adaptec.com&gt;, <t10 at t10.org&gt;</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">RE: initiator retransmission
of DATA frames with transport layer retries</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2 color=#000080 face="Arial">George</font>
<p><font size=2 color=#000080 face="Arial">&nbsp;</font>
<p><font size=2 color=#000080 face="Arial">How does a target which supports
retries deal with the following situation?</font>
<p><font size=2 color=#000080 face="Arial">&nbsp;</font>
<p><font size=2 color=#000080 face="Arial">Initiator sends write command.</font>
<p><font size=2 color=#000080 face="Arial">Target sends XFER_RDY.</font>
<p><font size=2 color=#000080 face="Arial">Initiator sends write data.
One DATA frame (not the last) has a CRC error, thus target sees a gap in
the stream (data offset does not match what is expected).</font>
<p><font size=2 color=#000080 face="Arial">&nbsp;</font>
<p><font size=2 color=#000080 face="Arial">The standard says that the target
must send a check condition (RESPONSE frame) to the initiator (sec 9.2.5.3
para 11). How does this square with the requirement that the initiator
is going to retransmit the data? Does this imply that the initiator cannot
transmit any additional DATA frames following the receipt of NAK? This
is not possible as DATA frames are not interlocked.</font>
<p><font size=2 color=#000080 face="Arial">&nbsp;</font>
<p><font size=2 color=#000080 face="Arial">Thanks for your time,</font>
<p><font size=2 color=#000080 face="Arial">&nbsp;</font>
<p><font size=2 color=#000080 face="Arial">Rich Deglin</font>
<p><font size=2 color=#000080 face="Arial">Principal Software Engineer</font>
<p><font size=2 color=#000080 face="Arial">Vitesse Semiconductor</font>
<p><font size=2 color=#000080 face="Arial">Email: rdeglin at vitesse.com</font>
<p><font size=2 color=#000080 face="Arial">&nbsp;</font>
<div align=center>
<p>
<hr></div>
<p><font size=2 face="Tahoma"><b>From:</b> George Penokie [mailto:gop at us.ibm.com]
<b><br>
Sent:</b> Thursday, July 28, 2005 11:00 AM<b><br>
To:</b> Deglin, Rich<b><br>
Cc:</b> Chen, Larry; Hu, Lin; t10 at t10.org<b><br>
Subject:</b> RE: initiator retransmission of DATA frames with transport
layer retries</font>
<p><font size=3 face="Times New Roman">&nbsp;</font>
<p><font size=2 face="sans-serif"><br>
Rich,</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
At the point an initiator receives a NAK for a frame it has two choices:</font><font size=3 face="Times New Roman">
<br>
</font><font size=2 face="sans-serif"><br>
1- If retries are disabled (or not supported) then the initiator stops
sending frames (i.e., the state machine transitions from ST_ITS2:Initiator_Send_Frame
to ST_ITS1:Initiator_Start).</font><font size=3 face="Times New Roman">
</font><font size=2 face="sans-serif"><br>
2-If retries are enabled then the initiator resets the pointers for the
write data back to the offset that was sent in the last XFER_RDY and then
starts sending the frames again from that offset point.</font><font size=3 face="Times New Roman">
<br>
</font><font size=2 face="sans-serif"><br>
The target will never retransmit an XFER_RDY as the result of having sent
a NAK for a data frame. The only reason the target will retransmit an XFER_RDY
is if the XFER_RDY transmission failed. The target never attempts to retry
data frames on writes it will only retry data frames on read operations
(i.e., the initiator is responsible for controlling the retry of write
data frames not the target)</font><font size=3 face="Times New Roman">
</font><font size=2 face="sans-serif"><br>
<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>
</font><font size=3 face="Times New Roman"><br>
<br>
</font>
<p>
<table width=100%>
<tr valign=top>
<td width=33%><font size=1 face="sans-serif"><b>"Deglin, Rich"
<Richard_Deglin at adaptec.com&gt;</b> </font>
<p><font size=1 face="sans-serif">07/28/2005 12:05 PM</font><font size=3 face="Times New Roman">
</font>
<td width=66%>
<br>
<table width=100%>
<tr>
<td width=12%>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td width=87% valign=top><font size=1 face="sans-serif">George Penokie/Rochester/IBM at IBMUS</font><font size=3 face="Times New Roman">
</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top><font size=1 face="sans-serif">"Chen, Larry" <Larry_Chen at adaptec.com&gt;,
"Hu, Lin" <Lin_Hu at adaptec.com&gt;, <t10 at t10.org&gt;</font><font size=3 face="Times New Roman">
</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">RE: initiator retransmission
of DATA frames with transport layer retries</font></table>
<p><font size=3 face="Times New Roman">&nbsp;</font>
<p>
<br>
<table width=100%>
<tr valign=top>
<td width=50%><font size=3 face="Times New Roman">&nbsp;</font>
<td width=49%><font size=3 face="Times New Roman">&nbsp;</font></table>
<br></table>
<p><font size=3 face="Times New Roman"><br>
<br>
</font><font size=2 color=#000080 face="Arial"><br>
George</font><font size=3 face="Times New Roman"> </font><font size=2 color=#000080 face="Arial"><br>
 </font><font size=3 face="Times New Roman">&nbsp;</font><font size=2 color=#000080 face="Arial"><br>
I am generally in agreement with your analysis.</font><font size=3 face="Times New Roman">
</font><font size=2 color=#000080 face="Arial"><br>
 </font><font size=3 face="Times New Roman">&nbsp;</font><font size=2 color=#000080 face="Arial"><br>
I may be mistaken, but I believe an initiator is free to continue transmitting
DATA frames even after receiving NAK (although this is an unwise decision).
Would it not make sense for the target to quickly retransmit the XFER_RDY
in this case, in order to force the initiator to begin retransmission as
soon as possible?</font><font size=3 face="Times New Roman"> </font><font size=2 color=#000080 face="Arial"><br>
 </font><font size=3 face="Times New Roman">&nbsp;</font><font size=2 color=#000080 face="Arial"><br>
Rich</font><font size=3 face="Times New Roman"> </font>
<div align=center>
<p><font size=3 face="Times New Roman">&nbsp;</font>
<p>
<hr></div>
<p><font size=2 face="Tahoma"><b><br>
From:</b> George Penokie [mailto:gop at us.ibm.com] <b><br>
Sent:</b> Thursday, July 28, 2005 9:32 AM<b><br>
To:</b> Deglin, Rich<b><br>
Cc:</b> Chen, Larry; Hu, Lin; t10 at t10.org<b><br>
Subject:</b> Fw: initiator retransmission of DATA frames with transport
layer retries</font><font size=3 face="Times New Roman"> <br>
 &nbsp;</font><font size=2 face="sans-serif"><br>
<br>
Rich,</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
<br>
To follow up on me email from yesterday. <br>
<br>
The option 2 in the email (see below) will be recommended to the SCSI committee
as the solution to the problem. That will change section 9.2.6.3.3.3.3
of SAS 1.1 9e to be as follows:</font><font size=3 face="Times New Roman">
</font>
<p><font size=2 face="Arial"><b>Transition ST_TTS2:Target_Send_Frame to
ST_TTS5:Receive_Data_Out</b></font><font size=3 face="Times New Roman">
</font>
<p><font size=2 face="Arial">This transition shall occur after this state:</font><font size=3 face="Times New Roman">
</font>
<p><font size=2 face="Arial">a) sends a Transmission Complete (Xfer_Rdy
Delivered) message to the ST_TFR state machine; or <br>
b) receives a Data-Out Arrived message.</font><font size=3 face="Times New Roman">
</font>
<p><font size=2 face="Arial MT">This transition shall include the received
Data-Out Arrived message, if any, as an argument.</font><font size=3 face="Times New Roman">
</font>
<p><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</font><font size=3 face="Times New Roman"><br>
</font><font size=1 color=#800080 face="sans-serif"><br>
<br>
----- Forwarded by George Penokie/Rochester/IBM on 07/28/2005 09:33 AM
-----</font><font size=3 face="Times New Roman"> </font>
<p>
<table width=100%>
<tr valign=top>
<td width=27%><font size=1 face="sans-serif"><b>George Penokie/Rochester/IBM at IBMUS</b>
<br>
Sent by: owner-t10 at t10.org</font><font size=3 face="Times New Roman"> </font>
<p><font size=1 face="sans-serif">07/27/2005 01:22 PM</font><font size=3 face="Times New Roman">
</font>
<td width=72%><font size=3 face="Times New Roman">&nbsp;</font>
<p>
<br>
<table width=100%>
<tr>
<td width=12%>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td width=87% valign=top><font size=1 face="sans-serif">"Deglin, Rich"
<Richard_Deglin at adaptec.com&gt;</font><font size=3 face="Times New Roman">
</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top><font size=1 face="sans-serif">"Chen, Larry" <Larry_Chen at adaptec.com&gt;,
"Hu, Lin" <Lin_Hu at adaptec.com&gt;, owner-t10 at t10.org, t10 at t10.org</font><font size=3 face="Times New Roman">
</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">Re: initiator retransmission
of DATA frames with transport layer retries</font></table>
<p><font size=3 face="Times New Roman"><br>
 &nbsp;</font>
<p><font size=3 face="Times New Roman">&nbsp;</font>
<p>
<br>
<table width=100%>
<tr valign=top>
<td width=66%><font size=3 face="Times New Roman">&nbsp; </font>
<td width=33%><font size=3 face="Times New Roman">&nbsp;</font></table>
<br></table>
<p><font size=3 face="Times New Roman"><br>
</font><font size=2 face="sans-serif"><br>
<br>
<br>
Rich,</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
<br>
Before I answer what I believe your question is I would like to describe
the scenario that can cause it to happen and also what is happening on
the target side.</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
<br>
Your step 1 is normal operation</font><font size=3 face="Times New Roman">
</font><font size=2 face="sans-serif"><br>
Your step 2 is normal operation</font><font size=3 face="Times New Roman">
</font><font size=2 face="sans-serif"><br>
Your step 3 is normal operation</font><font size=3 face="Times New Roman">
</font><font size=2 face="sans-serif"><br>
Your step 4 assumes frame level retries are enabled and is normal operation
under that condition</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
<br>
At this point there are two possible options neither of which are currently
spelled out in the transport layer state machines.</font><font size=3 face="Times New Roman">
</font><font size=2 face="sans-serif"><br>
<br>
Option 1</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
Your step 5 can only happen if the target does not receive the ACK that
the initiator sent for the XFER_RDY. Because the target did not receive
the ACK it will be ignoring the write data at the transport layer (i.e.,
the write data will not be written to the media and/or not written into
the buffer). However, it will be retuning ACKs for the data frames as that
is a link layer operation that is independent from the transport layer
frame handling. The target will resend the XFER_RDY after an ACK/NAK Timeout
or a Connection Lost Without ACK/NAK.</font><font size=3 face="Times New Roman">
</font><font size=2 face="sans-serif"><br>
Your step 6 is correct. The initiator cannot set the CHANING_DATA_POINTER
bit set to one in any DATA frame unless the initiator is doing a retry
on it's own. In this case the retry was as a result of a target initiated
operation and therefore initiator cannot set the bit. The target determines
the valid frame by checking the TPTT field.</font><font size=3 face="Times New Roman">
</font><font size=2 face="sans-serif"><br>
<br>
Option 2</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
Your step 5 will never happen. The reason is that when the detects a frame
has been received for a XFER_RDY (even though it does not receive an ACK)
it will assume that XFER_RDY was received and will start processing the
DATA frames.</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
Your step 6 would be a retransmission of the frame with the TPPTT = A and
the CHANING_DATA_POINTER bit set to one.</font><font size=3 face="Times New Roman">
</font><font size=2 face="sans-serif"><br>
<br>
At this point I believe option 2 should be placed into SAS 1.1 as this
technique is being used in other places in the transport layer.</font><font size=3 face="Times New Roman">
</font><font size=2 face="sans-serif"><br>
<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</font>
<p>
<table width=100%>
<tr valign=top>
<td width=37%><font size=1 face="sans-serif"><b>"Deglin, Rich"
<Richard_Deglin at adaptec.com&gt;</b> <br>
Sent by: owner-t10 at t10.org</font><font size=3 face="Times New Roman"> </font>
<p><font size=1 face="sans-serif">07/25/2005 04:08 PM</font><font size=3 face="Times New Roman">
</font>
<td width=62%><font size=3 face="Times New Roman">&nbsp; </font>
<p><font size=3 face="Times New Roman">&nbsp;</font>
<p>
<br>
<table width=100%>
<tr>
<td width=12%>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td width=87% valign=top><font size=1 face="sans-serif"><t10 at t10.org&gt;</font><font size=3 face="Times New Roman">
</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top><font size=1 face="sans-serif">"Hu, Lin" <Lin_Hu at adaptec.com&gt;,
"Chen, Larry" <Larry_Chen at adaptec.com&gt;</font><font size=3 face="Times New Roman">
</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">initiator retransmission
of DATA frames with transport layer retries</font></table>
<p><font size=3 face="Times New Roman"><br>
 &nbsp;</font>
<p><font size=3 face="Times New Roman">&nbsp;</font>
<p>
<br>
<table width=100%>
<tr valign=top>
<td width=66%><font size=3 face="Times New Roman">&nbsp; </font>
<td width=33%><font size=3 face="Times New Roman">&nbsp;</font></table>
<br></table>
<p><font size=3 face="Times New Roman"><br>
</font><font size=2 face="Courier New"><br>
<br>
<br>
* From the T10 Reflector (t10 at t10.org), posted by:<br>
* "Deglin, Rich" <Richard_Deglin at adaptec.com&gt;<br>
*<br>
This is a multi-part message in MIME format.<br>
<br>
------_=_NextPart_001_01C5915C.F053CB8C<br>
Content-Type: text/plain;<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;charset="us-ascii"<br>
Content-Transfer-Encoding: quoted-printable<br>
<br>
I have not been able to clearly make out the meaning of this phrase in<br>
sec 9.2.4.5.2:<br>
=20<br>
"For both reads and writes, the CHANGING DATA POINTER bit is set to
one<br>
in the first retransmitted DATA frame<br>
and CHANGING DATA POINTER bit is set to zero in subsequent DATA frames."<br>
=20<br>
Consider the following scenario:<br>
=20<br>
1. Initiator transmits write command to target<br>
2. Target transmits XFER_RDY frame to initiator (TPTT =3D A, offset =3D
=<br>
X,<br>
RETRANSMIT =3D 0)<br>
3. Initiator transmits DATA frames for TPTT =3D A<br>
4. Initiator receives NAK for one of the write DATA frames and prepares<br>
to retransmit the DATA frames<br>
5. Target retransmits XFER_RDY frame to initiator (TPTT =3D B, offset =<br>
=3D X,<br>
RETRANSMIT =3D 1)<br>
6. Initiator abandons its retransmission for TPTT =3D A and begins<br>
transmission for TPTT =3D B<br>
=20<br>
Q: does initiator set the CHANGING_DATA_POINTER bit in the first DATA<br>
frame of the transmission for TPTT =3D B?<br>
=20<br>
Rich Deglin<br>
Principal Software Engineer<br>
Vitesse Semiconductor, Inc.<br>
<br>
------_=_NextPart_001_01C5915C.F053CB8C<br>
Content-Type: text/html;<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;charset="us-ascii"<br>
Content-Transfer-Encoding: quoted-printable<br>
<br>
xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word"
= xmlns=3D"http://www.w3.org/TR/REC-html40&quot;> <br>
<br>
I have not been able to clearly make out the meaning = of this phrase in
sec 9.2.4.5.2:<br>
<br>
<br>
<br>
For both reads and writes, the = CHANGING DATA POINTER bit is set to one
in the first retransmitted DATA = frame<br>
<br>
and CHANGING DATA POINTER = bit is set to zero in subsequent DATA frames.<br>
<br>
<br>
<br>
Consider the following = scenario:<br>
<br>
<br>
<br>
1. Initiator transmits = write command to target<br>
<br>
2. Target transmits = XFER_RDY frame to initiator (TPTT =3D A, offset =3D
X, RETRANSMIT =3D = 0)<br>
<br>
3. Initiator transmits DATA = frames for TPTT =3D A<br>
<br>
4. Initiator receives NAK = for one of the write DATA frames and prepares
to retransmit the DATA = frames<br>
<br>
5. Target retransmits = XFER_RDY frame to initiator (TPTT =3D B, offset
=3D X, RETRANSMIT =3D = 1)<br>
<br>
6. Initiator abandons its retransmission for TPTT =3D A and begins transmission
for TPTT =3D = B<br>
<br>
<br>
<br>
Q: does initiator set the CHANGING_DATA_POINTER bit = in the first DATA
frame of the transmission for TPTT =3D = B?<br>
<br>
<br>
<br>
Rich Deglin<br>
<br>
Principal Software = Engineer<br>
<br>
Vitesse= Semiconductor, Inc.<br>
<br>
------_=_NextPart_001_01C5915C.F053CB8C--<br>
<br>
<br>
*<br>
* For T10 Reflector information, send a message with<br>
* 'info t10' (no quotes) in the message body to majordomo at t10.org</font><font size=3 face="Times New Roman">
</font>
<p>
--=_alternative 0070BBE58625704C_=--





More information about the T10 mailing list