RE: iSCSI : digest error handling violates EMDP/InDataOrder

[julian_satran@il.ibm.com]

David,

I read Bob's mail and my interpretation is similar to his. However I think
that SPC explicitly states that different transports are free to interpret
and make use of this page as they find appropriate.

I have a hard time understanding Santosh's objection as it does not refer
to the reason the EMDP is there but to the way it is written in FCP (not
iSCSI).

I have trouble understanding why would a target that is reissuing an R2T
violate any rule. The ordering rules where meant to assure that targets can
do their work in a fashion that is optimal for them and they where not
meant to affect initiator operation - except perhaps to enable exception
checking.

The whole issue looks to me as overblown.

Regards,
Julo

Black_David@emc.com on 24/04/2001 22:00:45

Please respond to Black_David@emc.com

To:   santoshr@cup.hp.com, ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI : digest error handling violates EMDP/InDataOrder




Santosh's original issue was that R2Ts to request
retransmission of data (e.g., due to data CRC failure)
result in an initiator seeing what appear to be out
of order R2Ts due to the need to go back and get
the failed data retransmitted.

Santosh's original email said (in part):

> Section 6.2 (pg 80). Digest Errors
> -----------------------------------
> "If the error is a Data-Digest-Error in a Data-PDU, the target MUST
> either request retransmission with a R2T or answer with a Reject iSCSI
> PDU and abort the task."

> Problem :
> ---------
> On a Data digest error detected by a target, it MUST NOT request
> re-transmission of the data PDU thru an R2T if the session login key
> InDataOrder is set to yes.

This key has been renamed to DataOrder in -06, and if
it's set to "yes" as currently defined, then (IMHO)
Santosh appears to be correct.  The Initiator is not
going to be expecting the R2T offset to step back to
pick up the missing data, and hence the Target MUST
Reject and Abort.

Beyond this, I take Bob Snively's mail as a suggestion
that we ought to split iSCSI DataOrder from SCSI's
EMDP, as FCP considers those to be separate concepts.
That seems like a reasonable approach.

Comments?

--David

> -----Original Message-----
> From:   Santosh Rao [SMTP:santoshr@cup.hp.com]
> Sent:   Tuesday, April 24, 2001 2:30 PM
> To:     ips@ece.cmu.edu
> Cc:     David Black
> Subject:     Re: iSCSI : digest error handling violates EMDP/InDataOrder
>
>
> What is the final resolution on this EMDP issue. IMHO, iSCSI must retain
> the EMDP semantics as defined in FCP, SRP. i.e. It controls the order of
> the data across the entire SCSI command. (which includes sending R2T
> requests in order, if EMDP was set to 1).
>
> Some additional thoughts on this topic are :
>
> 1) Is it worth a finer granularity of control wherein the initiator be
> allowed to negotiate with the target that R2T requests be sent in-order
> , while not imposing any constraints on the Read Data PDU order.
>
> 2) Should control be provided over a "Random Relative Offset" feature,
> as Bob describes it below, or is it to be assumed that iSCSI Data PDUs
> will always be in-order within a sequence ?
>
> 3) Speaking of sequence, this terminology has been often used in this
> thread. Where is the notion of a sequence defined in iSCSI ? What is the
> definition of an iSCSI sequence.
>
> - Santosh
>
> Robert Snively wrote:
> >
> > Seems to me that there are some unclarities in this area as well.
> >
> > There are really two pieces being discussed as one:
> >
> >         EMDP (a SCSI functionality)
> >
> >         Random relative offset (a transport functionality)
> >
> > EMDP is used to allow a target to request or deliver its data
> > out of order.  This is used for things like passing a stripe
> > segment from a RAID data extent as soon as it has been accumulated,
> > rather than waiting until all previous parts of the RAID data
> > extent have also been accumulated and delivered.  It is also used
> > for things like "start anywhere" reading of a disk track.
> >
> > It says nothing about the ordering of data within a PDU or sequence
> > which must be ordered according to the rules of the protocol.  Fibre
> > Channel allows the data within a sequence to be transmitted in order
> > or out of order by using the login parameter "random relative offset".
> > Almost all devices choose to login and require "continuously increasing
> > relative offset". << File: Card for Santosh Rao >>