Re: iSCSI: Recovery R2T

[Michael Morrison <mmorrison@istor.com>]

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:
>     
>     
>     
>        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
>     
>     
>     
>     "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. 
> >         
> >         
> >         
> >         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. 
> >         
> >         cbm@rose.hp.com 
> >         
> >         
> >         
> >         > Michael Morrison wrote: 
> >         
> >         > 
> >         
> >         > 
> >         
> >         > 
> >         
> >         > 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
> >         
> -- 
> http://san.hcltech.com
>      
>

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