Subject: iSCSI : Reject PDU Concerns.

From: Santosh Rao <[email-masked]>
Date: Thu, 18 Jan 2001 13:53:38 -0800

Ref : Section 2.19 (Reject PDU), Section 5.5 (Digest Errors)

Issue :
=====
1) Reject PDU must return an Initiator Task Tag in the Reject PDU
header, which provides the initiator sufficient context to lookup the
outbound exchange that was transmitted.

2) An error_byte field should be considered for inclusion in the Reject
PDU which contains the byte offset of the errant byte[or word] in the
received header/payload that caused the target to send a Reject response
to the command.

This is a simple solution that provides for quick fault isolation and
root cause of the reason for the reject. This also rids the Reject PDU
of any detailed elaboration of reason codes meant to allow root cause of
the reason for the reject.

3) The Reject PDU should only be used for " Format Error" since the
Reject mechanism  is a per-task error recovery to deal with header
format problems.
"Digest Error" handling is too complex dealing with too many situations.
Digest error recovery should be simplified to a connection level error
recovery which involves Logout or connection close/re-start.

The current digest recovery is a ping-pong as follows :
- Target sends REJECT
- Initiator on seeing REJECT with "Digest Error" sends Logout
- Target sends Logout response.
(the spec is not clear on who drives the connection close. does the
initiator close the connection on receiving logout response, or does the
target close connection and send logout reponse on another connection
??).

The above procedure is quite convoluted and the followinf simplification
should be considered :
- On a digest error, target sends Logout, indicating appropriate reason
code.
- Target follows up the Logout with a TCP connection close.

4) There is no value add in expecting a logout response on a logout
which is intended to close a connection and is sent on the same
connection. The logout can be followed up with a connection close.

Regards,
Santosh

---

From: [email-masked]
Date: Wed, 24 Jan 2001 15:25:42 +0200

That is not completely accurate.  You could enter the marker intervals if
you know them or, assuming that you have CRCs the analyzer can look for
48byte sequence (or 56 byte sequences) with a correct CRC and after finding
several block that make sense consider itself synched. Consider also that
after any longer silence the ULP will be aligned with TCP.  The analyzer
could work as it can loose data!

Julo

Matt Wakeley <[email-masked]> on 23/01/2001 20:54:54

Please respond to Matt Wakeley <[email-masked]>

To:   IPS Reflector <[email-masked]>
cc:
Subject:  Re: iSCSI : Reject PDU Concerns.

[email-masked] wrote:

> <js> that is no big help since there can be more than one error and it
> helps mostly in debugging. For implementation errors in the target and/or
> initiator I am sure the protocol analyzer will be happy to help but
running
> implementation should not be burdened with. For those that are running
> errors on good implementations we will provide some details when
necessary
> </js>

Julian,

With only in-band framing [the markers that are currently defined in the
spec], there is no way a protocol analyzer can be used in the traditional
way.  In order for the protocol analyzer to work, it would have to be
continuously running since the tcp connection(s) was  established.
Besides,
early on there will not be any protocol analyzers.

-Matt

---

From: [email-masked]
Date: Wed, 24 Jan 2001 15:28:16 +0200

will consider - Julo

Santosh Rao <[email-masked]> on 23/01/2001 21:35:06

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

To:   Matt Wakeley <[email-masked]>, Julian
      Satran/Haifa/IBM@IBMIL
cc:   IPS Reflector <[email-masked]>
Subject:  Re: iSCSI : Reject PDU Concerns.

Matt Wakeley wrote:

> > helps mostly in debugging.

Julian,

1) The iSCSI layer, on parsing a PDU, will stop on detecting the first
error.
So, there should really be only one error to report and that is the first
one
discovered.

2) Helping in debugging is a big issue since one of the major problems
iSCSI implementations will need to deal with is inter-operability. This is
not a
one-time problem as new implmentations of devices and initiators keep
coming
along. The iSCSI draft must attempt to provide some aids for quick fault
isolation.

3) The cost of providing this error_byte based fault indication feature is
really minimal, compared to the benefits it provides.

Regards,
Santosh

> For implementation errors in the target and/or
running
necessary
Besides,
> early on there will not be any protocol analyzers.

 - santoshr.vcf