Re: iSCSI Requirements v0.3 05 Jul 00

[Matt Wakeley <matt_wakeley@agilent.com>]

julian_satran@il.ibm.com wrote:

> 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).
>
> ++++RDMA knows what to do with data on a TCP segment base - It does not
> need the ISCSI header - that is the whole idea!

Ok, I went back and read the TCP RDMA proposal, and I agree.  This is
essentially adding the framing and other fields to handle the data in each
received ethernet frame - but what is the likelyhood (and when) that this will
be approved?


> 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?
>
> ++++ isn't SACK an option

SACK is a TCP option.  The only thing iSCSI has to do to "support" this is turn
it on!  The wording makes it sound like iSCSI must do more than that.


> Section 3.5 "Firewall friendly. The protocols 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".
>
> ++++  firewall support will be deemed essential by everybody as it includes
> handling threats beyond what we will handle in iSCSI

My point is, it only has to be "firewall friendly" if it is going *through* the
firewall.  Now, how many real implementations are going to do storage through a
firewall?

-Matt Wakeley
Agilent Technologies