Re: iSCSI : Reject PDU Concerns.

[julian_satran@il.ibm.com]

Santosh,

my answers in text

Julo

Santosh Rao <santoshr@cup.hp.com> on 18/01/2001 23:53:38

Please respond to Santosh Rao <santoshr@cup.hp.com>

To:   IPS Reflector <ips@ece.cmu.edu>
cc:
Subject:  iSCSI : Reject PDU Concerns.




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.

<js> reject PDU can have a multitude of causes and those are/will be
detailed to certain level
(not too much.  Whenever the Initiator Task Tag is available and relevant
it can be read from the returned information. However I am still looking to
what it would take to get it back into the reject PDU itself </js>

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.

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

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.

<js> No. Command Response flow follows a regular client-server pattern and
I am
not willing to consider all the consequences of transforming it into a
"peer to peer" </js>

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.

<js> That can be done at extreme anyhow. Logout is a late addition to this
protocol  mainly to clean-up a failing connection before recovery. Logout
response is there for symmetry and convenience. Even if the target follows
logout with a connection close - the response can get to the initiator and
recovery may proceed faster that in a complete failure in which it would
have to wait for a timeout </js>

Regards,
Santosh