Subject: iSCSI: ERL=1 question.

From: "Prasenjit Sarkar" <[email-masked]>
Date: Thu, 3 Jan 2002 11:36:46 -0800

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

---

From: "Ranganathan, Deva" <[email-masked]>
Date: Thu, 3 Jan 2002 17:19:10 -0800

>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:[email-masked]]
Sent: Thursday, January 03, 2002 11:37 AM
To: [email-masked]
Subject: iSCSI: ERL=1 question.

1. I->T: Scsi Cmd

   Prasenjit Sarkar
   Research Staff Member
   IBM Almaden Research
   San Jose

---

From: Eddy Quicksall <[email-masked]>
Date: Fri, 4 Jan 2002 09:32:03 -0500

I hate to get blasted but here goes ... :)

I would prefer that iSCSI Response and SCSI Status are mutually exclusive.
Let the initiator generate the appropriate SCSI Status for the ULP given the
iSCSI Response.

It used to be that way. Maybe someone could tell us why it was changed.

If there is a very good reason for them not to be mutually exclusive, then
my code would just overlay the first status with the second and everything
would work properly. Maybe a note could be added to the spec to make people
aware that this could occur.

Eddy

-----Original Message-----
From: Prasenjit Sarkar [mailto:[email-masked]]
Sent: Thursday, January 03, 2002 11:17 PM
To: Santosh Rao
Cc: [email-masked]
Subject: Re: iSCSI: ERL=1 question.

Santosh,

Regarding (B), I did not even venture to imply that there would be a
stat_sn hole.

I'm a little confused about your data snack recovery rule, but that is
besides the point and I can discuss this offline with you.

My chief concern is that ERL 1 leaves open the possibility for duplicate
SCSI status PDUs. There are three solutions:

1. Leave it to implementors who can use their judgement to decide which
status to ignore.
2. Formulate a tight rule: status PDU with higher stat_sn number always
wins.
3. Change the standard so that duplication does not happen.

I would like the standard to at least discuss this and then state what path
they chose and why (with good reason of course). I do not think that this
is merely an implementation issue.

My preference is of course: 3,2,1.

   Prasenjit Sarkar
   Research Staff Member
   IBM Almaden Research
   San Jose

                    Santosh Rao

                    <santoshr@cup.       To:     Prasenjit
Sarkar/Almaden/IBM@IBMUS       
                    hp.com>              cc:     [email-masked]

                    Sent by:             Subject:     Re: iSCSI: ERL=1
question.          
                    owner-ips@ece.

                    cmu.edu

                    01/03/2002

                    06:45 PM

Prasenjit,

Regarding your question (B)....

Anytime the initiator's receive path successfully receives a pdu and
passes format and digest error tests, the local state information of
exp_cmdsn, max_cmdsn, statsn should be updated based on the values that
are carried in that pdu and the rules specified in Section 2.2.2.

Thus, in your below context, when the first scsi status pdu was
received, the exp_statsn should have gotten updated and there should not
have been any hole in statsn sequence. What am I missing (?)

Regarding your question (A)...

You may have read more into my answer than was intended.

It is not the job of the lower layered pdu assembly path to filter out
duplicate scsi status pdu's. Rather, this intelligence would lie within
the module (finite state machine) that implemented the i/o path logic.

While a data_snack has been sent and the i/o state machine is awaiting
missing data pdu's , any received scsi status for that exchange must not
be sent up to the SCSI ULP. Upon successful receipt of all the missing
data pdu[s], the status can then be conveyed to the ULP.

(I don't have a strong opinion either way, if we should have to state
the above in the draft, or leave it unsaid as implementation specifics.
I guess, at some point we cross over into the realm of an implementation
guide vs a protocol specification :)

- Santosh

