Re: iSCSI: Recognizing Recovery R2Ts

["Mallikarjun C." <cbm@rose.hp.com>]

Nick,

> Ok,  just to few more points to verify with regard to a lost R2T due to
> a Header Digest error:
> 
> In the case of ErrorRecoveryLevel=>1, DataSequenceinOrder=No and
> MaxOutStandingR2T=>1:
> 
> Initiator is able to ascertain a lost R2T by receiving an
> R2TSN greater than expected,  and sends a SNACK of type R2T
> to request retransmission of the lost R2T. Target retransmits R2T with
> identical values as the lost R2T.

Yes, it's the most likely scenario even though the initiator may simply 
choose to leave it up to the target to generate a recovery R2T (initiator
meanwhile may continue to work on the following R2Ts, if any) even in
this case.
 
> 
> In the case of ErrorRecoveryLevel=>1, DataSequenceinOrder=Yes and
> MaxOutStandingR2T=1:
> 
> Target will timeout waiting for Data OUT from the lost R2T
> and sends a Recovery R2T with identical values of the lost R2T.

With the next higher R2TSN (recovery R2T uses a new sequence number).

Again, this is the most likely scenario.  There's an outside chance that an
initiator may choose to generate a proactive R2T SNACK based on
aggressive timeouts (even though the spec cautions that sequence timeout-
driven R2Ts "SHOULD NOT" be used, section 5.1.4.1).

Hope that helps.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm@rose.hp.com