Re: a vote for asymmetric connections in a session

["Matt Wakeley" <matt_wakeley@agilent.com>]

If SCSI (T10, SAM-x?) can't solve the problem of flow controlling commands, then
iSCSI can by using at least 2 TCP connections, one for commands and 1+ for
data.  The commands can back up, and be flow controlled by TCP and the data to
satisfy the executing commands can continue.  If you don't want to do this, then
T10 (SAM) will have to address it, and it sould NOT be an issue of the transport
(iSCSI).

-Matt

Joshua Tseng wrote:

> 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