RE: Recovery Within Connection - Command Restart

["Amir Shalit" <amir@astutenetworks.com>]

> 2. Request not acknowledged would be most of the time due to a
> header digest errors at the target end. If the header is bad how
> would one know at the target, that this was a command PDU v/s a Data
> PDU, since the target will have to implement a command scoreboard if
> it is a command PDU.
>

A target that failed to get a command PDU will notice SCSI data PDUs with unrecognized initiator tag .

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran
Sent: Friday, December 21, 2001 8:42 PM
To: shaileshm
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: Re: Recovery Within Connection - Command Restart

owner-ips@ece.cmu.edu wrote on 20-12-2001 00:06:44:

>  
>
> 1. The draft says a) Requests not acknowledged for a long time…..
> Does the SCSI timeout’s introduce the notion of time, or does iscsi
> has to have timeout’s at the transport layer. Also for detecting
> connection failures don’t the NOP’s have to be timed.
>

Timeouts here are iSCSI timeouts - by the time SCSI timeouts it is too late

> 2. Request not acknowledged would be most of the time due to a
> header digest errors at the target end. If the header is bad how
> would one know at the target, that this was a command PDU v/s a Data
> PDU, since the target will have to implement a command scoreboard if
> it is a command PDU.
>

You won't know but initiator sees that ExpCmdSN is not advancing
 
> 3. Usage of Reject PDU talks about Reject on Command PDU : however
> the error codes for Reject PDU do not indicate a command PDU error.

???
>
> 4. Is the recovery R2T different from the usual R2T.
>
>
No  
>
> These things are not clear from the draft !
>
>
It is all in the eye of the reader :-)
We heard already complaints that the text is too bulky and has things that belong to a tutorial
>
> Shailesh Manjrekar.

Julo