RE: iSCSI: ERL=1 question.

["Ranganathan, Deva" <Deva_Ranganathan@adaptec.com>]

>C. I'm looking for motivation here: why does the target (rather than the
>initiator) generate the second status? Couldnt the initiator also do the
>same on receiving the DATA_SNACK_REJECT?

I am with Prasanjith on the thought that the iSCSI initiator layer ignore
the status sent from the target,
when the SNACK is rejected, is a good idea. I dont like having the target
send
two statii.  Unless there is a specific reason that the target SHOULD send
two statii, 
we SHOULD have the initiator handle this scenario.

Any comments?

Thanks

Deva


-----Original Message-----
From: Prasenjit Sarkar [mailto:psarkar@almaden.ibm.com]
Sent: Thursday, January 03, 2002 11:37 AM
To: ips@ece.cmu.edu
Subject: iSCSI: ERL=1 question.


Assume the following scenario where I and T stand for initiator and target
respectively.

1. I->T: Scsi Cmd

2. T->I: Scsi Data (DataSN:0)

3. T->I: Scsi Status (Good)

Assume there is a data digest problem for the data with DataSN:0, so

4. I->T: Data Snack for DataSN:0

The target for some reason cannot respond with the data, so according to
the spec

5: T->I: Reject with reason DATA_SNACK_REJECT

6. T->I: Scsi Status (iSCSI response: SNACK rejected -> SCSI READ Error)

The questions are as follows:

A. Is SAM ambivalent of the fact that there can be two statii for the same
command? (I dont have a problem if SAM doesnt)

B, Does the second SCSI status have the same StatSN as the first? Likely,
it does not, but it should be clearly stated that a SCSI status with higher
stat_sn overrides one with the lower stat_sn.

C. I'm looking for motivation here: why does the target (rather than the
initiator) generate the second status? Couldnt the initiator also do the
same on receiving the DATA_SNACK_REJECT?




   Prasenjit Sarkar
   Research Staff Member
   IBM Almaden Research
   San Jose