Re: iSCSI Requirements v0.3 05 Jul 00

[Matt Wakeley <matt_wakeley@agilent.com>]

Comments on iSCSI Requirements v0.3:

Section 3.2:

Due to the buffering requirements at each node as link rates increase (needs to buffer
frames when a frame is lost), the lack of TCP framing, the retry behavior of TCP to
the detriment of audio and video streaming, do we really want to restrict iSCSI to
TCP?  The benefits of TCP are it's recovery and congestion algorithms, but those could
just as easily be implemented in a UDP type of transport.

Section 3.3, first [R]:

"a stated requirement (below) is that iSCSI shall have no impact on T10 architecture
or command sets. Collaboration with T10 will be required to achieve this requirement."

These two sentences seem to be mutually exclusive.  If iSCSI is to have no impact on
T10, why must there be collaboration with T10?

Section 3.5: "[R] It has been noted that a remote DMA option for TCP possibly could
provide the desired
framing."

Not if the iSCSI header is lost.  If the iSCSI header is lost, RDMA won't help,
because the RDMA will not know which I/O this iSCSI message is for, and will not be
able to DMA the data into the correct buffers described for the I/O (Initiator read
for example).

Section 3.5 "Selective TCP retransmission.":

"[D] Given the long delays in the WAN, using TCP selective retransmission must be
supported by iSCSI, in order to minimize the bandwidth impact of retransmission."

How can iSCSI support how the underlying TCP transport performs it's retransmission?

Section 3.5 "Firewall friendly. The protocol’s use of IP addressing and TCP port
numbers should be firewall friendly."

Why?  "real" implementations will use their own dedicated lines to reach long
distances, and will not transport data over the "public internet", especially due to
the "information super highway traffic jam".