RE: iSCSI Data Integrity - Digests

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

> Hi, Doug:
>
> The Charters of this WG prohibits us discussing any change of TCP protocol
> and I was not talking about changing any TCP protocol.  I am
> quite familiar
> with the history why urgent pointer wouldn't work as so many TCP
> gurus were
> too quickly to point out.  This WG does not recommend the use of urgent
> pointer nor does it endorse the placement of a command/status PDU in a
> separate TCP segment.
>
> However, for microcode that running in my iSCSI interface chip with my TCP
> acceleration implementation, I can place each command/status PDU in a
> separate TCP segment without violating the TCP protocol.
> Similarly, in the
> manner I understood about TCP if I turn on the urgent pointer when I send
> the PDU to another iSCSI chip of which I came to know at login, I don't
> believe I have altered TCP.

Y.P.

You are free to add non-standard TCP and perhaps both server and client may
implement the same level of alteration. Change aggressiveness of the TCP
congestion algorithm, force framing, implement non-standard definitions of
urgent pointers, add special flags, and seldom seen options.  View TCP as
important in name only or wire only.  An alternative to chaos generated by
multitudes of such clever creations would be adoption of SCTP to provide
options already found within this standard.

iSCSI is a good example why transports are not easily developed.  If to
allow fail-over with iSCSI, even StatSN should be unique across all
connections and a strict monotonic sequence should be mandated for both
CmdSN or StatSN within every PDU (rename to ClientSN and ServerSN.)  Better
yet, adopt the SCTP structures within TCP (replace the SCTP ports with a
pseudo-frame length and allow padding to fixed intervals for frame
recovery.)  I fail to see how either client or server knows the state of the
other and how to prevent a cascade, and what benefit is derived by the
complex process of rediscovery of discarded relationships.

Doug



> Some people in this WG might not like what could be done by each iSCSI
> interface chip designer.  However, this method of doing something
> special in
> a SCSI device not available by others gives one a unique
> advantage and is a
> common practice by the SCSI industry for many years.  I will not be
> surprised that each iSCSI interface chip will have its own bag of
> tricks to
> accelerate its performance and still totally confirm the iSCSI
> specifications.  This is how the technology world is. :-)
>
> Y.P.
>
>