RE: iSCSI Data Integrity - Digests

[Michael Krause <krause@cup.hp.com>]

At 10:13 AM 1/29/2001 -0800, Douglas Otis wrote:
>Michael,
>
>Your highest and second highest preference represents a change to the TCP
>protocol in that it mandates segment alignment of the PDU with the Ethernet
>frame.

This is not a change to the TCP protocol - strictly implementation specific.

>The impact of changing TCP into a datagram protocol may not be well
>received.

It is still byte streaming but iSCSI PDUs don't span multiple 
segments.  This is an application-specific issue, i.e. it is the unit of 
how one sends data and has nothing to do with the TCP protocol 
itself.  This really isn't any different than what applications do today - 
a peek() to determine how to cast the byte stream into a message - which is 
very common for most sockets applications.

>  If you wish to see two frame checks, one for the iSCSI header and one 
> again for the SCSI payload, I would suggest that there are variables used 
> as handshakes within the iSCSI
>header that could use even a simpler scheme than a 16 bit CRC, a 32 bit XOR.
>If done in software, both the TCP checksum and this header checksum will
>require updating.  A single CRC field will represent a time constraint in
>that a pipeline delay of iSCSI feedback will exist. Allowing these
>calculations to take place prior to being placed for delivery within an
>interrupt routine is the advantage of allowing a simple feedback update.

Disagree with your recommendations and analysis.  There is no change 
required for the TCP checksum this proposal is strictly above the TCP 
layer, i.e. iSCSI.

Mike