RE: iSCSI Data Integrity - Digests

["Y P Cheng" <ycheng@advansys.com>]

> I see a spark of life still lives in hopes of redefining the
> Urgent pointer. A problem you will see is this pointer is only 16 bits.
> As it is defined to coalesce should new points become defined,
> it takes a small backlog in the TCP stack to create a pointer that
> can not reach a point being defined at the API. To use the Urgent
> pointer as a message marker, this issue has been
> decided and, in short, your conclusion about the ability to use the urgent
> pointer in the manner you wish is re-inventing TCP and not to be done.  If
> you wish such non-standard implementations of TCP, it clearly is
> outside the benefits of this WG.
>
> Doug

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.

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.