|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: Flow ControlBTW, on the issue of adjusting the total amount of RAM available to allow us to avoid the protocol issue, this will not work for moderately priced NAS boxes. These are focused on ease of use, and so are sealed and not end user (or channel) configurable. Off the top of my head I'd estimate that approach would not work for NAS devices selling for $10,000 or less - any perhaps not very well for those selling for several tens of thousands of dollars. Even if the boxes are technically capable of accepting more RAM, the configuration you want depends on the deployment - which is determined by the end user, and may be changed through subsequent redeployment. For a traditional heavy touch IS operation that is fine, but not for those working outside the glass house. This is not to say there will not be different amounts of buffering used - a 1 disk NAS will have less than a 10 disk NAS. But no one I knows wants to produce multiple versions of 4 disk NAS, with differing amounts of buffering, if they can avoid it. Jim PS of course, if the focus of iSCSI was just the machine room then this becomes manageable, but that is not what I am hearing people talk about. -----Original Message----- From: Jim McGrath Sent: Wednesday, October 04, 2000 7:37 PM To: 'John Hufferd/San Jose/IBM'; IPS@ece.cmu.edu Subject: RE: iSCSI: Flow Control I agree that there is a difference in the degree of buffer requirements based on true internet vs machine room application. However, I don't think vendors will necessarily design their products differently for the two applications. And even in a machine room setting (e.g. today's parallel SCSI and Fibre Channel), people have requested immediate data on writes (which is what this feature is designed to provide). I don't think leaving this out of the iSCSI protocol is wise - we have already had a market failure (i.e. an experience where a desired feature could not be supported by the vendors) in this area with Fibre Channel, and it just looks worse going forward. I fear coupling to sessions sounds too much like coupling to login, which did not work in FC-AL. BTW, the burden here is almost entirely on the target. The target is the one responsible for allocating the buffers - the hosts just have to respond to changes in the amount available. Unless this is really hard for the host to do(?) Jim -----Original Message----- From: John Hufferd/San Jose/IBM [mailto:hufferd@us.ibm.com] Sent: Wednesday, October 04, 2000 2:58 PM To: IPS@ece.cmu.edu Subject: RE: iSCSI: Flow Control OK, I can buy that Peer to Peer Session stuff. So we, at least we seem to be in agreement on these items. (The length of "normal" Sessions, the length of Peer to Peer Sessions, and the Dynamic Buffering requirements for Storage Controllers.) So let me push this slightly. I also believe that when Storage Controllers are sold as iSCSI Internet (by that I mean long distance connect) capable, there will be a RAM Storage Feature that is recommended by the Vendor. Any one that just wants to use the Storage Controller in areas where SCSI Buss or FC distances apply today, might not need the additional RAM feature. I think that is the way this stuff will be sold (and need to be sold) and vendors will then compete on their more optimum ways of using the RAM buffers. There may be a variant of the above where the Vendor Sells the RAM Storage Feature based on the number of Concurrent Sessions the customers wants to sustain. And of course there will be combinations of RAM Storage Features for number of Sessions and Distance. Vendors will compete on how simple (in relationship to Cost and performance) their approach is viewed relative to the Distance and number of Sessions needed. If others believe this, then the stuff we have been talking about with regards to Flow Control is Mute and can be left up to TCP/IP and the various vendors implementations of the iSCSI/SCSI buffering algorithms. . . . John L. Hufferd Michael Krause <krause@cup.hp.com>@ece.cmu.edu on 10/04/2000 01:44:25 PM Sent by: owner-ips@ece.cmu.edu To: IPS@ece.cmu.edu cc: Subject: RE: iSCSI: Flow Control At 12:34 PM 10/4/00 -0700, John Hufferd/San Jose/IBM wrote: >Michael Krause, >First, a session usually lasts from Boot Time till it is Booted again or >stopped. The variant to this is a Storage Device being used in a manor >like a Mount or Map done with NAS. Even then, most folks, have that setup >so the Mounting and Mapping is done at bring up, though it is sometimes >done at other times, but even then it is left around. So I think the thing >you can say about Session Time as the term is used in the iSCSI context is >that it is LONG. > >I do not think we have consensus about the notification of available >buffers. With the way many systems work, is (as stated above), all devices >are set up at startup of the Host, and the Session is kept around by the >Host, even if there hasn't been anything which use that device all >day/week, etc. So I am not sure if having a certain amount of buffer space >reserved for each Host (which could be 100s-1000s) would be an especially >good idea. I believe we are in agreement both in terms of duration and the need to have dynamic buffer management. I will clarify that there will also be sessions that are not host focused, e.g. the peer-to-peer direction of a storage object to another device, e.g. multi-media streaming and these sessions will be shorter lived - possibly on a per transaction basis where a transaction is something of reasonably large in value (e.g. 100's MBs of data movement). Mike
Home Last updated: Tue Sep 04 01:06:50 2001 6315 messages in chronological order |