RE: Towards Consensus on TCP Connections

[hufferd@us.ibm.com]

I agree with most of what Stephen says.

Now, do you think that now we can shelve the disk drive discussion and
focus more on the Storage Controller functions.

When we started all this, I thought that we wanted to FIRST focus on the
interface to Storage Controllers, in order to avoid the quagmire that Fibre
Channel got into when they tried to handle both controller  (with Switched
interfaces) and Disk Interfaces with Loops.

I would like to continue to focus on the Host to Storage Controller
approach which we were following.  If there is some important item, which
will prevent its operation on disks, we should be aware of it, but our
focus should be FIRST on Storage Controllers.  This current Disk interface
discussion, seems to be distracting from our goal to insure that the
proposal works well at the Storage Controller level.

I think that it has been stated several times that the use of a Session per
LUN etc. is within the current iSCSI proposal, and it has been stated a
number of times by folks that make their living creating Storage
Controllers that they do not think they can support a protocol that
REQUIRES a Session per LUN.

So I would like to propose, again, that we get back on track and work
issues which apply first to Storage Controllers.



.
.
.
John L. Hufferd

Internet address: hufferd@us.ibm.com



"Douglas Otis" <dotis@sanlight.net>@ece.cmu.edu on 08/11/2000 11:14:13 AM

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


To:   "Stephen Byan" <Stephen.Byan@quantum.com>, <ips@ece.cmu.edu>
cc:
Subject:  RE: Towards Consensus on TCP Connections



Today's drives can deliver 320 Mbits/second of data on the outside
cylinders.  Improvement of the mechanics comes at a high price with respect
to power and cost.  The cost/volume trend takes us to a single disk which
increases access time as read channel data rate increases.  By offering
scaled throughput using more drives where each drive's interface bandwidth
is restricted with respect to read channel data rates provides a system
with
uniform and superior performance.  The advantage of such an approach is
found with respect to smaller random traffic.  With more devices,
redundancy
is easily achieved and parallel access offers a means of performance
improvement by spreading activity over more devices.  The switch provides
bandwidth aggregation and is not found in the individual device.

An 8ms access + latency figure in the high cost drives restricts the number
of 'independent' operations that average 64k byte to 100 per second or 52
Mbit per second.  Such an architecture of 'restricted' drives would scale
whereas the solicitated burst approach does not.  An independent nexus at
the LUN is the only design that offers required scaling and configuration
flexibility.  Keeping up with the read channel is a wasted effort.  In
time,
1 Gbit Ethernet will be the practical solution about the time drives are 1
inche in size.  Several Fast Ethernet disks combined at a 1 Gbit Ethernet
client makes sense in cost, performance, capacity, reliability, and
scalability at this point in time.  The protocol overhead should be
addressed.  There are substantial improvements to be made to allow this
innovation using standard adapters.

The power cost to use copper 1 Gbit is high.  Firewire does not scale and
has a limited reach.  Firewire also places scatter/gather on the drive
together with direct access.  Doing such over a WAN will impose significant
changes.  Serial ATA is nothing more than IDE through a SERDES.  The read
channel data rate is like a drug, just say no.  It is hard not to buy
enough
dram to allow a proper buffer these days.  Serial ATA removes all buffers.
Intel is just usurping any remaining electronics at the cost of sensitivity
to a near by cell phone.  Fewer drives with less electronics.  What a good
idea?

Doug

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Stephen Byan
> Sent: Friday, August 11, 2000 7:07 AM
> To: 'ips@ece.cmu.edu'
> Subject: RE: Towards Consensus on TCP Connections
>
>
> Stephen Bailey [mailto:steph@cs.uchicago.edu] wrote:
>
> > The gating factor for whether iSCSI succeeds is not going to be 200
> > MB/s instead of 100 MB/s out of a single LUN.
>
> In general, I agree. iSCSI can succeed in the high and midrange storage
> market without link aggregation for a single LUN. These markets can
afford
> 10 Gb/s links.
>
> As a disk device level interface, iSCSI will not succeed unless
> it offers at
> least 2 Gb/s by around 2002, at very low cost for the link. Note that
even
> Serial ATA starts at 1.5 Gb/s in 2001. Take a look at the Serial ATA
speed
> roadmap on slide 16 of Intel's Serial ATA presentation at WinHEC:
> http://serialata.org/F9pp.pdf.
>
> One can argue the technical merits, but from a marketing
> viewpoint, the disk
> industry (both suppliers and customers) has long held the view that
> interface speeds need to match the media data rate. iSCSI can try
> to make an
> argument that slower speeds are technically adequate, but this
> will increase
> the barriers to establishing iSCSI as a device interface.
>
> > If iSCSI works at ALL in a cost effective way that can be implemented
> > in a disk, there'll be wild dancing in the streets and you'll all (or
> > maybe your companies will) be rich beyond the dreams of avarice.
> >
> > The easier you can make it for the implementors, the more likely it
> > will succeed.
>
> Disk drive companies have implemented much more complex interfaces than
> iSCSI and TCP - e.g. fibre channel arbitrated loop. And multiple TCP
> connections don't look very hard to implement. They just look like a
wart.
> But I think a necessary one.
>
> Regards,
> -Steve
>
> Steve Byan
> <stephen.byan@quantum.com>
> Design Engineer
> MS 1-3/E23
> 333 South Street
> Shrewsbury, MA 01545
> (508)770-3414
> fax: (508)770-2604
>