RE: iSCSI Data Integrity - Digests

["Douglas Otis" <dotis@sanlight.net>]

Michael,

> 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.

Are you saying the network adapter stack becomes starved to the point of
only seeing one potential Ethernet frame at a time?

> >  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.

Perhaps I should have not also included feedback on your suggestion of
splitting of headers in conjunction with objecting to your datagram
proposal.  I was not saying to change TCP, only that an error checking
supplement for a small handshake field could be kept separate from the
static SCSI payload.  A simple check scheme may be effective if applied over
a few words of feedback.  Perhaps a SCSI interface driver encapsulates SCSI
payload in a pipeline fashion.  As the stack is ready, feedback is added to
the constructed frame near when the TCP is checksum is updated.  A natural
place to divide these headers checks would be with respect to dynamic
feedback.  The rest of the payload may have already had CRC and partial
checksums calculated in place waiting for placement on the network.  If
these segments are prepared within an interrupt routine, the overhead to
include feedback is important.  A handful of instructions to calculate CRC
could be replace by a single instruction as in the MTF standard.  Wanting to
indicate a possible consideration of where to delineate a header split to
include the static portion of the header together with data as one check and
the dynamic portions of the header as another.

Doug

> Mike
>
>