This was my take on this while it was
being developed:
The initiator should continue as normal.
This means it should assume the PDUs in the stack were sent and so it should
send the next PDU. The target will detect holes in the DataSN and will then use
the recovery R2T.
Things will then pickup as per the text
below.
If the lost connection was on the last PDU
or the last PDU was already on the stack, then the initiator will timeout due
to the missing response and send an abort. Then, hopefully, re-try the command.
Eddy
-----Original Message-----
From: Nandakumar Ramamurthy
[mailto:nramamur@npd.hcltech.com]
Sent: Wednesday, March 05, 2003
3:42 AM
To: kevin_lemay@agilent.com
Cc: ips@ece.cmu.edu
Subject: Re: Error recovery level
2 Question
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."
----- Original Message -----
Sent: Wednesday, March 05, 2003 4:44
AM
Subject: Error recovery level 2
Question
> Julian,
>
> Assume that I have a multi-connection session to a target when one of the
connections fails.
>
> What is the completion of the following diagram (assume 8K PDUs and
maxBurst = 64K):
>
>
Initiator
Target
>
----------
---------
> Write Cmd (64K no Immediate) --->
>
<--- R2T Offset 0, len=64K
> Data PDU (8K DataSN 0) --->
> Data PDU (8K DataSN 1) --->
> --- Connection Lost ---
>
>
> On 2nd connection:
> Logout (for recovery) --->
>
<--- Logout Response
> Task Mgnt (Reassign)
--->
>
<--- Task Mgnt Response - OK
>
> What Comes Next?
>
> Is a recovery R2T expected from the target?
> or does the Initiator continue to send data PDUs to the target?
>
> 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.
>
> The read request seems fairly straight forward, but the write case is not
clear (at least to me...)
>
> Thanks for any help,
>
> Kevin Lemay
