RE: iSCSI Data Integrity - Digests

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

Y.P.

Forcing frame alignment does little to assist iSCSI if mid-tier equipment
removes such framing despite option negotiation.  The urgent pointer has a
defined behavior within RFC documentation such that to define it as a record
boundary is not in keeping with standards.  To implement and use an urgent
pointer as a record boundary pointer clearly modifies the TCP standard.
Requiring modification of all compliant TCP implementations is modifying the
standard.  There are already several TCP negotiated options such as SACK and
no one suggested disallowing use of existing standard options.  The urgent
pointer as a record boundary marker, as several people have indicated, is
not part of the standard, can not be done reliably with existing
implementations, and clearly places this concept into the non-standard
category.

PDU discovery can be done in a number of ways.  If the SCTP structures were
adopted, then a pseudo-frame could be declared to start at fixed intervals
within the TCP byte stream.  This could be done without modifying any TCP
implementations and as every device could support this mechanism, it could
be done in a uniform way.  The SCTP structures allow encapsulation of larger
structures and could comply with this interval and define handshakes and
retries independent of TCP.  This becomes required with added digest errors
that would need handling above TCP and hopefully below SCSI.  I understand
the desire to use reserved bits and tweak behavior but with such a sizeable
install base, such desires only appear deceivingly simple to realize.

The NET-SCSI standard should be independent of the underlying transport.
There should be a transport layer added to TCP to provide all needed
features demanded by SAN.  SCTP does a good job in defining these modern
transport requirements and an additional layer could be added to TCP to
provide a transport compliant to both SCTP using TCP.  In doing so, there
would be virtually no difference between the two transports and there would
be little doubt about eventual migration.

Doug


> Doug,
>
> May be I am mistaken, but I don't think what I am suggesting is doing
> non-standard TCP.  What is a non-standard TCP if I follow all the RFCs
> approved by IETF?  What I think you are referring to the non-standard
> implementation, i.e., not working working with existing TCP stacks.
>
> The urgent pointer, 32-bit TCP window, one segment per PDU, even with the
> addition of SACK are all part of "standard" TCP, just not every TCP
> implementations are supporting them.  This is why option negotiation comes
> in.  I hope I am not mistaken.
>
> Y.P.
>
>