iSCSI has already been done before, sort of...

[Bill Main <wmain@gis.net>]

Folks-
    If this seems late in the cycle, I apologize but I just recently
joined this project and I realize there is an IETF deadline looming
but....

    How does the adage go? Those who fail to learn from history are
doomed to repeat it.

That I believe applies here. Many protocols have been put forward or
mentioned but one seems distinctly absent from this discussion. Right up
front, this is **NOT** proposed as a protocol for adoption but it does
offer to us some valuable insights in how to handle some of the
questions at hand.

The important thing is that it does everything iSCSI is trying to do and
it has been running for years at performance levels that iSCSI will
struggle to match.

Here are some of its features:

- Been around a long time (not well known even though has an ANSI spec)
- Specs revised and improved 1986, 92, 95 and latest twik to spec in 97
- Up and running and supported by IBM, Compaq(Digital), NEC, Cray and
SGI & probably others.
- Connects large storage farms to hosts over switched network
- Deals well with congestion delays
- Handles tapes
- works with all common unix host based file systems.
- priority classifications for what now is called QoS.
- adaptable block size on transmit
- allows coalescing of data for transfer (sorts transmit queue to
optimize transfers)
- Designed and built to function on full duplex 100 MB/s networks albeit
LAN only.
- Optional multiple path capability for load balancing or striping for
both hosts and targets.
- Optional out of band command and response channel (usually Ethernet).
- Header layout done so receiver has a priori knowledge of pay load and
can segregate address data such that payload goes to page flip memory
(Does exactly what RDMA wants to do).
- Has a transmit credit system.
- Sports a well thought out error and recovery system (this could be
very useful)
- Handles partition, spanning and volume work.
- Performance numbers are commonly in the range of 85MB/s raw and 50
MB/s with a file system (WRITE) on single path with in line command and
response using 8KB file blocks. The 50 is a file system limitation
regardless of storage system class.
- relatively easy to implement, only about 1.5 man-years to get it
designed, coded and working into production envirnoment
- has stages of operation that are very SMP (or ASIC) friendly


It is called IPI-3 and runs currently only over Hippi networks which are
as close to being a SAN as any FC layout. Specs are available from the
T11 group (http://www.t11.org/index.html)
Grab the IPI-3DR and IPI-3TR versions (disk and tape respectively).

    Having been the original architect on one implementation of IPI-3,
there is a lot of knowledge in there that has been stepwise improved on
over the 14 years of its existence, but it does exactly what iSCSI is
trying to do.

 Now the bad news: Does not use IP or TCP but IPI-3 is very efficient.
Note though, the Hippi-PH can be replaced by IP if one really wanted to
without much effort.

 First, from my perspective it appears that iSCSI is a re-invention of
the wheel – Not that a redesigned wheel can’t be made better. But it
always seemed better to study the original while doing it.

 Second, when you pull the specs, you will notice that they are weighty.
Having designed an implementation of a network disk transfer system (ala
iSCSI) for IPI-3, I assure you there is very little excess in there.
Eventually every issue that generated paragraphs in the IPI-3 spec will
show up in the iSCSI implementations as well.

 Regards,
    Bill Main