Message-ID: <001601c33a7a$346aee30$b08a170f@rose.hp.com>
From: "Mallikarjun C." <cbm@rose.hp.com>
To: <ips@ece.cmu.edu>
Cc: <abhijit_lahiri@yahoo.com>, <supriyo_p2003@yahoo.com>
References: <20030624141213.59998.qmail@web41409.mail.yahoo.com>
Subject: Re: Clarification requested on iscsi-draft-20 w.r.t target behavior on error conditions
Date: Tue, 24 Jun 2003 10:58:23 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Abhijit, comments below.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm@rose.hp.com

----- Original Message ----- 
From: "Abhijit Lahiri" <abhijit_lahiri@yahoo.com>
To: <ips@ece.cmu.edu>
Cc: <abhijit_lahiri@yahoo.com>; <supriyo_p2003@yahoo.com>
Sent: Tuesday, June 24, 2003 7:12 AM
Subject: Clarification requested on iscsi-draft-20 w.r.t target behavior on error conditions


> Hi All,
> 
> We are in the process of desigining an iscsi target
> simulator as per draft-ietf-ips-iscsi-20.txt. 
> 
> The draft does not seem to be explicit about an ISCSI
> target's behavior on encountering the following error
> conditions.
> 
> 1. Logout Request contains non zero DataSegmentLength
> 
> 2. Write or Data-Out PDU contains data more than 
>    MaxRecvDataSegmentLength
> 
> 3. When pre-negotiated KeyValue pairs (like
> InitialR2T, 
>    ImmediateData, DataPDUInOrder etc) are not
>    honoured in Full Feature Phase
>    ("not honouring", also means violation of result 
>     function rules)

All the above seem to fall into the "protocol error" bucket,
so one would have to employ Rejects to deal with these.
Depending on the severity of the impact on the receiving 
implementation, it may also choose to drop the connection 
in some cases. The protocol error discussion text (6.11)
provides a hint to this effect.

> 
> 4. When the sequence of PDUs (DataSN for Data-Out, 
>    R2TSN for R2T, CmdSN for Command) are not in 
>    increasing order

This protocol error manifests as a "sequence error" whose 
handling is described in fair detail in the error recovery chapter (section 6).

> 
> 5. SNACK PDU sent for an iSCSI PDU already 
>    acknowledged 
> 
> 6. If NOP-Out ping request is sent in response to a 
>    a NOP-In ping request
> 
> 7. Renegotiating KeyValue pairs which are not 
>    permitetd FFP,. (viz. MaxConnections)

These all seem to again fall into the protocol error category.
Note that #5 is specifically mentioned in the Reject reason
code table as a protocol error.

> 
> Will such erors always result in a reject PDU with
> appropriate error code ? In fact few of the above
> cases does not map to an appropriate error code
> listed.
> 
> 
> It would be great if someone can help us out. 
> 
> 
> Thanks in Advance,
> -Abhijit Lahiri
> 
> 
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
>