Prasenjit Sarkar wrote:
>
> I'm assuming Santosh wanted to reply to the entire group, so I am
> forwarding his response to the mailing list.
>
> Santosh's argument is to provide the (unstated) rule that data assembly
is
> the domain of a lower iSCSI layer whose job is to filter out duplicate
SCSI
> status PDUs. I would gladly accept this argument except that a standard
> should present a generic rule which should be independent of how a
protocol
> is implemented. I would prefer a rule based on stat_sn ordering or any
> other equivalent rather than one based on ideal iSCSI layering.
>
> Santosh's motivation of having a seamless way of completing commands is
> probably not true as initiators are allowed to generate SCSI responses.
>
>    Prasenjit Sarkar
>    Research Staff Member
>    IBM Almaden Research
>    San Jose
>
>
>                     Santosh Rao
>                     <santoshr@cup.       To:     Prasenjit
Sarkar/Almaden/IBM@IBMUS
>                     hp.com>              cc:
>                     Sent by:             Subject:     Re: iSCSI: ERL=1
question.
>                     [email-masked]
>                     p.com
>                     01/03/2002
>                     05:00 PM
> Prasenjit,
> Responses inline.
> Regards,
> Santosh
> Prasenjit Sarkar wrote:
> I'm not certain on what SAM says on this one. However, one can envision
> that the iscsi i/o finite state machine would enter into some state upon
> encountering a datasn hole, say, data_snack_sent, and it should ignore
> any scsi status received while in this state.
> The lower pdu receive and re-assembly module should have passed format
> and digest checks (assuming the frame came thru fine) and so, the local
> value of exp_statsn should have gotten updated within this initiator
> instance's iscsi connection finite state machine.
>
> Thus.....
> i) since the 1st status was ignored while awaiting a data_snack
> response, only 1 scsi status ends up being processed by the i/o finite
> state m/c.
>
> ii) there will not be a statsn hole, since the previous status was
> received successfully by the receive path, resulting in an update to
> exp_statsn. however, the staus was discarded within the i/o fsm.
>
> >
> See above.
> So that all I/Os receive a single method of completion via the SCSI
> status, I guess.
>
> --
> ##################################
> Santosh Rao
> Software Design Engineer,
> HP-UX iSCSI Driver Team,
> Hewlett Packard, Cupertino.
> email : [email-masked]
> Phone : 408-447-3751
> ##################################

--
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : [email-masked]
Phone : 408-447-3751
##################################

---

From: "Julian Satran" <[email-masked]>
Date: Sat, 5 Jan 2002 15:26:53 +0200

Eddy,

As it stands they are mutually exclusive. But by keeping 2 fields we leave
our options open.
It also maps to SAM - SAM has both a response and a status in the model
procedure call and restricting the validity of status to good responses is
made in text.

Regards,
Julo

                    Eddy Quicksall                                                                    
                    <Eddy_Quicksall@iv       To:     Prasenjit Sarkar/Almaden/IBM@IBMUS, Santosh Rao  
                    ivity.com>                <[email-masked]>                                   
                    Sent by:                 cc:     [email-masked]                                  
                    [email-masked].       Subject:     RE: iSCSI: ERL=1 question.                  
                    edu                                                                               

                    04-01-02 16:32                                                                    

I would prefer that iSCSI Response and SCSI Status are mutually exclusive.
Let the initiator generate the appropriate SCSI Status for the ULP given
the
iSCSI Response.

Eddy

-----Original Message-----
From: Prasenjit Sarkar [mailto:[email-masked]]
Sent: Thursday, January 03, 2002 11:17 PM
To: Santosh Rao
Cc: [email-masked]
Subject: Re: iSCSI: ERL=1 question.

Santosh,

   Prasenjit Sarkar
   Research Staff Member
   IBM Almaden Research
   San Jose

                    Santosh Rao

                    cmu.edu

                    01/03/2002

                    06:45 PM

Prasenjit,

- Santosh

is
SCSI
protocol
Sarkar/Almaden/IBM@IBMUS
question.