Re: iSCSI Data Integrity - Digests

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

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