IP Storage WG Minutes
Presentations will be posted on IPS web site.
(http://www.ece.cmu.edu/~ips/)
Dave Lee:
Storage & Networking used to mean just file abstraction IP Storage means having new choices: block storage and possible OBSD
Mailing list is ips@ece.cmu.edu. Join by sending a SUBSCRIBE request to ips-request@ece.cmu.edu
Mark Bradley:
Gave Dave Nagle's Storage over IP presentation.
Greg Finn:
Gave a NetSCSI presentation
Many of the inefficiencies in storage are due to workstation operating system kernel architecture (leading to excess copies)
Security is a must.
Julian Satran:
Presented iSCSI
Pointed out that TCP was the most optimized part of some network stacks.
Paul von Stamwitz:
Presented SEP.
Internet draft of SEP is coming soon.
Randy Haagens:
Noted that 1 connection/SCSI LUN may be onerous for some applications/systems.
HP has storage arrays with 1000 LUNs today and that number is going up as storage arrays gain the functions of volume managers.
Mark Bradley charter presentation summary:
Presented broad options that the group COULD work on. However, work and interest in this area point to putting focussing on just SCSI over TCP.
Mentioned that storage may not need a reliable transport. Scott Bradner was surprised by this and questioned the use of reliable. Mark Bradley and others pointed out that multimedia streams from the disk probably don't need transport reliability.
Allison Mankin:
Shared and non-shared storage: thought that SCSI is at the wrong level to share storage.
Mark Bradley:
SCSI does have sharing mechanisms at a very coarse level (RESERVE/RELEASE on the LUN level).
Somebody:
Was Mark Bradley suggesting in his presentation that FC use this group to build a storage protocol on top of TCP?
Mark Bradley:
Not suggesting this at all
Luciano:
Concerned about all the options in the presentation. Wanted to focus on SCSI/TCP.
Somebody:
Very concerned by this discusion. IPS eliminates the intelligence that functions as a file server and replaces it by proprietary OS file systems/databases.
The utility of the disk block abstraction is capped and so the utility of this effort is capped.
Randy Haagens:
It is most obvious to apply block storage in the LAN. However, there are wide-area applications like remote mirroring, remote tape backup, etc. These are hard to support with a network.
Also, there is an emerging concept of a storage utility that rents out storage in the metoropolitan area, where the speed of light latency problems are minimal.
Thus, there are good reasons to run SCSI over a TCP/IP network.
It is useful to concentrate on the abstraction. If you put foo on a network, you can share foo. I did this with printers at HP (despite the howls of some people) and it turned out to be a success and people are using the Internet today to do wide-area printing.
Similarly, there are real reaons to share disks - file systems and databases want block storage, not file sotrage.
Also, placing a storage controller on the network lets you share the storage controller. Storage controllers may have 2-10,000 LUNs and each storage client on the network consumes some portion of those LUNs.
Allison Mankin:
Congestion control needs to be on the slide
Julian Satran:
Also QoS needs to be on the slide. Can IPS put both congestion control and QoS together.
Scott Bradner:
QoS and congestion control are separate things IPS needs to be able to exploit QoS facilities to minimize latencyand/or guarantee bandwidth through the network. There should be a charter item that at least has the group monitoring the QoS work and probably suggestion QoS for Storage.
Brian Carpenter and several other people said this:
I don't understand where this is going to be used or what this group is targetting. It would be useful to generate an applicability statement which indicates where this technology is to be applied.
Several people also said:
Security (authentication, privacy, and integrity) is an absolute must if you're manipulating stuff at such a low level.
Somebody said:
There's a bit of a disconnect here. You're talking about simple hard disks: devices with limited CPU. And now, you're adding security features like authentication and encryption. These seem incompatible goals.
Later on somebody else pointed out that storage controllers are large SMP boxes today (so may have the processing power to do security).
Also, hard disks may not need as strong security if they're used in a private IP networks (e.g. in a storage box)
Somebody asked whether IPS could have somebody else solve the security problem for us. Scott Bradner pointed out it was the responsibility of each IETF WG to solve the security problem in its domain, perhaps using mechanisms from other (esp. security) WGs.
Somebody else pointed out that low configuration of storage servers and clients is a must and that IPS should pay attention to DHC and ZEROCONF work.
Somebody asked:
DOesn't SCSI have a notion of transactions? What is IPS going to do to support transactions?
Randy Haagens answered:
Though disk I/Os are called transactions sometimes, they're actually done on a best-effort basis. There is not strict database notion of transaction here.
There was some discussion on other standards bodies that might be working on this. Scott pointed out that many other standards groups had been notified of this work by soliciting comments on the new-works mailing list.
Scott Bradner:
Hum if you're interested in this.
Audience:
Hmmmm.....
Scott Bradner:
Take the feedback under consideration.
Requirements doc is a must
Applicability statement is a must
Security definitely needs to be addressed
None received.