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

From: [email-masked]
Date: Wed, 18 Apr 2001 14:42:37 +0200

OK - I misread it. In any case we are not FCP and we don't violate iSCSI
rules.
Even in FCP the real reason for the ordering requirement is media order and
the need to minimize buffering for reordering.
Both can be maintained while requiring retransmission with R2T.

Julo

Santosh Rao <[email-masked]> on 17/04/2001 20:47:14

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

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   IPS Reflector <[email-masked]>, Fibre Channel T11 reflector
      <[email-masked]>
Subject:  Re: iSCSI : digest error handling violates EMDP/InDataOrder

[email-masked] wrote:
>
> Santosh,
>
> The bit and the interpretation are protocol specific.
>
> FCP uses it like iSCSI - i.e. the order has to maintained within a
sequence

Not true. If you take a look at FCP-2 rev 04 Section 10.1.1.7
description on EMDP, it explicitly states :
"The EMDP bit does not affect the order of frames within a sequence".

For a WRITE command, an EMDP setting of 0 implies that the buffer offset
in R2T requests must be in continuous and increasing order whereas an
EMDP setting of 1 implies the buffer offset in R2T can be out of order.

For a READ command, an EMDP setting of 0 implies the buffer offset in
READ data PDUs is in continuous and increasing order, whereas, an EMDP
setting of 1 implies buffer offset in READ Data PDUs can be out of
order.

Based on the above rules, iSCSI is violating EMDP setting by its error
recovery for data digest errors detected by targets on Data PDUs.

- Santosh

> (a R2T derived output or the entire input).
> In that sense we are not violating the EMDP.

>
> And BTW the recovery procedure in FCP is similar although a bit more
> complicated than ours and involves also
> a link level sequence.
>
> Julo
>
> Santosh Rao <[email-masked]> on 13/04/2001 03:54:28
>
> Please respond to Santosh Rao <[email-masked]>
>
> To:   IPS Reflector <[email-masked]>
> cc:
> Subject:  iSCSI : digest error handling violates EMDP/InDataOrder
>
> Where :
> =======
>
> 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. The current rev 05 draft violates
> InDataOrder/EMDP settings by allowing a re-transmission of R2T by
> target.
>
> Scenario :
> ==========
> initiator           target
> ---------           ------
> EMDP=0
> InDataOrder=YES
> (exp_off=0)
>         offset=0,len=64k <------ R2T
>
> --------> data PDUs
> (exp_off = 64K)
>                               data digest error results in
>                      an 8K PDU being dropped at offset 24K.
>
>        offset=24K,len=8K  <------ R2T for missing PDU.
>
> exp_off != offset
>
> - Santosh
 - santoshr.vcf

---

From: Santosh Rao <[email-masked]>
Date: Wed, 18 Apr 2001 10:20:53 -0700

> OK - I misread it. In any case we are not FCP and we don't violate iSCSI

Julian,

What reasons exist to differ in EMDP behaviour b/n iSCSI and FCP ? 

Also, a fundamental question is that the description only speaks about
incoming data PDUs. Are you implying that InDataOrder only control the
ordering for READ data PDUs ? If so, what is the mechanism to control
ordering for write data PDUs ?

It is a useful control option for initiators to negotiate that R2T
requests be made in increasing continuous buffer offset order and R2T
requests not be sent out of order. Does iSCSI allow this ?

- Santosh

"31 InDataOrder 
    
   InDataOrder=<yes|no> 
    
   No is used by iSCSI to indicate that the incoming data PDUs can be in 
   any order (EMDP = 1). Yes is used to indicate that incoming data PDUs 
   have to be at continuously increasing addresses (EMDP = 0). 
    
   This also sets the Connect-Disconnect mode page EMDP bit. 
    
   The default is yes but targets MAY support no. "

------------------------------------------------------------------------------------