Subject: Re: iSCSI : target session login behaviour

From: [email-masked]
Date: Fri, 27 Apr 2001 12:59:29 +0300

SNACK rejected has been removed from the SCSI Response - Julo

Santosh Rao <[email-masked]> on 26/04/2001 21:41:20

Please respond to Santosh Rao <[email-masked]>

To:   Stephen Bailey <[email-masked]>, [email-masked]
cc:   David Black <[email-masked]>
Subject:  Re: iSCSI : target session login behaviour

Stephen Bailey wrote:

> > As a side note, the iSCSI draft Status Class/Codes could do with a misc
> > error category along the lines of the FC "No additional Explantion"
> > reason explantion. This would help deal with error conditions that
don't
> > come under the listed category.
>
> Personally, I think we should add categories for reasons we obviously
> see now, AND have a no additional reason.
>
> One peculiarity with what you're talking about above is that it should
> be a login response status code which expresses this rejection.  The
> login response set does not seem to have an `invalid parameter'
> response for cases when the request is somehow inconsistent.

Steph,

The iSCSI draft is unclear today about the exact mechanism through which
the target indicates "invalid parameters" in response to a received
command.

1) Should it use a REJECT PDU or respond with the appropriate response
for that PDU indicating a response code of "Invalid Parameters" and a
"first bad byte" offset that indicates which parameter the target
disliked.

IMO, an "Invalid Parameters" response in the response codes is
appropriate for SCSI Command and SCSI Task Mgmt commands. [coupled with
a "first bad byte" offset.]

This is missing today.

2) Also, as discussed above, a general "No Addional Explanation" type of
status code in the login response would cover the "misc" category.

3) There are cases of ambiguity in the usage of REJECT or SCSI Response.
Take the case of a "SNACK Reject". It is present in both the SCSI
Response (SNACK Rejected) and REJECT PDU reason code (Data SNACK
Reject). Which mechanism is to be used in this case ?

4) There is no "Status SNACK Rejected" in the REJECT PDU.

Regards,
Santosh
 - santoshr.vcf

---

From: "Ayman Ghanem" <[email-masked]>
Date: Fri, 27 Apr 2001 09:09:11 -0500

Is Status SNACK reject going to be added as a reason for a reject PDU?. If
not, what is the appropriate behavior on a target receiving a status SNACK
that it can not fulfill?. Should it terminate the connection?.

-Ayman

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Friday, April 27, 2001 4:59 AM
> To: [email-masked]

---

From: Santosh Rao <[email-masked]>
Date: Fri, 27 Apr 2001 11:55:21 -0700

Rev 06 seems to indicate that Status SNACK is still mandatory (?). 

I thought the group had consensus that Status SNACK recovery must not be
mandated and Julian had agreed to make it optional. (See
http://ips.pdl.cs.cmu.edu/mail/msg04008.html).

The following text in rev 06 seems to indicate that target support for
Status SNACK is still mandatory :

Section 2.16
"iSCSI targets MUST support Status SNACK and MAY support Data SNACK."

Section 6.7.2 :
"The initiator MAY request the missing responses through SNACK, in which
case the target MUST reissue them."

Some clarifications on whether SNACK recovery schemes are going to be
optional would be helpful.

- Santosh