RE: iSCSI:Data Recovery from digest errors ...

["Dev" <deva@stargateip.com>]

Mallikarjun,

Thanks for the clarification.

Deva

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Mallikarjun C.
Sent: Tuesday, August 21, 2001 7:05 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI:Data Recovery from digest errors ...


Deva,

InitialR2T=no only implies that an *initial* unsolicited
burst is allowed by the target - _not_ that R2T is completely
disabled.  For complete details, see rev07, Appendix D, item 24.

Data sequence numbers always follow the rules clearly outlined
in section 1.2.2.3.  R2T is a request to transfer certain data
range, *not* PDU sequence range (as does a SNACK).

I hope that addresses your questions.
--
Mallikarjun


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


>Mallikarjun,
>
>Thanks for the input.  I thought about it. I like the way of using R2T
>to retry the data. But on further thoughts I have some
>clarifications/concerns.
>
>At the outset, it looks to me to open the door for having the
>target solicit for data (unless some restrictions are on the R2T) even
>though  R2T is disabled as initR2T is disabled.. But R2T PDU has all the
>relevant field
> data offset, data length etc and fits in to retry data. Now, If out of 64K
>received,
>target desires to choose to retry the 16K,say between 32K to 48K, what will
>be the data
>sequence numbers generated for the data PDUs sent as response to R2T. Will
>it be the
>same sequence number for Data PDUs when they were sent as unsolicited burst
>or a different
>one? What will be the value of the value of expR2TSN and expDataSN in the
>SCSI response PDU for this case. Probably a flag in the R2T header indicate
>that
>it is a retry for immediate and the initiator should resend the entire
>data..
>
>If an initiator/target have to still be capable of supporting R2T when it
is
>disabled,
>why would R2T and unsolicited data burst be mutually exclusive in the iSCSI
>spec? Meaning,
>if a command request is for 64K write and unsolicited burst size is 32K,
why
>not the target
>receive the rest of the data (the next 32K) through R2Ts?
>
>Am I missing something?
>Just my thoughts. what do you think? If Im on the wrong track, could you
>correct me?
>
>
>
>Thanks
>
>Deva
>Platys Communications
>
>
>
>-----Original Message-----
>From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
>Mallikarjun C.
>Sent: Tuesday, August 21, 2001 3:07 PM
>To: deva@stargateip.com
>Cc: ips@ece.cmu.edu
>Subject: Re: iSCSI:Data Recovery from digest errors ...
>
>
>Deva,
>
>Let me respond to your questions.
>
>Currently, the draft assumes that recovery R2Ts can be generated
>for digest errors on unsolicited data bursts in separate data PDUs.
>This will be explicitly called out as I said in a response to Sandeep:
>
>http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05855.html
>
>The immediate data digest failures however, are not intended to
>be recoverable with R2Ts since an iSCSI (and SCSI) task is not
>instantiated in that case (rev07, section 7.2).  The rationale
>was that it is much easier for the initiator to re-ship the entire
>PDU (command+immediate) than build a new data PDU with a Write-data
>header (if only a part, command, of the rejected PDU were accepted
>on  the target).   Also, accepting partial PDUs didn't seem to make
>it easier for targets either.
>
>New wording dealing with immediate data digest failures had already
>been added to section 7.2, to appear in rev08.
>
>Thanks.
>--
>Mallikarjun
>
>
>Mallikarjun Chadalapaka
>Networked Storage Architecture
>Network Storage Solutions Organization
>MS 5668	Hewlett-Packard, Roseville.
>cbm@rose.hp.com
>
>>Julian,
>>
>>I dont know if this has been already discussed. If so forgive me and point
>>me to the link please.
>>
>>In Section 7.4, in draft 7 (page 115)it is stated that the target may
>>request retransmission
>>with a R2T. It then goes on to say that non-data PDU. It does not talk
>about
>>unsolicited data PDUs, explicitly.
>>I presume that data digest errors in unsolicited and immediate data PDUs
>>cannot be retried and should be responded
>>with delivery-subsystem failure. Is this correct? If so, why is this
>>requirement ?
>>
>>In section 7.11.1, page 119, the spec. implies that digest errors in data
>>PDUs may be recovered by issuing R2T. Once again,
>>it fails to talk about digest errors in immediate data unsolicited data
>>PDUs.
>>
>>Thanks
>>
>>Deva
>>Platys communications