RE: iSCSI Data Integrity - Digests

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

Mike,

I agree with most of your points with the exception of TCP being a wire
protocol.  Use the SCTP structures and apply them to TCP where the SCTP port
locations become a pseudo frame word length and then allow padding to a
predefined interval and you then have the required framing and all the
benefits of SCTP while not harming TCP at the API.  As we get mired down in
amorphic iSCSI, a transport specification as complete as SCTP would
immediately provide productive solutions and a clean migration to that
uncharted land where SCTP dominates.

Doug

> At 10:51 PM 1/29/2001 -0500, Sean Quinlan wrote:
> >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.
>
> The continual assertion that TCP implementations are sacrosanct and thus
> not cannot be modified to support iSCSI combined with a tendency to make
> everything an option should someone object quite frankly leads one to
> question whether iSCSI will suffer the same 10-year growing pains /
> interoperability problems FC suffered and thus seriously raises a
> question
> of its viability within the industry.
>
> Yes, iSCSI could be implemented using SCTP which is, from an architecture
> point of view, more suitable in many ways than TCP.  However, SCTP isn't
> really deployed today, is not targeted by those few that have deployed it
> for a high-volume market, and thus unclear whether it can generate
> sufficient interest to make it a viable transport from a business
> perspective.  I don't want to debate SCTP vs. TCP - there has been enough
> of it already on this reflector and the only point was while it is
> interesting, the business issues are a major problem that is not going to
> be solved in the desired deployment time frames.
>
> Summary: Either iSCSI starts getting realistic in terms of what
> is subject
> to change without violating / major modifications to existing protocols
> (not implementations) and starts reducing the number of options so
> interoperability has a chance of success or it will suffer the
> fate of FC's
> early years.
>
> >If you change the requirements of for a valid TCP implementation
> I believe
> >you have effectively changed the protocol.
>
> The protocol is defined as a set of wire formats and semantics.  The
> proposal did not violate any aspect of the RFC which does allow
> TCP a great
> deal of freedom in terms of how it packages segments.
>
> >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.
>
> Put some intelligence into the solution's implementation and segment
> accordingly.
>
>
> >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.
>
> The original proposal stated what the difference here is: these protocols
> target buffers and associated information that is not transmitted
> over the
> wire thus reducing the probability of a DMA targeting an
> incorrect location
> in memory.  iSCSI communicates addressing information either
> direct VAs or
> a handle for the look-up.  In either case, there is a greater probability
> of a DMA targeting the wrong location as a result.  FC protects
> their data
> with a 32-bit CRC which provides customers with a lot greater
> confidence in
> the data integrity than what they get from TCP's checksum.
>
> Also, as noted by numerous people there is a measured evidence of silent
> data corruption getting past TCP's checksum today in the Internet.  If
> people really believe iSCSI will flow across the Internet, then
> silent data
> corruption must be dealt with in a much stronger manner than what
> is being
> proposed and having it as an option is unacceptable for most vendors and
> customers.
>
> >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.
>
> One cannot mandate IPSec /  TLS usage within the standard nor can
> one rely
> upon it for data integrity. To assume that the majority of people want it
> is incorrect as well since this is a function of the usage models being
> deployed.  Many people interested in iSCSI are not interested per se in
> block storage over the actual Internet but block storage over IP-based
> networks - there is a very big difference here and the requirements for
> security as a result.
>
>
> >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.
>
> CRCs are well understood.  While software is an interesting
> implementation
> and certainly one that I do not want to see harmed, many vendors are
> developing hardware-based solutions (keeps the CPU consumption to be the
> same as FC which is important for customers and vendors).  The
> proposal put
> forth also provided a mechanism for some intelligence to be added to
> non-iSCSI hardware implementations similar to the way one does checksum
> off-load today allowing software to not necessarily be burdened with
> unnecessary overheads if so desired.
>
> Mike
>
>