Re: iSCSI Data Integrity - Digests

[Sean Quinlan <seanq@bell-labs.com>]

I would suggest that if iSCSI requires that a PDU does not span a
TCP segment then iSCSI is indeed changing TCP.  A valid implementations
of TCP has considerable freedom in deciding how to pack data into segments
and this is not under the control of the application layer.  Such a
requirement in iSCSI would mean it is not feasible to implement iSCSI on
many existing TCP stacks.  If you change the requirements of for a valid TCP
implementation I believe you have effectively changed the protocol.
I agree with Douglas Otis that such a change may not be well received.

What would you suggest for situations such a iSCSI over a protocol such as TLS(SSL).
TLS uses an internal framing mechanism that is not under the applications
control and is also not related to the underlying TCP segments.

It would seem to me a little unwise to mandate end-to-end data integrity within iSCSI
especially using a CRC algorithm.  Rather a lot of data goes over protocols
such as HTTP, FTP, NFS and CIFS without any additional end-to-end data integrity
over what is provided by TCP and link level integrity - I think it is a little
strong to say 
	strong end-to-end data integrity is not an option as customers will
	not adopt solutions without such guarantees.
If TLS or IPsec are used in conjunction with iSCSI, then strong
end-to-end integrity is already provided and duplicating this in iSCSI seem
rather a waste.  It may be the case that some people are not satisfied with
the integrity provided by TCP and yet do not want to use TLS or IPsec to ensure
integrity/authenticity, but I suspect that such people are not the majority and
thus mandating a data integrity mechanism within iSCSI seems like a mistake -
perhaps as an option or perhaps leave it to other layers in the protocol stack.

If data integrity is provided by iSCSI, CRC algorithms are not particularly
ideal from a software implementation point of view - surely there
are better alternatives than CRC that are easy to implement in hardware and
can take advantage of 32bit wide data ops.

Michael Krause wrote:
> 
> 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