Return-Path: X-Sieve: cmu-sieve 2.0 Return-Path: Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id h258gQe29063 for ips-outgoing; Wed, 5 Mar 2003 03:42:26 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hclnpd.hclt.co.in ([202.54.64.7]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id h258gNM29058 for ; Wed, 5 Mar 2003 03:42:24 -0500 (EST) Received: from pilex.hclt-ntl.co.in ([192.168.19.34]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 191ZJ7FC; Wed, 5 Mar 2003 14:12:21 +0530 Received: from nramamurpc (NRAMAMUR-PC [192.168.19.98]) by pilex.hclt-ntl.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GJPPP6AV; Wed, 5 Mar 2003 14:11:46 +0530 Message-ID: <007901c2e2f3$0d512ff0$6213a8c0@hcltntl.co.in> From: "Nandakumar Ramamurthy" To: Cc: References: <1BEBA5E8600DD4119A50009027AF54A010FAE103@axcs04.cos.agilent.com> Subject: Re: Error recovery level 2 Question Date: Wed, 5 Mar 2003 14:11:44 +0530 Organization: HCL Technologies Ltd. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0076_01C2E321.26FFCF00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0076_01C2E321.26FFCF00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Kevin, In my understanding, the initiator must wait for a recovery R2T from the target. This is conveyed by the following sections of the draft : 10.17.1 "For iSCSI, Data-Out PDU retransmission is only done if the target requests retransmission with a recovery R2T." 6.2.2 (Allegiance Reassignment) "In reassigning connection allegiance for a command, the targets SHOULD continue the command from its current state." "For all types of commands, a reassignment request implies that the task is still considered in progress by the initiator and the target must conclude the task appropriately if the target returns the "Function Complete" response to the reassignment request. This might possibly involve retransmission of data/R2T/ status PDUs as necessary, but MUST involve the (re)transmission of the status PDU." From the above it seems to be implied that the target, after returning the 'Function Complete' response for the "task reassign" request, might retrasmit 'data' in case of a 'READ' (or) an 'R2T' in case of a = 'WRITE'. 6.1.4.1 (Recovery Within-command) "To avoid a race with the target, which may already have a recovery R2T or a termination response on its way, an initiator SHOULD NOT originate a SNACK for an R2T based on its internal timeouts (if any). Recovery in this case is better left to the target." Thanks, Nandakumar Member Technical Staff HCL Technologies, Chennai, INDIA. http://www.hcltech.com/san ----- Original Message -----=20 From: To: Cc: Sent: Wednesday, March 05, 2003 4:44 AM Subject: Error recovery level 2 Question > Julian, > =20 > Assume that I have a multi-connection session to a target when one of = the connections fails. > =20 > What is the completion of the following diagram (assume 8K PDUs and = maxBurst =3D 64K): > =20 > Initiator Target > ---------- --------- > Write Cmd (64K no Immediate) ---> > <--- R2T Offset 0, len=3D64K > Data PDU (8K DataSN 0) ---> > Data PDU (8K DataSN 1) --->=20 > --- Connection Lost --- > =20 > =20 > On 2nd connection: > Logout (for recovery) ---> > <--- Logout Response > Task Mgnt (Reassign) ---> > <--- Task Mgnt Response - OK > =20 > What Comes Next? > =20 > Is a recovery R2T expected from the target? > or does the Initiator continue to send data PDUs to the target? > =20 > If the initiator continues to send, what is the proper place to = continue. I may have submitted several PDUs to the stack that were never = received before the connection loss was detected.=20 > =20 > The read request seems fairly straight forward, but the write case is = not clear (at least to me...) > =20 > Thanks for any help, > =20 > Kevin Lemay ------=_NextPart_000_0076_01C2E321.26FFCF00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Kevin,
 
In my understanding, the initiator must = wait=20 for
a recovery R2T from the = target.
 
This is conveyed by the following = sections of the=20 draft :
 
10.17.1
"For iSCSI, Data-Out PDU = retransmission=20 is only done if the
target requests retransmission with a recovery=20 R2T."
 
6.2.2 (Allegiance Reassignment)
"In = reassigning=20 connection allegiance for a command, the targets
SHOULD continue the = command=20 from its current state."
 
"For all types of commands, a = reassignment request=20 implies that the
task is still considered in progress by the = initiator=20 and
the target must conclude the task appropriately if the = target
returns=20 the "Function Complete" response to the reassignment
request. This = might=20 possibly involve retransmission of data/R2T/
status PDUs as = necessary, but=20 MUST involve the (re)transmission of
the status PDU."
 
From the above it seems = to be implied=20 that the target, after returning
the 'Function Complete' = response for=20 the "task reassign" request,
might retrasmit 'data' = in case of=20 a 'READ' (or) an = 'R2T' in case of a=20 'WRITE'.
 
 
6.1.4.1 (Recovery = Within-command)
"To avoid a=20 race with the target, which may already have a recovery
R2T or a = termination=20 response on its way, an initiator SHOULD NOT
originate a SNACK for an = R2T=20 based on its internal timeouts (if
any). Recovery in this case is = better left=20 to the target."
 
 
Thanks,
Nandakumar
Member Technical = Staff
HCL=20 Technologies, Chennai, INDIA.
http://www.hcltech.com/san
 
 
----- Original Message -----
From: <kevin_lemay@agilent.com>
To: <Julian_Satran@il.ibm.com>
Cc: <ips@ece.cmu.edu>
Sent: Wednesday, March 05, 2003 4:44=20 AM
Subject: Error recovery level 2=20 Question

> Julian,
>  
> Assume that I have a = multi-connection=20 session to a target when one of the connections fails.
> =  
>=20 What is the completion of the following diagram (assume 8K PDUs and = maxBurst =3D=20 64K):
>  
>=20 Initiator          &nbs= p;            = ;  =20 Target
>=20 ----------          &nb= sp;           &nbs= p;=20 ---------
> Write Cmd (64K no Immediate) --->
>=20             &= nbsp;           &n= bsp;   =20 <---  R2T Offset 0, len=3D64K
> Data PDU (8K DataSN=20 0)       --->
> Data PDU (8K = DataSN=20 1)       --->
>    --- = Connection Lost ---
>  
>  
> On 2nd=20 connection:
> Logout (for=20 recovery)        --->
>=20             &= nbsp;           &n= bsp;   =20 <---  Logout Response
> Task Mgnt=20 (Reassign)         = --->
>=20             &= nbsp;           &n= bsp;   =20 <--- Task Mgnt Response - OK
>  
> What Comes = Next?
>=20  
> Is a recovery R2T expected from the target?
> or = does the=20 Initiator continue to send data PDUs to the target?
> =  
> If=20 the initiator continues to send, what is the proper place to continue. I = may=20 have submitted several PDUs to the stack that were never received before = the=20 connection loss was detected.
>  
> The read request = seems=20 fairly straight forward, but the write case is not clear (at least to=20 me...)
>  
> Thanks for any help,
> =  
> Kevin=20 Lemay ------=_NextPart_000_0076_01C2E321.26FFCF00--