RE: a vote for asymmetric connections in a session

["John Hufferd/San Jose/IBM" <hufferd@us.ibm.com>]

Joshua,
Many of us have seen speeds much faster then what you quoted, and with the
new TCP/IP offload NICs, we will see performance equal to line speeds.

.
.
.
John L. Hufferd



Joshua Tseng <jtseng@NishanSystems.com> on 09/09/2000 09:46:07 PM

To:   John Hufferd/San Jose/IBM@IBMUS, Joshua Tseng
      <jtseng@NishanSystems.com>
cc:   ips@ece.cmu.edu
Subject:  RE: a vote for asymmetric connections in a session



John,

"A lot of data" is relative.  The fastest TCP implementations available
today
don't come close to what will be required for iSCSI, since they peak out
at about 200Mbps.  And the vast majority of applications are get much worse
performance than that out of TCP--I would guess typically about 20Mbps max.

iSCSI will use TCP like never before.  I believe FCP has flow control/
command recovery mechanisms below SCSI.  Unlike iSCSI, FCP has the benefit
of
operating in a low latency environment (<10us).  To think iSCSI can do
without
it and still be able to function reliably is, well iffy at best from what I
can
see.

Regads,

Josh

-----Original Message-----
From: John Hufferd/San Jose/IBM [mailto:hufferd@us.ibm.com]
Sent: Saturday, September 09, 2000 12:05 AM
To: Joshua Tseng
Cc: ips@ece.cmu.edu
Subject: RE: a vote for asymmetric connections in a session


Joshua,
I do not understand whether this is a real issue or not.  I know of a lot
of Client Server applications that ship a lot of data on TCP/IP, and TCP/IP
seems to be adequate.  Now I understand there are some differences in
Direct Storage Access, but it is more like the other applications then it
is different.  If we can address Costa's Issue or have at least two
Connection per Asymmetric Session, I am not sure anything else is a real
life problem.  But I can be convinced, however, I would like to understand
for each problem we come up with, why it is only a problem for iSCSI and
not for the other real world applications, and why the SCSI layer can not
handle the problem.

.
.
.
John L. Hufferd


Joshua Tseng <jtseng@NishanSystems.com>@ece.cmu.edu on 09/08/2000 08:53:48
PM

Sent by:  owner-ips@ece.cmu.edu


To:   John Hufferd/San Jose/IBM@IBMUS, Joshua Tseng
      <jtseng@NishanSystems.com>, Charles Monia <cmonia@NishanSystems.com>
cc:   ips@ece.cmu.edu
Subject:  RE: a vote for asymmetric connections in a session



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