Subject: RE: iSCSI : digest error handling violates EMDP/InDataOrder

From: [email-masked]
Date: Tue, 24 Apr 2001 15:00:45 -0400

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:[email-masked]]
> Sent:	Tuesday, April 24, 2001 2:30 PM
> To:	[email-masked]
> 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 >>

---

From: Stephen Bailey <[email-masked]>
Date: Wed, 25 Apr 2001 13:17:18 -0400

David,

> That seems like a reasonable approach.

Assuming DataOrder controls the equivalent of random relative offset
(data within an R2T block, or an entire read return), you took the
words out of my mouth.

Steph