RE: A Data Integrity Negotiation Scheme for iSCSI

[Jim McGrath <Jim.McGrath@quantum.com>]

I agree with Rob.  This is where your intended application gets in the way
again.  If this is the sort of traditional, server to server communications
networks employ today, then the original proposal is OK - the server is
responsible for buffering and breaking down the long transmissions to block
size units the data storage devices understand.  But if you are going
directly to the storage device, then your buffering and processing power is
severely limited.

Frankly, I don't know why we need multiple levels of CRC/ECC at all.  Yes,
TCP can be run on layer 2 networks that do not have any error checking.  But
is that a real concern (for LANs probably not - maybe for WANs)?  Is all the
TCP checksum doing is insuring frames do not get lost?  And if so, aren't
there other (more effective) mechanisms?

Jim

PS note that you can still use TCP as is in the protocol, you could just
drop the requirement that the destination device check the checksum,
allowing it to process blocks one at a time as normal (actually,
ethernet/fibre channel/infiniband frame as a time - allowing for reassembly
of course).






-----Original Message-----
From: relliott@hobbit.eng.hou.compaq.com
[mailto:relliott@hobbit.eng.hou.compaq.com]
Sent: Thursday, July 06, 2000 7:59 AM
To: mark.bakke@nuspeed.com; ips@ece.cmu.edu
Subject: Re: A Data Integrity Negotiation Scheme for iSCSI


Mark A Bakke wrote:
> The CRC32 Scheme
> 
>   Other than "none", "CRC32" is the scheme specified in this
>   document.  Other schemes that may be more applicable should
>   be proposed as well.
> 
>   If the CRC32 scheme is negotiated for headers, a 32-bit CRC
>   is at the end of an iSCSI request or response, or between
>   the request and its data, as described above.
> 
>   If the CRC32 scheme is negotiated for data, a 32-bit CRC
>   is added to the end of all data, covering ONLY the data (headers
>   and commands sold separately).
>   
>   The big open question here is whether to support a CRC at the
>   end of the data request, or at the end of every [8k?] "block"
>   of data, or both.  The advantage of a CRC over just the block
>   is simplicity; this works fine for most block device accesses,
>   since file systems and databases usually write in 2, 4, or 8k
>   clusters.  However, if the data is of sufficient size as to make
>   the check too weak (tape backup software and specialized file
>   systems for large block data can write 64k .. 1MB or more at
>   a time), we would need to add the CRC more often.

Storage devices cannot commit data to storage until the CRC has been 
checked, so larger intervals imply larger temporary storage buffers.  
In parallel SCSI (Ultra 3) the target was given the ability to choose 
how often CRC is transferred for both writes and reads.  This keeps 
it from needing infinite buffers for writes - if it has a 512 byte 
write buffer, it can ask for a CRC every 512 bytes.  For reads, the 
initiator can just redo the read if an error is detected - nothing 
disastrous happens if bad data enters its destination buffer before
the command is marked complete.  The target can send CRC when it 
chooses.

-- 
Rob Elliott      UNIX mailto:relliott@hobbit.eng.hou.compaq.com    
Houston, TX        PC mailto:Robert.Elliott@compaq.com