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

["Dev" <deva@stargateip.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
>
>
>
>-----Original Message-----
>From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
>Julian Satran
>Sent: Friday, August 17, 2001 3:23 PM
>To: Mark Bakke
>Cc: Douglas Otis; Sanjay Goyal; Ips (E-mail)
>Subject: Re: iSCSI: [Fwd: Crc-32c example in iSCSI spec]
>
>
>
>Mark & all,
>
>The 2 "additions" you will find in the CRC calculation:
>
>   initializing the "remainder" field with all ones (instead of the implied
>   shifting in of 0's) and
>   XORing the result with a mask (usually "full house")
>
>
>are done to improve the error correction capabilities of CRCs.
>CRCs are weak in detecting the spurious addition of leading 0s (that can
>result from clocking errors) and the deletion of initial 1 with spurious
>insertion of a 1 at the end.
>
>Julo
>
>Mark Bakke <mbakke@cisco.com>@ece.cmu.edu on 17-08-2001 23:10:22
>
>Please respond to Mark Bakke <mbakke@cisco.com>
>
>Sent by:  owner-ips@ece.cmu.edu
>
>
>To:   Douglas Otis <dotis@sanlight.net>
>cc:   Sanjay Goyal <sanjay_goyal@ivivity.com>, "Ips (E-mail)"
>      <ips@ece.cmu.edu>
>Subject:  Re: iSCSI: [Fwd: Crc-32c example in iSCSI spec]
>
>
>
>OK.  I don't see any reason for sending the CRC inverted either
>(we would just have a different remainder poly), but since Ethernet
>does it that way, and it doesn't cost anything, we might as well
>do it, too.
>
>--
>Mark
>
>Douglas Otis wrote:
>>
>> Mark,
>>
>> The reason for the bit swap within the table is to allow a serial
>hardware
>> scheme as CRC is processed ms to ls over the entire stream as if a single
>> number.  Ethernet sends the byte out least significant bit first.  The
>> entire table is also swapped ls to ms and actually reduces the operations
>> needed within the table calculations.  This reflects the method used for
>> Ethernet as it is being stored inverted and the initial value is started
>as
>> all ones.  The reason for the initial value being set to all ones is
>clear
>> for leading zero interaction, but I do not understand the value in
>storing
>> the CRC inverted.  I thought to include my ignorance to the mix.
>>
>> Doug
>>
>> > Sanjay Goyal wrote:
>> > >
>> > > Hi
>> > >  I get the remainder for iSCSI as 0x1c2d19ed if I complement my
>> > CRC and then
>> > > pass it through the CRC engine.
>> > >
>> > >  As per CRC generation for data: the thing which is not clear to me
>is
>> > >    why do we need to bit-swap the CRC reminader as is done in all
>your
>> > > examples.
>> >
>> > As far as I can tell, bit-swapping does nothing to help or hurt
>> > the effectiveness of the CRC.  When I ran my examples, I thought
>> > that it would be the simplest for our CRC to different from the
>> > Ethernet CRC only in the polynomial.  Ethernet, FDDI, FC, and SCSI
>> > all do this, so I figured it would cause the least confusion if
>> > we did the same.
>> >
>> > > We can just complement it and append it after the DATA bytes.
>> > >  The other side also can just pass it through the CRC engine to
>> > check it.
>> > >
>> > > Regards
>> > > Sanjay Goyal
>> > >
>> > > -----Original Message-----
>> > > From: Mark Bakke [mailto:mbakke@cisco.com]
>> > > Sent: Thursday, August 16, 2001 1:43 PM
>> > > To: Steve Blightman; ips@ece.cmu.edu
>> > > Subject: Re: [Fwd: Crc-32c example in iSCSI spec]
>> > >
>> > > One more thing that might be helpful.  When the Ethernet
>> > > polynomial is used in SCSI to generate its CRC, the T10
>> > > doc specifies the remainder polynomial that one should see
>> > > after running the data with a valid CRC through.  For
>> > > the Ethernet CRC, this was specified as 0xc704dd7b.  This
>> > > remainder polynomial is taken before the CRC is complemented
>> > > and bit-reflected.  For iSCSI, I came up with a remainder of
>> > > 0x1c2d19ed.  Can anyone verify this result?
>> > >
>> > > --
>> > > Mark
>> > >
>> > > Mark Bakke wrote:
>> > > >
>> > > > Steve-
>> > > >
>> > > > I just ran some Ethernet packets with known CRCs through
>> > > > my iSCSI/Ethernet CRC generator, and found the same thing
>> > > > as you did.
>> > > >
>> > > > All of my examples need to be byte-swapped, along with the
>> > > > fix I already posted for the all-ones example.  Here is a
>> > > > new set of examples, which will be in -08.  I also ran
>> > > > 64 bytes of zeroes and ones, which now agree with your
>> > > > numbers as well.
>> > > >
>> > > > Thanks again for bringing this up.
>> > > >
>> > > > --
>> > > > Mark
>> > > >
>> > > >      07 CRC Examples
>> > > >
>> > > >         N.B. all Values are Hexadecimal
>> > > >
>> > > >           Byte:        0  1  2  3
>> > > >
>> > > >              0:       01 a0 00 00
>> > > >              4:       00 00 00 00
>> > > >              8:       00 00 00 00
>> > > >             12:       00 00 00 00
>> > > >             16:       04 05 00 00
>> > > >             20:       00 01 00 00
>> > > >             24:       00 00 00 05
>> > > >             28:       00 00 00 04
>> > > >             32:       2a 00 00 00
>> > > >             36:       00 00 00 00
>> > > >             40:       80 00 00 00
>> > > >             44:       00 00 00 00
>> > > >
>> > > >            CRC:       93 70 51 db
>> > > >
>> > > >         32 bytes of zeroes:
>> > > >
>> > > >           Byte:        0  1  2  3
>> > > >
>> > > >              0:       00 00 00 00
>> > > >            ...
>> > > >             28:       00 00 00 00
>> > > >
>> > > >            CRC:       aa 36 91 8a
>> > > >
>> > > >         32 bytes of ones:
>> > > >
>> > > >           Byte:        0  1  2  3
>> > > >
>> > > >              0:       ff ff ff ff
>> > > >            ...
>> > > >             28:       ff ff ff ff
>> > > >
>> > > >            CRC:       43 ab a8 62
>> > > >
>> > > >         32 bytes of incrementing 00..1f:
>> > > >
>> > > >           Byte:        0  1  2  3
>> > > >
>> > > >              0:       00 01 02 03
>> > > >            ...
>> > > >             28:       1c 1d 1e 1f
>> > > >
>> > > >            CRC:       4e 79 dd 46
>> > > >
>> > > >
>> > > > Steve Blightman wrote:
>> > > > >
>> > > > > I believe the examples for the ISCSI CRC  have the wrong
>endianness.
>> > > > >
>> > > > > As yiou suugested over the phone I ran some Ethernet frames
>> > through a
>> > > > > simulation. I have some difficulty running the exact simulations
>you
>> > > > > wanted becuase the minimum size Ethernet frame is 64 bytes.
>> > > > >
>> > > > > However using the Ethernet CRC polynomial,
>> > > > > Running 64 bytes of 0 onto the wire, we append "36 63 8d
>> > 75" onto the
>> > > > > wire for the CRC - "36" goes out first.
>> > > > > Running 64 bytes of all 1, we append "ba 87 61 0f" onto the
>> > wire - "ba"
>> > > > > goes out first.
>> > > > >
>> > > > > Using the same logic for the ISCSI polynomial
>> > > > > Running 64 bytes of 0 I think we should append "67 eb c8 03" -
>"67"
>> > > > > going out first
>> > > > > and running 64 bytes of all 1 we should append "66 4e cd 2f" -
>"66"
>> > > > > going out first
>> > > > >
>> > > > > And now for 32 bytes with the ISCSI polynomial
>> > > > >
>> > > > > Running 32 bytes of 0 we should append "aa 36 91 8a" - "aa"
>> > going out
>> > > > > first
>> > > > > Running 32 bytes of all 1 we should append "43 ab a8 62" -
>> > "43" going
>> > > > > out first
>> > > > >
>> > > > > I don't want to get into an endless endian debate, but I
>> > believe it is
>> > > > > important to get the order of these bytes in the right
>> > order, so that we
>> > > > > can use the same hardware to check as well as to generate CRCs.
>> > > > >
>> > > > > Thanks for your help on this,
>> > > > > Steve Blightman
>> > > >
>> > > > --
>> > > > Mark A. Bakke
>> > > > Cisco Systems
>> > > > mbakke@cisco.com
>> > > > 763.398.1054
>> > >
>> > > --
>> > > Mark A. Bakke
>> > > Cisco Systems
>> > > mbakke@cisco.com
>> > > 763.398.1054
>> > >
>> > >
>> > ------------------------------------------------------------------
>> > ----------------------------------
>> > >
>> > >    Part 1.2    Type: application/ms-tnef
>> > >            Encoding: base64
>> >
>> > --
>> > Mark A. Bakke
>> > Cisco Systems
>> > mbakke@cisco.com
>> > 763.398.1054
>> >
>
>--
>Mark A. Bakke
>Cisco Systems
>mbakke@cisco.com
>763.398.1054
>
>
>
>