RE: iSCSI Data Integrity - Digests

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

> While I understand and can appreciate all the tricks that can be done
> with a merged stack that avoids the implementation layer, I strongly
> object to this WG allowing standard options that change the standard
> TCP wire protocol. Even if both ends agree to do the "special"
> processing, other nodes and protocols generally share these
> wires and "special" non-standard options can have nasty indirect
> effects.  If your custom adapter does things that are not changes
> in the protocol, like always putting an iSCSI request in a
> single segment which allows the other end to fast-path processing, is
> an acceptable implementation trick as either end not "knowing" about the
> trick will function correctly, although maybe not optimally.
> Any changes to the standard TCP must go through end2end, this WG MUST
> NOT allow options that circumvent that process.
> 	-David

David,

Each time when I touched this area, I always felt like walking around a
snake pit.  It is neither my intent to discuss changes of TCP wire protocol
in this WG nor my desire to make such changes.  I've been always carefully
in using the words "TCP implementation."  In fact, after reading a lots of
RFC's, I have come to the conclusion that there are ways within TCP that
would allow iSCSI work well in 10GB/100Ms Network.  The slow TCP transport
problem is in the existing implementations that do not have all the new TCP
options.

For example, you can have 16-bit TCP window-size or 32-bit.  Using 16-bit
window size, there in no way we can keep the 10Gb/100Ms pipe full.  But, the
use of 32-bit window-size does not change the TCP protocol.  Another
example, an iSCSI adapter can always send each iSCSI Command PDU in a
separate TCP segment.  In so doing, URG pointer is perfect for marking
message boundary. While the gurus of TCP can quickly point out that it is
impossible for URG pointer to mark the SCSI command boundary in the BSD
implementation, there is nothing preventing two iSCSI adapters from using
URG pointer when they send command PDUs to each other.  In fact, whether two
iSCSI adapters using URG pointer in their exchanges, IMHO, is even outside
the jurisdiction of this WG.  Because the use of URG pointer does not
violate TCP protocol.  It is just that old TCP implementations not able to
keep command/status PDUs in separate segments can not benefit from URG
pointer.

Therefore, while an iSCSI adapter can interoperate with a client running in
TCP of BSD 4.3, it should also be able to interoperate with another
state-of-art iSCSI adapter which is much more intelligent.  The difference
in their interoperation will be decided at login with text messages.  I
think we don't have to limit ourselves to stone age tools if electrical
drill is already invented.  Please note that I am not asking the invention
of new TCP options here.

Y.P.