Re: Clarification requested on iscsi-draft-20 w.r.t target behavior on error conditions

[Abhijit Lahiri <abhijit_lahiri@yahoo.com>]

Thanks for your clarifications....
I have few more related questions. Please see below.

> --
> Mallikarjun
> 
> 
> 
> > 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.


Can we specifically say that an ISCSI Target should
always follow the following path :

1. Send Reject
2. Then drop the conenction.

OR, should an ISCSI Target always drop the connection
?

OR, can it send only reject and NOT close connection ?

I am asking this because we are also developing an
iSCSI protocol conformance tester from which we will
simulate these error conditions. 

If the draft specifies an well defined way of
responding to the error message, the tester can be
more specific.

If an iSCSI target is given the option of behaving in
any of the 3 ways specified above, the tester needs to
be prepared for any of the above cases.

> > 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).

I am sorry about this query. I should have been more
specific  about this. 

I wanted to know the effect of sequence errors when
ErrorRecoveryLevel=0.

Which of the following might happen in this case when
errorRecoveryLevel = 0 ?

1. Send Reject
2. Then drop the conenction.

OR, should an ISCSI Target always drop the connection
?

OR, can it send only reject and NOT close connection ?

> > 
> > 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.

Right :)  Thanks.



__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com