initiator retransmission of DATA frames with transport layer retries

Deglin, Rich Richard_Deglin at adaptec.com
Thu Jul 28 10:05:51 PDT 2005


* 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_01C59396.9BA60CAC
Content-Type: text/plain;
        charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

George

=20

I am generally in agreement with your analysis.

=20

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?

=20

Rich

  _____ =20

From: George Penokie [mailto:gop at us.ibm.com]=20
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

=20


Rich,=20

To follow up on me email from yesterday.=20

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:=20

Transition ST_TTS2:Target_Send_Frame to ST_TTS5:Receive_Data_Out=20

This transition shall occur after this state:=20

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

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


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

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

07/27/2005 01:22 PM=20

To

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

cc

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

Subject

Re: initiator retransmission of DATA frames with transport layer retries

=20

=20

=20





Rich,=20

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.=20

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

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

Option 1=20
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.=20
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.=20

Option 2=20
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.=20
Your step 6 would be a retransmission of the frame with the TPPTT =3D A
and the CHANING_DATA_POINTER bit set to one.=20

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.=20

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>=20
Sent by: owner-t10 at t10.org=20

07/25/2005 04:08 PM=20

=20

To

<t10 at t10.org>=20

cc

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

Subject

initiator retransmission of DATA frames with transport layer retries

=20

=20

=20





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

------_=3D_NextPart_001_01C5915C.F053CB8C
Content-Type: text/plain;
               charset=3D"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:
=3D20
"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."
=3D20
Consider the following scenario:
=3D20
1. Initiator transmits write command to target
2. Target transmits XFER_RDY frame to initiator (TPTT =3D3D A, offset =
=3D3D
=3D
X,
RETRANSMIT =3D3D 0)
3. Initiator transmits DATA frames for TPTT =3D3D 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 =3D3D B, offset =
=3D
=3D3D X,
RETRANSMIT =3D3D 1)
6. Initiator abandons its retransmission for TPTT =3D3D A and begins
transmission for TPTT =3D3D B
=3D20
Q: does initiator set the CHANGING_DATA_POINTER bit in the first DATA
frame of the transmission for TPTT =3D3D B?
=3D20
Rich Deglin
Principal Software Engineer
Vitesse Semiconductor, Inc.

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

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

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



=1CFor both reads and writes, the =3D CHANGING DATA POINTER bit is set =
to
one in the first retransmitted DATA =3D frame

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



Consider the following =3D scenario:



1. Initiator transmits =3D write command to target

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

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

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

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

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



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



Rich Deglin

Principal Software =3D Engineer

Vitesse=3D Semiconductor, Inc.

------_=3D_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


------_=_NextPart_001_01C59396.9BA60CAC
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:st1=3D"urn:schemas-microsoft-com:office:smarttags" = xmlns=3D"http://www.w3.org/TR/REC-html40"> 

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 =3D 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.

------_=3D_NextPart_001_01C5915C.F053CB8C
Content-Type: text/plain;
        =    charset=3D"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:
=3D20
"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."
=3D20
Consider the following = scenario:
=3D20
1. Initiator transmits write command to = target
2. Target transmits XFER_RDY frame to = initiator (TPTT =3D3D A, offset =3D3D =3D
X,
RETRANSMIT =3D3D 0)
3. Initiator transmits DATA frames for = TPTT =3D3D 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 =3D3D B, offset =3D
=3D3D X,
RETRANSMIT =3D3D 1)
6. Initiator abandons its retransmission = for TPTT =3D3D A and begins
transmission for TPTT =3D3D = B
=3D20
Q: does initiator set the = CHANGING_DATA_POINTER bit in the first DATA
frame of the transmission for TPTT =3D3D = B?
=3D20
Rich Deglin
Principal Software = Engineer
Vitesse Semiconductor, = Inc.

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

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

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



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

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



Consider the following =3D = scenario:



1. Initiator transmits =3D write command = to target

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

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

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

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

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



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



Rich Deglin

Principal Software =3D = Engineer

Vitesse=3D Semiconductor, = Inc.

------_=3D_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

------_=_NextPart_001_01C59396.9BA60CAC--


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