|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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 >
Home Last updated: Tue Sep 04 01:08:10 2001 6315 messages in chronological order |