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

[Jim McGrath <Jim.McGrath@quantum.com>]

I think the question is whether there is a document similar to iSCSI for IPI
over a network that we could learn from.  My problem with the actual IPI-3
document is that I believe it is similar in scope to the SCSI documents
themselves - good at defining the protocol for the traditional storage
model, but not good at highlighting the changes/issues associated with
putting it over a network.

If there was a iIPI (IPI-3 over some network) document(s) out there, then
that could provide some useful guidance.

If I am mistaken, and the actual IPI-3 documents provide this level of
guidance, then it would probably help others to identify the appropriate
sections, since the document itself is rather large.

Jim


-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Friday, July 07, 2000 11:49 AM
To: wmain@gis.net; ips@ece.cmu.edu
Subject: RE: iSCSI has already been done before, sort of...


It's not clear to me what the point of this message is,
since the author says:

> 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.

but then has very little to say in terms of exactly
what the insights are.  The bullet list of IPI-3 features
isn't particularly helpful; is the intent to put them
forward as requirements?

Could I suggest writing an Internet-Draft on the topic of
what the author thinks is wrong with iSCSI, why, and how to
fix it as a productive alternative to making disparaging
comments on the efforts of others?

--David (future WG co-chair)

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909
black_david@emc.com  Cellular: +1 (978) 394-7754
---------------------------------------------------


> -----Original Message-----
> From:	Bill Main [SMTP:wmain@gis.net]
> Sent:	Friday, July 07, 2000 10:13 AM
> To:	ipSCSI list
> Subject:	iSCSI has already been done before, sort of...
> 
> 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
>