RE: a vote for asymmetric connections in a session

[Joshua Tseng <jtseng@NishanSystems.com>]

Hi John,

>I could be mistaken here but I think you, and some others have been
>addressing issues with the Storage Controller having the right amount of
>buffer space in the controllers for the commands, after they are delivered
>by iSCSI.  I think this is a SCSI issue and not a iSCSI/TCP flow control
>problem.

Yes, you are right that this is precisely the problem I'm addressing.  Maybe
I'm missing something here, but I still think there is an issue.  Yes,
as James described earlier SCSI has a mechanism for dealing with this, but
is it sufficient for iSCSI/TCP?  IP has distinctly different characteristics
than parallel SCSI and FC.  

For one thing, latencies in the IP world are much higher.  I'm assuming
parallel
SCSI latencies are next to nothing, while FC are in the <10us range.  If
iSCSI is going over the WAN, at least 50ms latencies are to be expected for
coast-to-coast US.  Over the Public Internet, we're talking about 80 to
250ms
or even more (RT).  Much of this latency is caused by the speed of light,
the rest
by the serialization process for WAN transport.  This works out to be
a huge amount of latency compared to FC.  How much can happen in the 30ms
before
the SCSI QUEUE FULL and BUSY messages finally get back to the initiator.
Are you
sure leaving it to SCSI or TCP will be okay?

>With respect to the Asymmetric approach,  the issues change, and we are no
>longer trying to solve the problem of missing commands that occur  because
>of a broken connection.  Therefore, I think we can dump the sliding window
>and leave the flow control -- and recovery  of lost commands,  --  up to
>TCP.  Yes, the SCSI layers on each end need to have their own buffer
>management under control, but I do not think this is a transport issue.

I agree dumping the sliding window is a good thing.  But my question is
should
iSCSI replace it with something else.  I believe the issue James brought up
with
multiple initiators needs to be considered.  Or even with a single
initiator,
how do you flow control the oncoming commands from the initiator(s)?  Is the
SCSI mechanisms sufficient given the latencies that iSCSI must be designed
to support?

BTW, I don't think that TCP has any role in addressing this issue.  If iSCSI
and
TCP operate independently at different layers, then TCP won't flow control
iSCSI commands any more than it flow controls any other PDU's, because it
can't
tell the difference between them.

Josh