|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: Requirements specificationAt 10:58 AM 8/4/00 -0700, psarkar@almaden.ibm.com wrote: >Two points: > >1. The iSCSI presenters seem to imply that having 'n' connections through >the IP fabric will automatically give you 'n' (or close to 'n') times the >bandwidth if you round-robin your packets across the connections. This is >probably true only in the very ideal case and in the real world, the >situation is far less rosy to make such an assertion so confidently. Not true that this has to be the ideal world - there are numerous applications that maintain high-bandwidth through multiple connections on the same path or across several paths. Also, network routers often implement RED / WRED schemes which may only impact a subset of the sessions connections. >2. Fault-tolerance currently is (and should be) layered above the SCSI >transport layer. There are enough solutions from several vendors in the >market which deal with this, >so there is no use in reinventing the wheel. Fault tolerance is a highest level of availability there are other levels that allow one to recover from a variety of failure types without requiring to implement to this level. Most of these can be simply implemented below the iSCSI level. Also, dynamic changes in the network composition can be dealt with without resorting to high-level changes to the applications. The objective of improving the availability is to not be required to use this overly complex solutions but to create simple, low-implementation costs solutions that will benefit the majority of the customers. >Based on the "Keep It Simple and Stupid" and "Optimize for the Common Case" >principles,I would appeal to the iSCSI "design team" to forgo multiple >connections per >session and use specialized solutions for remote mirroring and remote tape >backup (the apps that require multiple connections). Multiple connections can be done using a KISS principle and more robust solutions can be built on top of this solution to expand the functional capabilities without requiring the architecture to be radically permuted in the process. Mike
Home Last updated: Tue Sep 04 01:08:02 2001 6315 messages in chronological order |