Subject: Recovery R2T

From: Michael Morrison <[email-masked]>
Date: 11 Jul 2002 13:41:54 -0700

If an initiator sends multiple Data-Out in response to an R2T, and one
of the Data-Out in the
sequence has a data digest error, can the recovery R2T solicit only the
missing data, or must
it solicit the whole sequence?   I can't find anything in the draft that
defines what the contents
of a recovery R2T MUST/SHOULD/MAY contain.   

Thanks

Michael Morrison
ISTOR Networks
7585 Irvine Center Dr. Ste 250
Irvine Ca. 92618
PGP Key: 74C30155

---

From: "Mallikarjun C." <[email-masked]>
Date: Fri, 12 Jul 2002 10:31:42 -0700

Michael,

It appears to me that we need to define the term `recovery R2T' - 
the lack of which David Black also pointed out earlier.

Here's what I propose we should define it as:

Recovery R2T: It is an R2T generated by a target upon detecting 
the loss of one or more Data-Out PDUs through one of the following means
- a digest error, a sequence error, or a sequence timeout.  A recovery
R2T carries the next unused R2TSN, but requests part of or the entire
data 
burst that an earlier R2T (with a lower R2TSN) had already requested.

I believe the MUST/SHOULD/MAY language contained in Section 6 already 
defines the expectations on the usage scope of recovery R2T.
-- 
Mallikarjun 

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
MS 5668	Hewlett-Packard, Roseville.
[email-masked]

> Michael Morrison wrote:
> sequence has a data digest error, can the recovery R2T solicit only
> the missing data, or must
> it solicit the whole sequence?   I can't find anything in the draft
> that defines what the contents

---

From: Michael Morrison <[email-masked]>
Date: 12 Jul 2002 10:43:34 -0700

Mallikarjun,

Your definition looks OK to me.  But I'm concerned about the case of
DataSequenceInOrder
being set to Yes.  The R2T text allows the target to send a recovery
R2T, but the
text in 11.20 says that the initiator cannot send the requested data as
it's not a continuously non-decreasing offset.  

From 9.8 (R2T)
 DataSequenceInOrder governs the buffer offset ordering in consecu-
   tive R2Ts. If DataSequenceInOrder is Yes, then consecutive R2Ts
   SHOULD refer to continuous non-overlapping ranges.

From 11.20
If DataSequenceInOrder is set to Yes, Data Sequences MUST be trans-
   ferred using continuously non-decreasing sequence offsets (R2T buffer
   offset for writes, or the smallest SCSI Data-In buffer offset within
   a read data sequence).

Mike

On Fri, 2002-07-12 at 10:31, Mallikarjun C. wrote:

    Michael,

    

    Mallikarjun Chadalapaka

Michael Morrison
ISTOR Networks

---

From: "Mallikarjun C." <[email-masked]>
Date: Fri, 12 Jul 2002 12:22:59 -0700

Michael,

You're referring to a different, but related issue now.  We had debated
your new issue in the past, look at the last para in section 11.20.  
--
Mallikarjun

Mallikarjun Chadalapaka
Hewlett-Packard MS 5668 
Roseville CA 95747
[email-masked]

---

From: Parthi <[email-masked]>
Date: Tue, 16 Jul 2002 09:29:26 +0530

Hi Michael:

   Initiator will send SNACK request PDU indicates for missed
numbered-response.

   Support for SNACK is mandatory only if the supported ErrorRecovery-
Level is greater than zero.

   The SNACK request is used to request the retransmission of numbered-
responses, data, or R2T PDUs from the target.

Draft says "

    The numbered-response(s) or R2T(s), requested by a SNACK, MUST be
delivered as exact replicas of the ones the initiator missed and MUST
include all its flags. However, the fields ExpCmdSN, MaxCmdSN and Exp-
DataSN MUST carry the current values.

The numbered Data-In PDUs, requested by a SNACK with a RunLength dif-
ferent from 0, have to be delivered as exact replicas of the ones the
initiator missed and MUST include all its flags. However, the fields
ExpCmdSN and MaxCmdSN MUST carry the current values.  Data-In PDUs
requested with RunLength 0 (meaning all PDUs after this number) may be
different from the ones originally sent, in order to reflect changes
in MaxRecvPDULength.

Any SNACK that requests a numbered-response, Data, or R2T that was not
sent by the target MUST be rejected with a reason code of "Protocol
error". "

thanks,
parthi

--
http://san.hcltech.com

---

From: Michael Morrison <[email-masked]>
Date: 16 Jul 2002 09:31:05 -0700

Parthi,

Thanks for your response,

we are talking about two different things.  
If the initiator detects a hole in the R2TSN, it can request the R2T be
resent by sending SNACK.

If the target detects a hole in the DataSN of Data-out PDU, it can send
a Recovery R2T to re-solicit the missing data.

The contents of a recovery R2T are not defined in the draft. 
Mallikarjun provided a possible definition.

Mike

On Mon, 2002-07-15 at 20:59, Parthi wrote:

    Hi Michael:

       Support for SNACK is mandatory only if the supported
    ErrorRecovery-
    Level is greater than zero.
    
       The SNACK request is used to request the retransmission of
    numbered-
    responses, data, or R2T PDUs from the target.
    
    Draft says "
    
        The numbered-response(s) or R2T(s), requested by a SNACK, MUST
    be
    delivered as exact replicas of the ones the initiator missed and
    MUST
    include all its flags. However, the fields ExpCmdSN, MaxCmdSN and
    Exp-
    DataSN MUST carry the current values.
    
    The numbered Data-In PDUs, requested by a SNACK with a RunLength
    dif-
    ferent from 0, have to be delivered as exact replicas of the ones
    the
    initiator missed and MUST include all its flags. However, the fields
    ExpCmdSN and MaxCmdSN MUST carry the current values.  Data-In PDUs
    requested with RunLength 0 (meaning all PDUs after this number) may
    be
    different from the ones originally sent, in order to reflect changes
    in MaxRecvPDULength.
    
    Any SNACK that requests a numbered-response, Data, or R2T that was
    not
    sent by the target MUST be rejected with a reason code of "Protocol
    error". "

    thanks,
    parthi
    
    "Mallikarjun C." wrote: 

        Michael, 
        
        It appears to me that we need to define the term `recovery R2T'
        - 
        the lack of which David Black also pointed out earlier. 

        Recovery R2T: It is an R2T generated by a target upon detecting 
        the loss of one or more Data-Out PDUs through one of the
        following means 
        - a digest error, a sequence error, or a sequence timeout.  A
        recovery 
        R2T carries the next unused R2TSN, but requests part of or the
        entire 
        data 
        burst that an earlier R2T (with a lower R2TSN) had already
        requested. 
        
        I believe the MUST/SHOULD/MAY language contained in Section 6
        already 
        defines the expectations on the usage scope of recovery R2T.

        -- 
        Mallikarjun 
        
        Mallikarjun Chadalapaka 

    -- 
    http://san.hcltech.com

Michael Morrison
ISTOR Networks